Netlify, hosting stron i rozliczenie kredytami

Netlify, wdrożenie strony bez własnego serwera

Wystawienie strony w internecie kiedyś oznaczało serwer, konfigurację i pilnowanie aktualizacji. Netlify sprowadza to do podłączenia repozytorium: po każdym wypchnięciu zmian platforma buduje projekt i wystawia go pod adresem, z certyfikatem i siecią dostarczania treści w komplecie.

To był pierwotny pomysł tej platformy i nadal jest jej najmocniejszą stroną. Wokół niego narosły funkcje brzegowe, obsługa formularzy bez zaplecza i podglądy wdrożeń, ale sedno pozostaje: strona z repozytorium do internetu bez pracy administracyjnej.

Wdrożenie i podglądy

Konfiguracja mieści się w jednym pliku w repozytorium, więc jest częścią kodu i przechodzi przez przegląd tak samo jak reszta.

[build]
  command = "pnpm build"
  publish = "dist"

[[redirects]]
  from = "/stary-adres"
  to = "/nowy-adres"
  status = 301

[[headers]]
  for = "/*"
  [headers.values]
    X-Frame-Options = "DENY"

Najbardziej użyteczną funkcją jest podgląd wdrożenia. Każda propozycja zmian dostaje własny adres z działającą wersją strony, więc przegląd nie polega na czytaniu różnicy w kodzie i wyobrażaniu sobie wyniku.

To zmienia sposób pracy przy zmianach wizualnych bardziej, niż wygląda. Osoba spoza zespołu programistycznego może zobaczyć zmianę i zgłosić uwagi, zanim trafi ona na produkcję, bez uruchamiania czegokolwiek u siebie i bez proszenia kogoś o zrzut ekranu.

Warto ustawić dwie rzeczy od początku. Pierwsza to zabezpieczenie podglądów hasłem, jeśli strona zawiera treści niegotowe do publikacji. Druga to wykluczenie podglądów z indeksowania, bo inaczej wyszukiwarka znajdzie dwadzieścia kopii Twojej strony pod różnymi adresami.

Rozliczenie kredytami

To najważniejsza zmiana ostatnich lat i pierwsza rzecz do zrozumienia przy planowaniu kosztu.

Wcześniej limity liczono osobno: gigabajty transferu, minuty budowania, wywołania funkcji. We wrześniu 2025 roku zastąpiono to jedną walutą. Każda czynność zużywa kredyty według własnej stawki, a plan daje miesięczną pulę.

Wdrożenie produkcyjne kosztuje piętnaście kredytów niezależnie od czasu budowania, co jest korzystne przy projektach budujących się długo i niekorzystne przy takich, które wdraża się dziesięć razy dziennie. Transfer to dwadzieścia kredytów za gigabajt, obliczenia dziesięć kredytów za gigabajtogodzinę, a żądania dwa kredyty za dziesięć tysięcy. Minut budowania nie liczy się wcale.

Zmiana upraszcza jedną rzecz i komplikuje inną. Upraszcza, bo jest jeden licznik zamiast czterech. Komplikuje, bo przewidzenie rachunku wymaga teraz oszacowania kilku różnych czynności i przeliczenia ich na wspólną jednostkę, co przy pierwszym miesiącu jest zgadywaniem.

Praktyczne podejście polega na przepracowaniu miesiąca i sprawdzeniu faktycznego zużycia w panelu. Ta liczba mówi więcej niż jakikolwiek kalkulator, bo uwzględnia Twoją częstotliwość wdrożeń i Twój ruch, a te dwie rzeczy różnią się między projektami bardziej niż cokolwiek innego.

Ceny

Plan darmowy wystarcza do projektu osobistego, portfolio i strony o umiarkowanym ruchu. Obejmuje też funkcje brzegowe i zwykłe funkcje bezserwerowe w liczbie, która przy małej stronie nie zbliża się do limitu.

Liczba równoległych budowań bywa ważniejsza od puli kredytów przy pracy zespołowej.

Po wyczerpaniu puli nie dzieje się nic automatycznie, i to jest ważniejsze, niż wygląda. Doładowanie jest domyślnie wyłączone, więc plan darmowy po prostu zatrzymuje się na twardym limicie, a na planach płatnych trzeba je najpierw włączyć: pięć dolarów za pięćset kredytów na planie osobistym, dziesięć dolarów za tysiąc pięćset na zespołowym. Kolejne równoległe budowanie jest osobnym dodatkiem za czterdzieści dolarów miesięcznie, więc kolejkę skraca się dopłatą, a nie zmianą planu. Jedno budowanie naraz oznacza, że przy trzech osobach wypychających zmiany kolejka rośnie, a podgląd wdrożenia pojawia się z opóźnieniem.

