Wybór hostingu dla Next.js między Vercel, Coolify i VPS

Co naprawdę hostujesz w aplikacji Next.js?

Nie każda aplikacja Next.js wymaga stałego backendu. Prosta strona może zostać wyeksportowana do statycznych plików. Jeżeli jednak korzystasz z renderowania serwerowego, Server Actions, tras API, ISR, PPR lub funkcji zależnych od żądania, potrzebujesz runtime'u serwerowego.

Dokumentacja Next.js wskazuje, że pojedynczy proces next start obsługuje Server Components, ISR, PPR, Cache Components, Server Actions, Proxy oraz after(). W praktyce oznacza to, że Vercel nie jest wymogiem technicznym dla pełnej aplikacji Next.js. Platforma zarządzana ułatwia operacje, ale aplikację można poprawnie uruchomić także na Node.js lub w Dockerze.

Vercel dla Next.js: zarządzana platforma i koszty użycia

Vercel rozwija Next.js i oferuje środowisko przygotowane pod jego wdrożenia. Po połączeniu repozytorium platforma buduje aplikację, wystawia deploymenty podglądowe i produkcyjne oraz obsługuje warstwę dostarczania treści. To oszczędza czas zespołu, szczególnie przy MVP, stronach marketingowych i produktach, w których częste preview ma realną wartość.

Co daje Vercel przy hostingu Next.js

• automatyczne wdrożenia i preview deployments po zmianach w repozytorium,
• zarządzany CDN, HTTPS i mechanizmy cache dla obsługiwanych zasobów,
• zarządzaną optymalizację obrazów: obrazy z next/image mogą być transformowane i cache'owane w CDN Vercel,
• dashboard użycia oraz opcjonalne produkty analityczne i obserwowalność,
• konfigurację regionu wykonania Vercel Functions blisko bazy danych.

CDN nie określa regionu funkcji. Statyczne zasoby są dostarczane z globalnej sieci, natomiast kod funkcji wykonuje się w regionie przypisanym do projektu. Sprawdź tę konfigurację zamiast zakładać, że globalny CDN oznacza globalne wykonanie backendu. Funkcję zwykle umieszcza się blisko bazy, ponieważ odległość między compute i danymi wpływa na każde zapytanie. Wieloregionowe wykonanie oraz failover zależą od planu i architektury aplikacji.

Cennik Vercel w 2026 roku

W projekcie komercyjnym nie należy opierać kalkulacji na darmowym Hobby. Dla Pro koszt może rosnąć wraz z transferem, żądaniami, compute, ISR, optymalizacją obrazów, buildami i dodatkami. Według cennika z 1 sierpnia 2026 roku Pro obejmuje między innymi 1 TB szybkiego transferu, 10 mln Edge Requests, 1 mln wywołań funkcji i 5 tys. transformacji obrazów. Jednostki te mają osobne stawki po przekroczeniu limitu, a regionalne ceny mogą się różnić.

Budżet domyślny nie zawsze jest limitem. Vercel udostępnia alerty, limity wydatków i możliwość wstrzymania projektów po osiągnięciu progu, ale trzeba świadomie skonfigurować tę politykę. Przed uruchomieniem ruchu komercyjnego ustaw alerty oraz hard limit odpowiedni do skutków zatrzymania aplikacji.

Vercel a RODO i lokalizacja danych

Samo korzystanie z Vercel nie oznacza braku zgodności z RODO. Vercel publikuje Data Processing Addendum dotyczący klientów planów Pro i Enterprise oraz umożliwia konfigurację regionów wykonywania funkcji. Jednocześnie ustawienie funkcji w Europie nie dowodzi, że każda kategoria danych, logów lub usług pomocniczych pozostaje wyłącznie w Europejskim Obszarze Gospodarczym.

Jeżeli aplikacja przetwarza dane osobowe, sprawdź zakres danych, plan Vercel, DPA, podprocesorów, transfery, ustawienia logów i używane magazyny danych. To analiza prawno-techniczna, a nie prosta różnica między „Vercel” i „serwer w UE”.

Coolify dla Next.js: panel wdrożeń na własnej infrastrukturze

Coolify jest otwartoźródłową platformą do wdrażania aplikacji, baz i usług na serwerach dostępnych przez SSH. Możesz hostować go samodzielnie. Obsługuje aplikacje Next.js, automatyczne certyfikaty Let's Encrypt oraz integracje Git. Dostępne są dwa odmienne modele:

Co Coolify upraszcza przy hostingu Next.js

• wdrożenia aplikacji i usług Docker-compatible na własnych serwerach,
• automatyczne certyfikaty TLS dla domen,
• podpinanie repozytoriów i automatyczne deploymenty,
• preview deployments dla pull requestów po skonfigurowaniu GitHub App lub webhooków,
• zarządzanie usługami oraz automatyzację backupów do magazynu S3-compatible.

Preview deployments nie są „za darmo” pod względem zasobów: każda wersja podglądowa zużywa pojemność Twojego serwera. Dokumentacja Coolify wymaga również skonfigurowania domeny wildcard dla adresów preview i zaleca rozdzielenie sekretów produkcyjnych od sekretów podglądowych.

