Vercel, wdrożenia i rozliczanie czasu CPU

Vercel, wdrożenia i rozliczanie czasu CPU

Vercel to platforma, która po podłączeniu repozytorium buduje i publikuje aplikację przy każdym wypchnięciu zmian, a każdej gałęzi daje własny adres do obejrzenia. Do tego dokłada funkcje uruchamiane na żądanie, sieć dostarczania treści i pamięć podręczną dla stron generowanych po stronie serwera.

Największa zaleta jest banalna i dlatego skuteczna: od pustego repozytorium do działającego adresu upływa kilka minut, bez konfigurowania czegokolwiek. Największa wada jest równie prosta: rachunek bywa nieprzewidywalny, dopóki nie zrozumiesz, za co dokładnie płacisz.

Dwie zmiany, o których trzeba wiedzieć

Materiały opisujące tę platformę starzeją się szybko, a dwie zmiany z ostatniego czasu unieważniają sporą część tego, co znajdziesz w sieci.

Pierwsza dotyczy podziału na dwa rodzaje funkcji. Przez lata trzeba było wybierać między środowiskiem brzegowym, szybkim w starcie i ubogim w możliwości, a zwykłym środowiskiem Node, wolniejszym w starcie i pełnym. Osobny produkt z funkcjami brzegowymi został wycofany w czerwcu 2025 roku, a zalecanym rozwiązaniem jest jedno środowisko Node z pełnym dostępem do interfejsów.

To upraszcza życie bardziej, niż wygląda. Znika klasa błędów wynikających z tego, że biblioteka działała lokalnie, a padała po wdrożeniu, bo w środowisku brzegowym nie było modułu, którego używała.

Druga zmiana dotyczy rozliczania i jest ważniejsza dla rachunku. Funkcje są rozliczane za faktyczny czas pracy procesora, a nie za czas trwania wywołania mierzony zegarem. Oczekiwanie na odpowiedź z bazy danych albo z modelu językowego nie jest naliczane, bo procesor wtedy nie pracuje.

Co to znaczy dla kosztów

Różnica między tymi dwoma modelami jest zasadnicza i zmienia opłacalność całych klas aplikacji.

Weź funkcję, która wysyła zapytanie do bazy, czeka osiemset milisekund na odpowiedź i przez pięćdziesiąt milisekund przetwarza wynik. W dawnym modelu płaciłeś za osiemset pięćdziesiąt milisekund. W nowym płacisz za pięćdziesiąt, bo reszta to czekanie.

Im więcej Twoja aplikacja czeka, tym większa oszczędność. Trasa wołająca model językowy, która czeka pięć sekund na odpowiedź, kosztuje ułamek tego, co kosztowała wcześniej. Trasa przeliczająca obrazy albo sortująca duży zbiór w pamięci nie zyskuje nic, bo tam procesor faktycznie pracuje.

Dochodzi do tego współbieżność. Jedna instancja obsługuje wiele wywołań naraz, więc czas oczekiwania jednego żądania jest wykorzystywany na obsługę innego. To dodatkowo obniża rachunek i skraca zimne starty, bo instancji potrzeba mniej.

Praktyczny wniosek: jeśli Twoje wyobrażenie o kosztach tej platformy pochodzi sprzed tej zmiany, policz je ponownie. Przy aplikacji, która głównie czeka na zewnętrzne usługi, różnica bywa kilkukrotna.

Podglądy wdrożeń, czyli najmocniejsza rzecz w tym zestawie

Każda gałąź dostaje własny adres, a każde żądanie scalenia odnośnik do wersji zawierającej te konkretne zmiany.

Brzmi to jak drobiazg i jest najczęściej wymienianym powodem, dla którego zespoły zostają przy tej platformie mimo kosztów. Osoba projektująca ogląda zmianę na działającej stronie, a nie na zrzucie ekranu. Klient klika w rzeczywistą aplikację, zanim cokolwiek trafi na produkcję. Testy automatyczne dostają adres, pod którym stoi dokładnie ten kod, który jest w przeglądzie.

Warto pilnować dwóch rzeczy. Podglądy są domyślnie publiczne pod trudnym do odgadnięcia adresem, więc jeśli aplikacja w tej wersji ma dostęp do prawdziwych danych, trzeba włączyć ochronę dostępem. Oraz: każdy podgląd używa zmiennych środowiskowych przypisanych do tego środowiska, więc podpięcie ich do bazy produkcyjnej jest łatwe i groźne. Osobna baza dla podglądów rozwiązuje problem raz.