Przy szacowaniu kosztu warto policzyć trzy rzeczy osobno: liczbę wdrożeń produkcyjnych miesięcznie, spodziewany transfer i zużycie obliczeń. Kluczowa jest tu jedna zasada, którą łatwo przeoczyć: kredyty zużywają wyłącznie wdrożenia produkcyjne. Podglądy wdrożeń i budowania z gałęzi kosztują zero, więc aktywny zespół otwierający dziesiątki żądań scalenia nie płaci za nie ani kredyta. Największą pozycją okazuje się zwykle transfer, nie liczba budowań.

Funkcje i formularze

Poza hostowaniem plików platforma pozwala uruchomić kod po stronie serwera w dwóch wariantach.

Funkcje zwykłe działają jak klasyczne funkcje bezserwerowe: pełne środowisko, dostęp do bibliotek, uruchomienie w wybranym regionie. Funkcje brzegowe działają bliżej użytkownika, na ograniczonym środowisku, i nadają się do rzeczy szybkich: przekierowań warunkowych, testów porównawczych, personalizacji nagłówków.

export default async (request: Request) => {
  const kraj = request.headers.get('x-country')
  if (kraj === 'PL') return Response.redirect(new URL('/pl', request.url))
}

export const config = { path: '/' }

Osobną funkcją jest obsługa formularzy bez zaplecza. Formularz oznaczony atrybutem trafia do panelu, a platforma zajmuje się odbiorem, filtrowaniem niechcianych i powiadomieniem. To wystarcza do formularza kontaktowego i oszczędza całej warstwy serwerowej.

Granicą jest złożoność. Formularz wymagający walidacji zależnej od bazy, zapisu do systemu zewnętrznego albo przetworzenia pliku wykracza poza to rozwiązanie i wymaga własnej funkcji.

import type { Config, Context } from '@netlify/functions'

export default async (request: Request, context: Context) => {
  const dane = await request.formData()
  const email = String(dane.get('email') ?? '')

  if (!email.includes('@')) {
    return new Response('Niepoprawny adres', { status: 400 })
  }

  await zapiszZgloszenie({ email, kraj: context.geo.country?.code })
  return Response.json({ ok: true }, { status: 201 })
}

export const config: Config = { path: '/api/zgloszenie' }

Warto to sprawdzić przed obietnicą terminu, bo przejście z formularza wbudowanego na własny oznacza napisanie obsługi od zera. Obiekt kontekstu daje przy okazji dane o lokalizacji żądania bez pytania o nie użytkownika, co bywa wygodniejsze niż pole wyboru kraju w formularzu.

Przekierowania i nagłówki

Dwie rzeczy z pliku konfiguracyjnego zasługują na osobne omówienie, bo od nich zależy zarówno widoczność w wyszukiwarkach, jak i bezpieczeństwo.

Przekierowania obsługują zmianę struktury adresów, obsługę wielu języków i przepisywanie ścieżek na zaplecze. Kolejność ma znaczenie, bo pierwsza pasująca reguła wygrywa, a to najczęstsza przyczyna sytuacji, w której reguła dodana na końcu nie działa.

[[redirects]]
  from = "/stary-blog/*"
  to = "/blog/:splat"
  status = 301

[[redirects]]
  from = "/*"
  to = "/index.html"
  status = 200

Odwrócenie kolejności tych dwóch wpisów psuje wszystko. Reguła z gwiazdką na całą witrynę pasuje do każdego adresu, więc postawiona wyżej przechwyci również stary blog i przekierowanie na nową strukturę nigdy się nie wykona.

[[redirects]]
  from = "/api/*"
  to = "https://api.example.com/:splat"
  status = 200
  force = true

Status dwieście przy przekierowaniu oznacza przepisanie po stronie serwera, a nie przekierowanie widoczne dla przeglądarki. Adres w pasku zostaje ten sam, a treść pochodzi z innego miejsca. To rozwiązuje problem polityki pochodzenia bez konfigurowania nagłówków po stronie zaplecza.