Czego Coolify nie gwarantuje w produkcji

Coolify nie zamienia pojedynczego VPS-a w wieloregionową platformę o automatycznej wysokiej dostępności. Jeżeli serwer z aplikacją i panelem ulegnie awarii, bez osobnej architektury awaryjnej niedostępne mogą stać się aplikacja oraz możliwość jej wdrażania.

Koszt również nie jest automatycznie stały przy dowolnym ruchu. Możesz potrzebować większego serwera, oddzielnej bazy, object storage, zewnętrznych backupów, CDN, monitoringu, load balancera lub dodatkowych maszyn. Coolify pozwala kontrolować te decyzje; nie usuwa ich kosztu.

Backup panelu nie obejmuje danych aplikacji. Dokumentacja rozróżnia kopię konfiguracji samego Coolify od wolumenów, uploadów i baz uruchomionych przez użytkownika. Dla PostgreSQL, MySQL, MariaDB i MongoDB można skonfigurować osobne harmonogramy oraz storage zgodny z S3. Kopia jest użyteczna dopiero wtedy, gdy zespół zna wymagane klucze, potrafi ją pobrać poza serwer i regularnie testuje odtwarzanie.

Minimalne wymagania i instalacja Coolify

Dokumentacja Coolify zaleca świeży serwer, co najmniej 2 rdzenie CPU, 2 GB RAM i 30 GB wolnego miejsca. Rekomendowana szybka instalacja na wspieranym systemie wygląda następująco:

curl -fsSL https://cdn.coollabs.io/coolify/install.sh | sudo bash

Po instalacji panel jest początkowo dostępny na porcie 8000. Pierwsze konto administratora trzeba utworzyć natychmiast, a po skonfigurowaniu własnej domeny i reverse proxy należy ograniczyć publiczny dostęp do portów panelu zgodnie z dokumentacją firewalla.

Polecenie curl | bash jest oficjalną szybką ścieżką instalacji, ale uruchamia pobrany skrypt z wysokimi uprawnieniami. W środowisku objętym kontrolą zmian można najpierw pobrać i przejrzeć skrypt albo użyć instalacji ręcznej. Zapisz także APP_KEY oraz klucze SSH Coolify poza hostem, ponieważ są potrzebne do pełnego odtworzenia panelu.

Własny VPS i Docker dla Next.js: pełna kontrola nad wdrożeniem

Ręczne wdrożenie VPS ma sens, gdy zespół już utrzymuje infrastrukturę, wymaga nietypowej sieci lub świadomie chce zarządzać każdą warstwą systemu. Nie jest to jednak osobny „wyższy poziom” względem Coolify: Coolify również działa na serwerach, a różnica polega na tym, czy używasz jego warstwy zarządzania deploymentami.

Na własnym serwerze odpowiadasz między innymi za:

• aktualizacje systemu, Node.js, Dockera i reverse proxy,
• certyfikaty TLS, firewall, ograniczenie dostępu i monitoring,
• backup danych aplikacji oraz test odtwarzania,
• deploymenty bez przestoju i strategię rollbacku,
• skalowanie oraz cache, jeśli aplikacja przestaje mieścić się na jednej instancji.

Dockerfile dla projektu Next.js

Next.js może wygenerować minimalny serwer produkcyjny przez output: 'standalone'. Poprzednia wersja tego przykładu używała Node.js 20, który zakończył okres wsparcia 24 marca 2026 roku. Dla nowego wdrożenia wybierz utrzymywaną linię LTS. W produkcyjnym repozytorium możesz dodatkowo przypiąć digest obrazu i aktualizować go kontrolowanym procesem. Poniższy przykład używa Node.js 24 LTS oraz npm:

FROM node:24-alpine AS base
 
FROM base AS deps
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
 
FROM base AS builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
RUN npm run build
 
FROM base AS runner
WORKDIR /app
ENV NODE_ENV=production
ENV PORT=3000
ENV HOSTNAME=0.0.0.0
RUN addgroup --system --gid 1001 nodejs
RUN adduser --system --uid 1001 nextjs
COPY --from=builder /app/public ./public
COPY --from=builder --chown=nextjs:nodejs /app/.next/standalone ./
COPY --from=builder --chown=nextjs:nodejs /app/.next/static ./.next/static
USER nextjs
EXPOSE 3000
CMD ["node", "server.js"]

// next.config.ts
const nextConfig = {
  output: 'standalone',
}
 
export default nextConfig

Dodaj .dockerignore, aby kontekst budowania nie zawierał sekretów ani zbędnych katalogów:

.git
.next
node_modules
.env*
npm-debug.log*

Zmienne NEXT_PUBLIC_* używane podczas budowania mogą zostać zapisane w bundlu przeglądarkowym. Sekrety przekazuj do kontenera w runtime i nie kopiuj plików .env do obrazu. Obraz uruchamiaj jako użytkownik bez uprawnień roota, skanuj zależności i regularnie przebudowuj po aktualizacji obrazu bazowego.