Przy pracy lokalnej podobną wygodę adresu daje Portless, narzędzie z laboratoriów tego samego producenta: zamiast localhost:3000 otwierasz projekt pod nazwą w rodzaju sklep.localhost, po HTTPS i z ciasteczkami osobnymi dla każdej aplikacji, więc dwie usługi uruchomione naraz przestają się nawzajem wylogowywać. Kosztem jest instalacja u każdej osoby w zespole i dodanie własnego urzędu certyfikacji do magazynu zaufania systemu, co w części firm podlega politykom bezpieczeństwa.

Struktura kosztów w praktyce

Rachunek składa się z kilku pozycji i tylko jedna z nich jest oczywista.

Plan darmowy wystarcza do projektów prywatnych i portfolio, z zastrzeżeniem, że nie wolno w nim prowadzić działalności komercyjnej. Plan płatny zaczyna się od dwudziestu dolarów miesięcznie za osobę i zawiera pulę zużycia, po której przekroczeniu płacisz za nadwyżkę.

Pozycje, które zaskakują, to zwykle nie funkcje. Transfer danych, liczba żądań obsłużonych przez sieć dostarczania treści, przechowywanie i odświeżanie stron generowanych przyrostowo oraz optymalizacja obrazów potrafią przewyższyć koszt samego wykonywania kodu.

Optymalizacja obrazów zasługuje na osobne zdanie, bo jest najczęstszym źródłem niespodzianki. Każdy rozmiar i format wygenerowany dla każdego obrazu liczy się osobno, więc galeria z dwustoma zdjęciami wyświetlana w pięciu rozmiarach to tysiąc pozycji, a nie dwieście.

Zanim wpiszesz tę platformę do budżetu, obejrzyj zakładkę ze zużyciem po pierwszym tygodniu ruchu produkcyjnego. Rozkład pozycji w niej jest zwykle inny, niż zakładał zespół, i to jedyna miarodajna podstawa do decyzji.

Warto przy tym wiedzieć, że platforma ma wbudowany mechanizm chroniący przed rachunkiem, o którym mowa wyżej, a zespoły rzadko z niego korzystają. Nowe zespoły dostają domyślny budżet zużycia na dwieście dolarów, z powiadomieniami pocztą, wiadomością tekstową i w panelu, a próg da się zmienić. Można też ustawić automatyczne wstrzymanie projektów po osiągnięciu stu procent budżetu.

To ustawienie warto rozstrzygnąć świadomie przy pierwszym wdrożeniu produkcyjnym, bo obie odpowiedzi są uzasadnione. Automatyczne wstrzymanie chroni przed rachunkiem po nieudanej pętli albo po nagłym ruchu, ale wyłącza stronę. Sam alert bez wstrzymania zostawia stronę działającą i przenosi decyzję na człowieka, który może akurat spać.

Pamięć podręczna i regeneracja stron

To jest obszar, w którym platforma daje najwięcej i w którym najłatwiej niechcący wyłączyć to, za co się płaci.

Strona wygenerowana raz i serwowana z sieci dostarczania treści kosztuje ułamek tego, co strona przeliczana przy każdym żądaniu, i odpowiada w kilkadziesiąt milisekund zamiast w kilkaset. Mechanizm regeneracji przyrostowej pozwala trzymać ją statyczną, a mimo to odświeżać po czasie albo na żądanie po zmianie treści.

Problem polega na tym, że łatwo z tego wypaść bez świadomej decyzji. Odczyt nagłówka żądania, sięgnięcie po ciasteczko albo użycie funkcji zwracającej bieżący czas zamienia trasę statyczną w dynamiczną, a wynik widać dopiero w rachunku i w czasach odpowiedzi.

Diagnoza jest prosta, jeśli wiesz, gdzie patrzeć. Wynik budowania wypisuje przy każdej trasie, czy jest statyczna, czy dynamiczna, a porównanie tej listy z oczekiwaniami zajmuje minutę.

npx vercel build

Warto zrobić to raz po każdej większej zmianie, bo pojedynczy import wciągnięty do wspólnego komponentu potrafi przestawić kilkanaście tras naraz.