Nagłówki bezpieczeństwa warto ustawić przy pierwszym wdrożeniu, bo później nikt do tego nie wraca. Zabezpieczenie przed osadzeniem strony w ramce, polityka bezpieczeństwa treści i wymuszenie połączenia szyfrowanego to trzy wpisy, które zajmują pięć minut.

[[headers]]
  for = "/*"
  [headers.values]
    X-Frame-Options = "DENY"
    X-Content-Type-Options = "nosniff"
    Referrer-Policy = "strict-origin-when-cross-origin"
    Strict-Transport-Security = "max-age=31536000; includeSubDomains"

[[headers]]
  for = "/assets/*"
  [headers.values]
    Cache-Control = "public, max-age=31536000, immutable"

Drugi wpis dotyczy czegoś innego niż bezpieczeństwo i jest równie warty ustawienia od razu. Pliki z nazwami zawierającymi skrót zawartości nigdy się nie zmieniają, więc mogą leżeć w pamięci podręcznej przeglądarki przez rok. Bez tego wpisu przeglądarka pyta o nie przy każdej wizycie.

Osobną sprawą jest strona błędu. Domyślna informacja o braku zasobu wygląda źle, a własna strona z linkiem do strony głównej i wyszukiwarką zatrzymuje część odwiedzających, którzy inaczej po prostu zamkną kartę. To kilkanaście minut pracy przy jednorazowym koszcie.

Netlify kontra alternatywy

Wybór między dwoma pierwszymi wierszami zależy od tego, w czym budujesz. Przy aplikacji w tym konkretnym frameworku integracja u jego twórców jest głębsza i część funkcji działa tam bez konfiguracji. Przy stronie w dowolnym innym narzędziu ta przewaga znika, a prostota pierwszego wiersza zostaje.

Trzeci wiersz warto rozważyć przy dużym ruchu, bo brak opłat za transfer zmienia rachunek zasadniczo. Cena za to jest w ograniczeniach środowiska uruchomieniowego, które przy prostej stronie nie boli, a przy aplikacji z zapleczem bywa odczuwalne.

Warto też pamiętać, że migracja między tymi platformami jest stosunkowo tania. Projekt zbudowany standardowymi narzędziami wdraża się wszędzie po zmianie kilku ustawień, a rzeczy specyficzne dla platformy sprowadzają się zwykle do jednego pliku konfiguracyjnego i formatu funkcji. To zmienia charakter decyzji: wybór na starcie nie musi być wyborem na lata.

Wyjątkiem są funkcje wykorzystujące mechanizmy dostępne tylko u jednego dostawcy: obsługa formularzy, magazyn na brzegu sieci, własny system uwierzytelniania. Każdy taki element dokłada pracy przy ewentualnym przeniesieniu, więc warto wiedzieć, ile ich masz.

Czas budowania i pamięć podręczna

Wdrożenie kosztuje tyle samo kredytów niezależnie od czasu budowania, więc bezpośredni koszt czasu jest zerowy. Pośredni już nie, bo długie budowanie oznacza późny podgląd i wolniejszą pracę zespołu.

Największy zysk daje pamięć podręczna zależności. Bez niej każde budowanie pobiera i instaluje wszystko od nowa, co przy dużym projekcie zajmuje kilka minut. Platforma robi to domyślnie dla popularnych menedżerów pakietów, natomiast przy nietypowej konfiguracji warto sprawdzić, czy faktycznie działa.

Drugą rzeczą jest zakres budowania. Projekt zawierający kilka aplikacji w jednym repozytorium buduje wszystko przy każdej zmianie, choć zmieniła się jedna. Ustawienie warunku pomijającego budowanie, gdy zmiany nie dotyczą danego katalogu, oszczędza czas i kredyty.

Trzecią jest generowanie stron. Strona z tysiącem podstron generowanych przy budowaniu potrafi budować się kwadrans, a odświeżanie przyrostowe albo generowanie na żądanie skraca to do minuty. To decyzja po stronie frameworka, nie platformy, ale wpływa na koszt tutaj.

Warto obserwować czas budowania jako liczbę, a nie wrażenie. Wzrost z dwóch minut do ośmiu następuje stopniowo i nikt go nie zauważa, dopóki ktoś nie porówna z zapisem sprzed pół roku.

Typowe błędy

Pierwszy to podglądy wdrożeń dostępne publicznie i indeksowane. Wyszukiwarka znajduje wtedy kopie strony pod adresami tymczasowymi, co szkodzi wynikom i pokazuje światu wersje niegotowe.

