Self-hosting Next.js and Payload: the maths that works, and three things that break

Cenniki platform serverless są tak skonstruowane, żeby start był darmowy. To działa: projekt rusza bez faktury, a pierwsze rachunki przychodzą dopiero wtedy, gdy coś zaczyna żyć. Problem w tym, że rosną nie proporcjonalnie do przychodu, tylko do transferu, liczby osób w zespole i czasu wykonania funkcji — trzech rzeczy, których na starcie nikt nie prognozuje.

Ten artykuł jest rachunkiem, nie manifestem. Po jednej stronie Vercel z bazą zarządzaną, po drugiej własny VPS z Coolify. Liczby pochodzą z cenników dostawców (sierpień 2026), a trzy awarie opisane na końcu wydarzyły się nam na produkcji, na dokładnie tym stosie, na którym stoi serwis, który właśnie czytasz.

Jeśli szukasz instrukcji krok po kroku, jest osobno: publiczny starter na GitHubie zawiera gotową konfigurację tego stosu, razem z plikami wdrożeniowymi.

Co realnie płacisz co miesiąc

Porównanie ma sens dopiero wtedy, gdy po obu stronach policzysz to samo: aplikację, bazę, transfer i miejsce na pliki. Przyjmijmy trzyosobowy zespół i 2 TB transferu miesięcznie — to skala małego serwisu z treścią, nie startupu po rundzie.

Dwie liczby z tej tabeli wymagają komentarza, bo to one robią różnicę. Pierwsza: transfer. Vercel Pro daje 1 TB, powyżej liczy 0,15–0,35 USD za gigabajt zależnie od regionu. Hetzner w regionach europejskich wlicza 20 TB — dwudziestokrotnie więcej, jako część ceny. Druga: baza. 57 USD to cena jednego węzła M10, a baza produkcyjna działa jako trójwęzłowy zestaw replik, więc realny rachunek jest bliżej trzykrotności, zanim doliczysz kopie zapasowe i transfer.

Jest też pozycja, której nie widać w żadnej tabeli: na własnym serwerze każda kolejna usługa jest darmowa. Worker do kolejki, własny cron, Redis, mały serwis pomocniczy — to jest ta sama maszyna. W modelu rozliczanym za wykonanie każda z nich ma własną pozycję na fakturze.

Czego ta tabela nie pokazuje

Różnica w abonamencie to nie oszczędność, tylko przesunięcie kosztu z faktury na czyjś czas. Przejmujesz trzy obowiązki, których wcześniej nie miałeś: kopie zapasowe wraz z odtwarzaniem do punktu w czasie, aktualizacje bezpieczeństwa i pilnowanie dostępności. Nie znikają dlatego, że rachunek zmalał — zmieniają właściciela.

Uczciwy przelicznik jest taki: jeśli utrzymanie zabiera dwie godziny miesięcznie przy stawce 150 zł, to 300 zł miesięcznie — czyli więcej niż zaoszczędzony abonament. Self-hosting wychodzi wtedy, gdy te godziny i tak są w zespole i dotyczą kilku projektów naraz, a nie jednego.

Architektura: jak to jest złożone

Payload od wersji 3 nie jest osobną aplikacją stojącą obok Next.js. Działa jako pakiet wewnątrz niego, dzieli ten sam proces, ten sam build i ten sam plik konfiguracyjny. To zmienia architekturę wdrożenia bardziej, niż się wydaje: panel administracyjny, API i frontend to jeden artefakt, więc jeden kontener aplikacji zamiast dwóch. Co Payload potrafi jako CMS i kiedy go wybieramy, opisujemy w: Payload CMS; sam Next.js rozkładamy w: Next.js.

Jeden kontener czy kilka

Domyślnie idziemy w jeden kontener aplikacji plus osobne kontenery na bazę, Redis i proxy. Rozbijanie aplikacji na więcej procesów ma sens dopiero wtedy, gdy któryś z nich skaluje się inaczej niż reszta — na przykład worker przetwarzający kolejkę zadań, który przy imporcie danych potrzebuje pamięci, a przez resztę doby nie robi nic.

Standalone build: 1,5 GB kontra 150 MB

Next.js potrafi zbudować katalog zawierający wyłącznie to, co jest potrzebne w czasie działania — bez pełnego drzewa zależności deweloperskich. Włącza się to jedną linią w konfiguracji (output: "standalone"), a różnica w rozmiarze obrazu jest rzędu wielkości: z około 1,5 GB schodzi się do mniej więcej 150 MB. To nie jest kosmetyka. Mniejszy obraz to krótszy transfer przy każdym wdrożeniu i wielokrotnie mniej miejsca zjadanego przez kolejne wersje, które Docker trzyma lokalnie.

Warunek jest jeden i łatwo go przeoczyć: przy budowaniu wielostopniowym trzeba ręcznie skopiować katalogi ze statycznymi zasobami i plikami publicznymi, bo standalone ich nie zabiera. Pominięcie tego daje działającą aplikację bez stylów — objaw, który wygląda na problem z CSS-em, a jest problemem z Dockerfile’em.