Osobna rzecz to unieważnianie. Odświeżanie po czasie jest proste i wystarczające przy treści, która może być nieaktualna przez kilka minut.

export const revalidate = 600

export default async function Strona() {
  const wpisy = await pobierzWpisy()
  return <Lista wpisy={wpisy} />
}

Unieważnianie na żądanie, wywoływane z systemu zarządzania treścią po publikacji, daje świeżość natychmiastową i wymaga jednej trasy, która przyjmie sygnał. Ta druga droga jest zwykle warta godziny pracy, bo usuwa kompromis między świeżością a kosztem.

import { revalidateTag } from 'next/cache'
import { NextRequest } from 'next/server'

export async function POST(req: NextRequest) {
  if (req.headers.get('x-webhook-secret') !== process.env.WEBHOOK_SECRET) {
    return new Response('Brak dostepu', { status: 401 })
  }

  revalidateTag('wpisy')
  return Response.json({ odswiezone: true })
}

Sprawdzenie sekretu w pierwszej linii nie jest formalnością. Trasa unieważniająca bez tego zabezpieczenia pozwala dowolnej osobie wymusić przeliczenie wszystkich stron, a to jest tani sposób na podniesienie cudzego rachunku.

Zmienne środowiskowe i sekrety

Trzy środowiska, każde z własnym zestawem zmiennych, i to rozróżnienie warto ustawić poprawnie od początku.

Zmienne oznaczone jako publiczne trafiają do kodu wykonywanego w przeglądarce, więc widzi je każdy, kto otworzy narzędzia deweloperskie. To jest oczywiste i mimo to najczęstsze miejsce, w którym klucz do zewnętrznej usługi wycieka: ktoś dodał przedrostek publiczny, żeby zadziałało w komponencie klienckim, i zadziałało.

Zmienne bez tego przedrostka są dostępne wyłącznie po stronie serwera i tam należy trzymać wszystko, co ma pozostać tajne. Reguła jest prosta: jeśli wartość pozwala coś zrobić w Twoim imieniu, nie może być publiczna, a wywołanie korzystające z niej musi iść przez trasę serwerową.

Zmienne z panelu ściągasz do pracy lokalnej jednym poleceniem, zamiast utrzymywać drugą kopię ręcznie.

npx vercel env pull .env.local
npx vercel env add STRIPE_SECRET production

Warto też pamiętać, że zmiana zmiennej nie wchodzi w życie sama. Wartości są wbudowywane w moment budowania, więc po edycji trzeba wdrożyć ponownie. To źródło regularnego zamieszania, bo panel pokazuje nową wartość, a aplikacja działa na starej.

Vercel kontra alternatywy

Pierwszy wiersz wygrywa przez wygodę, a nie przez cenę, i warto to nazwać wprost. Zespół bez osoby zajmującej się infrastrukturą dostaje tu wdrożenia, podglądy, certyfikaty, sieć dostarczania treści i cofanie zmian bez konfigurowania czegokolwiek. To realna oszczędność czasu, którą trzeba porównać z rachunkiem, a nie ignorować przy porównywaniu stawek.

Ostatni wiersz warto rozważyć przy stałym, przewidywalnym ruchu. Aplikacja obsługująca równomierne obciążenie przez całą dobę jest tańsza na maszynie o stałej cenie niż na modelu naliczanym za zużycie, i ta różnica rośnie wraz ze skalą.

Gdzie ta platforma nie pasuje

Warto to rozstrzygnąć wcześnie, bo migracja po roku jest kosztowna.

Zadania długotrwałe nie pasują. Funkcje mają limit czasu wykonania, więc przetwarzanie pliku wideo, generowanie dużego raportu albo import kilkuset tysięcy rekordów wymaga osobnej infrastruktury albo podziału na kroki.

Procesy działające w tle nie pasują. Kolejka konsumowana w sposób ciągły, nasłuch na zmiany w bazie albo utrzymywane połączenie wymagają czegoś, co po prostu działa, a nie startuje na żądanie.

Aplikacja o dużym transferze danych bywa tu droga. Serwis wideo, hosting plików albo strona z ciężką grafiką generuje koszt transferu, przy którym własne rozwiązanie zwraca się szybko.

Zaplecze złożone z wielu usług też pasuje słabo. Model oparty o funkcje sprawdza się przy trasach obsługujących żądania, a gorzej przy systemie z kilkoma procesami, kolejkami i zadaniami cyklicznymi między nimi.