Drugi to mylenie liczby budowań z kosztem. Kredyty pobierają wyłącznie wdrożenia produkcyjne, więc zespół szacujący rachunek po liczbie zatwierdzeń wyjdzie z liczbą wielokrotnie zawyżoną, a i tak przeoczy transfer, który zwykle waży najwięcej.

Trzeci to sekrety w konfiguracji budowania zamiast w zmiennych środowiskowych. Plik konfiguracyjny leży w repozytorium, więc klucz wpisany tam widzi każdy, kto ma dostęp do kodu.

Czwarty to funkcje brzegowe użyte do zadań wymagających pełnego środowiska. Ograniczenia są realne, a błąd pojawia się dopiero po wdrożeniu, bo lokalnie wszystko działa.

Piąty to brak przekierowań po zmianie struktury adresów. Stare adresy zwracają wtedy błąd, a wyniki wyszukiwania zbudowane przez lata przepadają.

Szósty to poleganie na wbudowanej obsłudze formularzy przy rosnących wymaganiach. Rozwiązanie sprawdza się przy formularzu kontaktowym i kończy przy pierwszej potrzebie walidacji zależnej od danych.

Domeny i certyfikaty

Podłączenie własnej domeny sprowadza się do wskazania jej w panelu i ustawienia wpisów u dostawcy nazw. Certyfikat powstaje automatycznie i odnawia się sam, więc ta część przestaje być czymkolwiek do pilnowania.

Dwie decyzje warto podjąć świadomie. Pierwsza dotyczy tego, czy adres główny ma zawierać przedrostek. Obie wersje działają, ale jedna musi przekierowywać na drugą, inaczej wyszukiwarka widzi dwie kopie strony.

Druga dotyczy poddomen. Środowisko testowe pod osobną poddomeną jest wygodne i wymaga wykluczenia z indeksowania, bo inaczej wersja niegotowa konkuruje w wynikach z produkcyjną.

Przy przenoszeniu istniejącej domeny warto pamiętać o kolejności. Najpierw wdrożenie działające pod adresem tymczasowym i sprawdzone, potem zmiana wpisów u dostawcy nazw. Odwrotna kolejność oznacza kilka godzin, w których strona nie działa, bo stary serwer już nie odpowiada, a nowy nie ma jeszcze treści.

Ostatnia rzecz to czas propagacji. Zmiana wpisów rozchodzi się po sieci nawet kilkadziesiąt minut, więc sprawdzenie natychmiast po zmianie pokazuje stan sprzed niej i bywa źródłem niepotrzebnej paniki.

FAQ

Ile kosztuje Netlify?

Plan darmowy obejmuje trzysta kredytów miesięcznie, co wystarcza do projektu osobistego. Plany płatne zaczynają się od dziewięciu dolarów miesięcznie, a plan zespołowy kosztuje dwadzieścia dolarów za osobę i daje więcej kredytów oraz równoległych budowań.

Czym są kredyty?

To jednostka rozliczeniowa wprowadzona zamiast osobnych limitów transferu, minut budowania i wywołań funkcji. Każda czynność zużywa kredyty według własnej stawki, przy czym wdrożenie kosztuje tyle samo niezależnie od czasu budowania.

Netlify czy Vercel?

Vercel ma głębszą integrację z Next.js, bo jest tworzony przez ten sam zespół, więc przy aplikacji w tym frameworku część rzeczy działa tam bez konfiguracji. Przy stronie budowanej innym narzędziem różnice są niewielkie, a prostota i obsługa formularzy przemawiają za pierwszym.

Czy podglądy wdrożeń są bezpieczne?

Domyślnie są publiczne, więc przy treściach niegotowych do publikacji warto włączyć zabezpieczenie hasłem. Warto też wykluczyć je z indeksowania, bo inaczej wyszukiwarka znajdzie wiele kopii strony pod adresami tymczasowymi.

Czy da się uruchomić kod po stronie serwera?

Tak, w dwóch wariantach. Funkcje zwykłe dają pełne środowisko i nadają się do zadań wymagających bibliotek i dostępu do bazy. Funkcje brzegowe działają bliżej użytkownika na ograniczonym środowisku i sprawdzają się przy przekierowaniach i personalizacji.

Dokumentacja stoi na stronie projektu, a opis zmian w rozliczeniu znajdziesz we wpisie o planie darmowym.