Dokumentacja Next.js rekomenduje reverse proxy, np. Nginx, przed publicznie dostępnym serwerem aplikacji. Proxy powinno terminować TLS, przekazywać właściwe nagłówki oraz nie buforować odpowiedzi strumieniowanych, jeżeli aplikacja korzysta ze streamingu lub PPR.

Cache i ISR przy samodzielnym hostowaniu Next.js

Przy samodzielnym hostowaniu next/image działa z next start bez dodatkowej konfiguracji. Również cache i ISR działają poprawnie na pojedynczej instancji z trwałym dyskiem. Artykuł byłby jednak niekompletny bez rozróżnienia pojedynczego serwera od skalowania aplikacji.

Next.js sam ustawia długi, niemodyfikowalny Cache-Control dla rzeczywiście niezmiennych zasobów z hashem w nazwie. Nie ma więc potrzeby przepisywania nagłówków dla /_next/static bez rozumienia konfiguracji. Tym bardziej nie należy automatycznie wymuszać cache dla całego /_next/image lub dynamicznego HTML-a: poprawna polityka zależy od odpowiedzi originu i sposobu użycia obrazów oraz danych.

Wiele instancji wymaga wspólnej konfiguracji

Przy wdrożeniu kroczącym dwie wersje aplikacji mogą przez chwilę obsługiwać ruch równocześnie. Next.js dokumentuje trzy osobne problemy:

• Cache musi działać między instancjami. Domyślna pamięć i dysk są lokalne, więc potrzebujesz trwałego handlera oraz koordynacji tagów rewalidacji.

• Server Actions potrzebują wspólnego klucza. Ustaw jednakowy NEXT_SERVER_ACTIONS_ENCRYPTION_KEY podczas budowania wszystkich replik danego wdrożenia.

• Deployment ID ogranicza version skew. Pozwala wykryć klienta korzystającego z assetów poprzedniej wersji i wymusić pełną nawigację.

// next.config.ts
const nextConfig = {
  output: 'standalone',
  deploymentId: process.env.DEPLOYMENT_VERSION,
  cacheHandler: require.resolve('./cache-handler.js'),
  cacheMaxMemorySize: 0,
}
 
export default nextConfig

Sam wpis cacheHandler nie tworzy rozproszonego cache. Implementacja potrzebuje trwałego magazynu, polityki wygaszania, obsługi błędów oraz synchronizacji revalidateTag() między instancjami.

Pliki, procesy w tle i ograniczenia runtime'u

Wybór platformy powinien wynikać również z efektów ubocznych aplikacji. Zapis pliku na lokalnym dysku funkcji Vercel nie jest trwałym magazynem produktu. Plik może zniknąć wraz z instancją i nie będzie współdzielony z innymi wykonaniami. Na pojedynczym VPS-ie wolumen może być trwały, ale po dodaniu drugiej repliki pojawia się ten sam problem spójności.

Uploady zapisuj w trwałym object storage. Baza powinna przechowywać identyfikator, metadane i uprawnienia, a nie ścieżkę zależną od jednego kontenera. Testuj również usuwanie osieroconych plików oraz ograniczenia rozmiaru i typu uploadu.

Podobnie wygląda praca asynchroniczna. Wysłanie odpowiedzi HTTP nie gwarantuje, że kod uruchomiony bez oczekiwania dokończy zadanie po zamknięciu procesu. E-maile, generowanie raportów, importy i przetwarzanie wideo kieruj do kolejki, workflow albo osobnego workera z ponowieniami i idempotencją.

Vercel oferuje zarządzane funkcje, cron, kolejki i workflow z limitami zależnymi od produktu oraz planu. Coolify lub VPS pozwalają uruchomić własnego workera, ale wtedy sam odpowiadasz za supervisor, retry, dead-letter queue, monitoring i skalowanie. Długotrwałe połączenia, własne demony i nietypowe zależności systemowe trzeba porównać z bieżącymi ograniczeniami wybranej platformy przed podpisaniem umowy.

Jak policzyć całkowity koszt hostingu

Porównanie 20 USD za Vercel Pro z ceną jednego VPS-a pomija większość kosztów. Użyj miesięcznego modelu:

TCO = platforma i serwery
    + transfer, compute, obrazy i storage
    + baza, backupy, monitoring i poczta
    + godziny utrzymania i dyżurów
    + oczekiwany koszt przestojów

Koszt pracy często zmienia wynik porównania. Jeśli własna infrastruktura wymaga czterech dodatkowych godzin miesięcznie, pomnóż je przez pełny koszt godziny osoby odpowiedzialnej. Do czasu zalicz aktualizacje, przegląd alertów, testy backupu, odtwarzanie po awarii i utrzymanie pipeline'u.

Dla Vercel zbierz z dashboardu transfer, Edge Requests, czas CPU i pamięć funkcji, ISR, transformacje obrazów, buildy oraz płatne dodatki. Dla Coolify i VPS zmierz szczytowe CPU, RAM, dysk, transfer i czas buildów. Zostaw zapas na nagły ruch oraz awarię jednej maszyny, jeśli deklarujesz wysoką dostępność.

Vercel vs Coolify vs VPS: jak podjąć decyzję?