Szkielet docker-compose

Poniżej rdzeń konfiguracji. Coolify dokłada do tego routing, domenę i certyfikat, więc w pliku nie ma ani słowa o Traefiku — to jest właśnie ta część, za którą się go używa zamiast gołego Dockera.

1services:
2  app:
3    build: .
4    environment:
5      DATABASE_URI: mongodb://mongo:27017/app
6      PAYLOAD_SECRET: ${PAYLOAD_SECRET}
7      REDIS_URL: redis://redis:6379
8    volumes:
9      - media:/app/public/media        # KAŻDY katalog uploadów osobno
10    depends_on: [mongo, redis]
11
12  mongo:
13    image: mongo:7
14    volumes:
15      - dbdata:/data/db
16
17  redis:
18    image: redis:7-alpine
19    command: redis-server --save 60 1
20    volumes:
21      - redisdata:/data
22
23volumes:
24  media:
25  dbdata:
26  redisdata:
Copy

Uwaga do wolumenów, bo to najczęstsza pomyłka. System plików kontenera jest ulotny. Każdy katalog, do którego aplikacja zapisuje pliki, musi mieć własny wpis w volumes — i „każdy” znaczy każdy, osobno dla każdej kolekcji uploadów. Dodanie nowej kolekcji w Payloadzie bez dopisania wolumenu to nie jest błąd, który zobaczysz w logach. Zobaczysz go po restarcie, gdy plików nie będzie.

Kompletny zestaw — Dockerfile, compose, zmienne środowiskowe i lista kontrolna przed uruchomieniem — leży w naszym publicznym repozytorium: nextjs-payload-starter.

Trzy rzeczy, które się psują

Poradniki opisują wdrożenie udane. Poniżej trzy mechanizmy, które psują je najczęściej — każdy z realnym incydentem z naszej produkcji jako dowodem, a nie ilustracją.

1. Pamięć: optymalizacja obrazów i zabójca OOM

Komponent next/image domyślnie przelicza grafiki w procesie aplikacji, używając biblioteki sharp. Na platformie zarządzanej robi to osobna, skalowana usługa i nikt tego nie zauważa. W kontenerze na VPS-ie z 2–4 GB pamięci wgranie kilku zdjęć produktowych przez panel Payloada potrafi wywołać OOM Killer — jądro zabija proces, żeby ratować system. Aplikacja znika bez wpisu w logach aplikacyjnych, bo nie zdążyła go zapisać.

Skutek biznesowy jest nieproporcjonalny do przyczyny: serwis przestaje odpowiadać w środku dnia, a jeśli trafi na to robot wyszukiwarki, strona wypada z indeksu na czas znacznie dłuższy niż sama awaria.

Naprawa ma dwa kroki. Pliki wychodzą z serwera do magazynu zgodnego z S3 — w Payloadzie robi to @payloadcms/plugin-cloud-storage z adapterem na Cloudflare R2, AWS S3 albo Hetzner Storage Box. Przeliczanie obrazów oddaje się na zewnątrz: albo do CDN-u z transformacją w locie (Cloudflare Images), albo przez wyłączenie wbudowanego optymalizatora (images.unoptimized) i generowanie rozmiarów po stronie Payloada przy zapisie. Aplikacja przestaje wtedy trzymać w pamięci coś, czego trzymać nie musi. Szerzej o doborze hostingu, CDN-u i tego, co realnie przyspiesza serwis: Hosting, domeny i CDN.

Nasza wersja tego błędu była gorsza, bo cichsza. Nie zabrakło nam pamięci — zabrakło wolumenu. Katalog jednej z kolekcji nie miał podpiętego trwałego magazynu, więc przy restarcie kontenera zniknęły wszystkie jej pliki, a rekordy w bazie zostały i twierdziły, że pliki istnieją. Zdarzyło się dwa razy: raz przy kolekcji z materiałami, raz przy kolekcji z dokumentami — jedenaście plików raportów i szablonów zniknęło z dysku, podczas gdy strona nadal oferowała je do pobrania.

2. Cache: ISR nie ma gdzie mieszkać

Na Vercelu odświeżanie stron statycznych i revalidateTag działają na poziomie globalnej sieci CDN. We własnym kontenerze cache Next.js zapisuje się do .next/cache na dysku tego kontenera. Wynikają z tego dwie rzeczy, obie nieprzyjemne: przy dwóch instancjach każda ma swój własny, niezsynchronizowany cache, a publikacja treści w panelu nie czyści go sama z siebie. To jest zresztą jedna z cen architektury headless — więcej o niej w: Headless — kiedy ma sens.