Praktyczne wskazówki

Kilka rzeczy oszczędza pieniądze i nerwy przy dłuższej pracy z tą platformą.

Ustaw limity wydatków od pierwszego dnia. Model naliczany za zużycie oznacza, że błąd w kodzie powodujący pętlę żądań rośnie w rachunek, a nie w komunikat o wyczerpanym limicie.

Pilnuj pamięci podręcznej. Trasa, która mogła być statyczna, a przez przypadkowe użycie nagłówka stała się dynamiczna, wykonuje się przy każdym żądaniu zamiast raz. To najczęstsza przyczyna nagłego wzrostu liczby wywołań bez wzrostu ruchu.

Ogranicz rozmiary obrazów do tych, których faktycznie używasz. Domyślny zestaw punktów przełamania generuje warianty, których interfejs nigdy nie pokaże.

Trzymaj bazę blisko funkcji. Zapytanie do bazy po drugiej stronie oceanu dokłada opóźnienie do każdego żądania, a przy rozliczaniu za czas procesora nie podnosi kosztu, tylko psuje odczucia użytkownika.

Ostatnia rzecz: nie wiąż logiki biznesowej z pojęciami tej platformy. Trasy zapisane jako zwykłe funkcje przenoszą się gdzie indziej bez przepisywania, a te oparte o mechanizmy specyficzne dla dostawcy już nie.

Typowe błędy

Pierwszy to podpięcie środowiska podglądów do bazy produkcyjnej. Każda gałąź dostaje wtedy dostęp do prawdziwych danych, a test kasujący rekordy kasuje je naprawdę.

Drugi to brak limitu wydatków. Przy naliczaniu za zużycie kosztowna pomyłka nie zatrzymuje się sama.

Trzeci to nieświadome uczynienie trasy dynamiczną. Jedno odwołanie do nagłówka albo ciasteczka wyłącza generowanie statyczne i mnoży liczbę wywołań.

Czwarty to opieranie się na wiedzy sprzed zmiany rozliczania. Kalkulacje oparte o czas trwania wywołania zawyżają koszt aplikacji, które głównie czekają na zewnętrzne usługi.

Piąty to uruchamianie tu zadań długotrwałych. Limit czasu wykonania funkcji utnie je w połowie, a wynik będzie wyglądał jak losowa awaria.

Szósty to ignorowanie kosztu optymalizacji obrazów. Każdy wariant liczy się osobno, więc galeria potrafi wygenerować więcej pozycji niż cała reszta serwisu.

FAQ

Czy Vercel jest darmowy?

Plan darmowy wystarcza do projektów prywatnych, nauki i portfolio, natomiast nie wolno w nim prowadzić działalności komercyjnej. Plan płatny zaczyna się od dwudziestu dolarów miesięcznie za osobę i zawiera pulę zużycia, po której przekroczeniu naliczana jest nadwyżka.

Czy Edge Functions nadal istnieją?

Osobny produkt z funkcjami brzegowymi został wycofany w czerwcu 2025 roku. Zalecanym rozwiązaniem są funkcje ze środowiskiem Node, które dają pełny dostęp do interfejsów i korzystają z rozliczania za faktyczny czas pracy procesora.

Za co dokładnie płacę przy funkcjach?

Za czas, w którym procesor faktycznie wykonuje Twój kod. Oczekiwanie na odpowiedź z bazy danych albo z zewnętrznego interfejsu nie jest naliczane, więc aplikacje spędzające większość czasu na czekaniu kosztują znacznie mniej niż przy rozliczaniu zegarowym.

Czy Vercel działa tylko z Next.js?

Nie, obsługuje popularne frameworki oraz strony statyczne. Integracja z Next.js jest najgłębsza, bo obie rzeczy powstają w tej samej firmie, więc część możliwości działa tam bez konfiguracji, a gdzie indziej wymaga ustawień.

Kiedy lepiej wybrać coś innego?

Przy dużym transferze danych, zadaniach długotrwałych, procesach działających w tle oraz przy stałym, przewidywalnym obciążeniu. W tych przypadkach Railway, Cloudflare albo zwykły serwer wychodzą taniej lub po prostu pasują lepiej.

Zmiany w rozliczaniu opisuje dziennik zmian dostawcy, a szczegóły planów strona z cennikiem.