Naprawa. Własny CacheHandler wskazany w next.config, trzymający wpisy w Redisie — wtedy stan jest wspólny dla wszystkich instancji i przeżywa restart. Do tego hook afterChange w kolekcjach Payloada, który po zapisie woła revalidatePath albo revalidateTag dokładnie dla tego, co się zmieniło. Wariant minimalny — trwały wolumen na .next/cache — rozwiązuje tylko restart, nie skalowanie poziome.

Nasza wersja: dysk zapełniony do 89 GB, choć nikt nic nie wgrywał. Boty skanowały nieistniejące adresy, a renderowanie na żądanie zapisywało każdą z tych odpowiedzi jako plik cache w .next/server/app. Rosło to tygodniami, bez objawów, aż zabrakło miejsca. Naprawa okazała się jednolinijkowa — filtr odsiewający takie żądania, zanim wygenerują plik. Wniosek nie dotyczy jednak filtru, tylko tego, że na własnym serwerze cache jest Twoim katalogiem na Twoim dysku i nikt go za Ciebie nie sprząta.

3. Zasoby i stan: budowanie głodzi bazę

Jeśli baza stoi na tej samej maszynie co aplikacja, to docker build podczas wdrożenia zabiera praktycznie cały procesor i pamięć. Efekt: serwis zwalnia dokładnie wtedy, gdy wdrażasz poprawkę — czyli zwykle wtedy, gdy coś już nie działa. Przy 8 GB RAM kompilacja Next.js potrafi też po prostu zostać zabita.

• Pamięć wymiany. Minimum 4 GB swapu. Nie przyspieszy budowania, ale nie pozwoli go zabić — a to jedyne, czego się tu oczekuje.
• Budowanie poza produkcją. Obraz powstaje w GitHub Actions, ląduje w rejestrze (GHCR), a Coolify pobiera gotowy artefakt. Produkcyjny serwer przestaje uczestniczyć w budowaniu w ogóle — to jest właściwa docelowa architektura, nie optymalizacja.
• Rozdzielenie bazy. Gdy projekt rośnie, baza dostaje własną instancję. Pierwszy wydatek, który warto ponieść dobrowolnie, zanim wymusi go awaria.
• Kopie z odtwarzaniem do punktu w czasie. Zrzut raz na dobę to za mało, jeśli liczy się, ile danych możesz stracić. PITR opiera się na dzienniku zapisów — w Postgresie na WAL, w MongoDB na oplogu — i to on decyduje, czy cofniesz się do wczoraj, czy do sprzed dziesięciu minut.

Dwie pułapki, które trafiły akurat nas. Pierwsza: serwer budujący nie ma dostępu do bazy, więc każda funkcja generująca ścieżki w czasie budowania musi to przewidzieć — inaczej build przechodzi lokalnie i wywala się na produkcji. Druga jest podstępniejsza: next build sprawdza typy w całym projekcie, więc katalog wykluczony przez .dockerignore potrafi wywalić wdrożenie, podczas gdy CI — budujące poza Dockerem — świeci na zielono. Straciliśmy na tym kilka wdrożeń, zanim zrozumieliśmy, że zielone CI i udany deploy to dwie różne rzeczy.

Certyfikaty. Coolify odnawia je automatycznie przez Let’s Encrypt, ale odnowienie wymaga, żeby proxy odpowiedziało na wyzwanie HTTP. Jeśli przed serwerem stoi Cloudflare w trybie pełnego proxy, a reguły przepuszczają nie wszystko, odnowienie cicho nie przechodzi i dowiadujesz się o tym dziewięćdziesiąt dni po wdrożeniu.

Kiedy to się opłaca, a kiedy nie

Decyzja rzadko jest techniczna. Sprowadza się do tego, czy w zespole jest ktoś, kto odbierze telefon, gdy serwer przestanie odpowiadać w sobotę.

Jeśli po tym rachunku własny serwer nadal wygląda sensownie, punktem wyjścia jest nasz publiczny starter — Next.js 16, Payload 3, MongoDB i wdrożenie na Coolify w jednym repozytorium: nextjs-payload-starter.

Szerszy kontekst technologiczny — co wybór stosu robi z kosztem projektu — rozkładamy w: Porównanie technik budowy strony. A jeśli interesuje Cię pełny rachunek utrzymania, nie tylko hosting: Opłaty cykliczne.

Budujemy takie wdrożenia u siebie i dla klientów — zobacz, jak realizujemy aplikacje webowe.

Skąd te liczby

Ceny pochodzą z cenników dostawców, stan na sierpień 2026: Vercel (20 USD za osobę miesięcznie, 1 TB transferu w cenie, powyżej 0,15–0,35 USD za GB zależnie od regionu), Hetzner Cloud (CPX31: 4 vCPU, 8 GB RAM, 160 GB NVMe, 16,49 EUR miesięcznie, 20 TB transferu w regionach europejskich) oraz MongoDB Atlas (M10 od około 57 USD miesięcznie za węzeł; baza produkcyjna to trójwęzłowy zestaw replik). Opisane awarie pochodzą z naszych własnych wdrożeń, nie z literatury.