Vercel, Render i klient w roli zakładnika

Coraz więcej firm nagle zaczyna płacić abonament w dolarach za stronę, która świetnie działała na opłaconym już hostingu. Zwykle nie dlatego, że tak trzeba - tylko dlatego, że ktoś wybrał jedyne narzędzie, jakie zna. Oto jak odróżnić sensowną migrację od niekompetencji i o co zapytać, zanim oddasz komuś dostęp do DNS.

Dostaję maila. Krótkiego, uprzejmego, napisanego przez kogoś, kto naprawdę chce dobrze:

„Potrzebujemy konkretnie dostępu do zarządzania rekordami DNS, żeby przekierować domenę, ponieważ hostujemy na Render."

Wszystko w tym zdaniu jest w porządku poza jednym: nikt nigdy nie zadał pytania dlaczego na Render. Strona firmowa działała na opłaconym hostingu współdzielonym. Ten hosting jest opłacony na rok z góry. Poczta firmowa stoi na tej samej domenie. A jednak nagle pojawia się nowa infrastruktura, nowy abonament, nowa faktura w dolarach i prośba o klucze do najbardziej krytycznego zasobu, jaki firma ma w internecie.

To nie jest tekst przeciwko Vercelowi ani przeciwko Renderowi. Oba są znakomite. To jest tekst o tym, co się dzieje, kiedy narzędzie zostaje wybrane nie dlatego, że jest właściwe, tylko dlatego, że jest jedynym, które ktoś zna.

Skąd się wzięła ta luka kompetencyjna

Kiedyś ścieżka wyglądała tak: FTP, katalog public_html, panel hostingu, rekord A, MX, plik .htaccess, backup bazy przez phpMyAdmin. Nudne, ręczne, ale zmuszało do zrozumienia, jak internet jest posklejany.

Dziś ścieżka wygląda tak: git push. Deploy dzieje się sam. Certyfikat SSL pojawia się sam. Domena podpina się kreatorem, który mówi „dodaj ten rekord". Wszystko działa, więc po co rozumieć.

Efekt jest przewidywalny: mamy pokolenie sprawnych deweloperów frontendu, którzy potrafią zbudować świetny produkt i nie mieli nigdy powodu, żeby dowiedzieć się, czym różni się rekord A od CNAME, dlaczego apeks domeny to inny problem niż subdomena, i co się stanie z pocztą, jeśli przepnie się serwery nazw.

To nie jest głupota. To luka w doświadczeniu. Problem zaczyna się dopiero wtedy, gdy tę lukę zaczyna finansować klient - abonamentem, przestojem albo utratą poczty.

Co realnie się psuje

1. Poczta pada w piątek po południu

Najczęstsza katastrofa migracji nie dotyczy strony, tylko maila. Scenariusz: deweloper, zamiast dodać dwa rekordy, przepina serwery nazw (NS) domeny na dostawcę hostingu aplikacji, bo tak było w tutorialu. Nowa strefa DNS startuje pusta. Rekordy MX, SPF, DKIM i DMARC - które istniały w starej strefie - przestają istnieć.

Strona działa. Poczta firmowa milczy. Klient dowiaduje się o tym w poniedziałek, kiedy kontrahent dzwoni z pytaniem, dlaczego nie odpowiadacie na oferty. Wiadomości z tego weekendu nie wracają - nadawcy dostali bounce.

Zasada: przy przenoszeniu samej strony NIE rusza się serwerów nazw. Zmienia się rekord A (lub ALIAS/ANAME dla apeksu) i CNAME dla www. Koniec. A jeśli już koniecznie przepinamy NS, to najpierw eksportujemy pełną strefę i odtwarzamy ją co do rekordu.

2. Apeks domeny to nie to samo co subdomena

Adres www.firma.pl można wskazać CNAME-em i to jest standardowa, bezproblemowa operacja. Firma.pl - apeks - CNAME-em wskazać się nie da, bo standard DNS na to nie pozwala (kolidowałoby z MX i NS). Zostaje rekord A na sztywny adres IP albo mechanizm ALIAS/ANAME/CNAME flattening, jeśli operator DNS go oferuje.

To jest dokładnie ten moment, w którym „proszę o adresy IP, na które mamy skierować rekordy A" bywa pytaniem, na które druga strona nie umie odpowiedzieć - bo dostawca PaaS podaje w panelu wartość CNAME i tyle.

3. Subdomeny giną po cichu

Firma ma zamowienia.firma.pl - panel B2B, formularz, integrację, cokolwiek. Migracja dotyczy „strony", więc nikt o subdomenie nie pomyślał. Jeśli operacja ograniczy się do zmiany dwóch rekordów, subdomena przeżyje. Jeśli obejmie przepięcie NS - zniknie razem z pocztą.

Przed każdą migracją: eksport całej strefy DNS do pliku i lista wszystkich rekordów z odpowiedzią, co się z każdym z nich dzieje. Jeden akapit roboty, oszczędza tydzień gaszenia pożarów.

4. Analityka i SEO resetują się do zera

GA4 nie jest przywiązane do serwera, tylko do tagu w kodzie. Nowa strona bez przeniesionego identyfikatora pomiaru to nowa, pusta historia. Do tego dochodzi mapowanie starych adresów URL na nowe, przekierowania 301, plik sitemap.xml, ponowna weryfikacja w Search Console i sprawdzenie, czy nowy build przypadkiem nie wypycha znacznika noindex z konfiguracji staging.

Strona wygląda lepiej, a ruch spada o 40%. Nikt nie łączy tych faktów przez trzy miesiące.

5. Rachunek, który nie miał się pojawić

Tu robi się konkretnie. Hosting współdzielony dla strony firmowej z pocztą to w Polsce zwykle 200-500 zł rocznie. Płatne za rok z góry, w złotówkach, z fakturą i polskim wsparciem.

Render i Vercel są znakomite, ale ich modele zaczynają się gdzie indziej. Darmowy plan Rendera usypia usługę po okresie bezczynności - pierwszy odwiedzający po nocy czeka kilkadziesiąt sekund na start kontenera. Dla strony firmowej to jest dyskwalifikujące, więc realnie schodzi się na plan płatny, per usługa, w dolarach. Baza danych to osobna pozycja. Vercel Pro rozlicza się per użytkownik miesięcznie, plus limity transferu i wywołań funkcji ponad pakiet.

Suma: firma, która płaciła kilkaset złotych rocznie, zaczyna płacić kilkaset złotych miesięcznie, za stronę o tej samej funkcjonalności. I dalej płaci za stary hosting, bo tam została poczta.

6. Kto właściwie jest właścicielem konta

Najbardziej niedoceniane ryzyko. Jeśli projekt stoi na Vercelu albo Renderze na koncie agencji, na jej karcie płatniczej, w jej repozytorium - to klient nie ma infrastruktury. Ma relację z agencją.

Rozstanie z wykonawcą przestaje być rozmową o rozliczeniu, a staje się operacją ratunkową. Widziałem to z bliska przy audytach: firma nie umie sama wykonać deployu własnej strony, bo cała wiedza i wszystkie dostępy są po drugiej stronie.

Kiedy Vercel i Render mają pełny sens

Żeby było jasne - nie jestem tu po stronie „wszystko na współdzielony hosting".

PaaS to właściwy wybór, gdy:

• aplikacja to Next.js, Nuxt lub SvelteKit z renderowaniem po stronie serwera, ISR, funkcjami brzegowymi - czyli rzeczy, których hosting współdzielony po prostu nie uruchomi;
• potrzebny jest CI/CD, preview deployments przy każdym pull requeście, rollback jednym kliknięciem;
• ruch jest zmienny i skalowanie ma realne znaczenie;
• zespół pracuje w kilka osób nad jednym kodem i wymaga środowisk staging;
• aplikacja potrzebuje kolejek, cronów, workerów, osobnych usług.

Hosting współdzielony wystarcza w zupełności, gdy:

• to strona wizytówkowa, katalog, blog, landing;
• treść zmienia się raz na kwartał;
• ruch jest przewidywalny i lokalny;
• i - to jest kluczowe - Next.js można wyeksportować statycznie. Opcja output: 'export' produkuje czysty zestaw plików HTML, CSS i JS, który wgrywa się na dowolny hosting przez FTP i który działa szybciej niż serwer renderujący, bo nic nie renderuje.

Ten ostatni punkt jest tym, o którym najczęściej nikt nie wspomina. Nowoczesny stack nie wymaga nowoczesnego abonamentu. Wymaga tylko wiedzy, jak go zbudować.

Pytania, które klient powinien zadać, zanim odda dostęp do DNS

Wydrukuj, powieś nad biurkiem, wyślij wykonawcy:

1. Dlaczego akurat ta platforma? Jakiej funkcji technicznej brakuje na hostingu, za który już płacimy?
2. Jaki będzie miesięczny koszt tej infrastruktury w pierwszym roku i po przekroczeniu limitów darmowego planu?
3. Na czyim koncie i na czyjej karcie będzie działać usługa? Czy możemy dostać ją na własne konto rozliczeniowe?
4. Czy planujecie zmieniać serwery nazw domeny, czy tylko rekordy A i CNAME?
5. Co się stanie z pocztą na tej domenie? Kto potwierdzi, że rekordy MX, SPF, DKIM i DMARC pozostają nietknięte?
6. Jakie subdomeny istnieją dziś i co się z każdą z nich stanie?
7. Czy mamy eksport całej strefy DNS przed zmianą?
8. Czy identyfikator GA4 i weryfikacja Search Console przechodzą na nową stronę?
9. Czy istnieje mapa przekierowań 301 ze starych adresów na nowe?
10. Jaki jest plan wycofania zmian, jeśli po przepięciu coś nie zadziała?
11. Czy repozytorium kodu jest nasze i czy mamy do niego dostęp?
12. Kto ma dostęp do panelu domeny i czy on się nie zmienia?

Jeśli na więcej niż trzy z tych pytań padnie odpowiedź „to sprawdzę", to jest wystarczający powód, żeby wstrzymać przepięcie do czasu sprawdzenia. Nie ma pośpiechu, którego wart jest tydzień bez poczty firmowej.

Krótka instrukcja dla wykonawcy

Bo połowa problemu jest po tej stronie i da się ją usunąć jednym rytuałem:

• Na 48 godzin przed migracją obniż TTL rekordów, które zmieniasz, do 300 sekund. Po udanej migracji podnieś z powrotem. Dzięki temu ewentualny rollback działa w kilka minut, a nie w dobę.
• Wyeksportuj strefę DNS i wklej ją do maila do klienta wraz z listą zmian: rekord po rekordzie, było i będzie.
• Nie ruszaj NS, jeśli przenosisz tylko stronę.
• Uruchom nową stronę pod tymczasowym adresem i przetestuj wszystko, zanim domena zacznie na nią wskazywać.
• Wykonaj przepięcie we wtorek rano, nie w piątek o siedemnastej.
• Zaproponuj klientowi konto na jego nazwisko i firmową kartę. To buduje zaufanie i chroni cię przed rolą zakładnika drugiej strony.
• Policz koszt i przedstaw go na piśmie, zanim klient zobaczy go na wyciągu. Zaskoczenie fakturą kosztuje więcej reputacji niż sama kwota.

Sedno

Problemem nigdy nie jest technologia. Problemem jest wybór dokonany bez alternatywy - bo jedyne środowisko, jakie ktoś zna, staje się automatycznie odpowiedzią na każde pytanie.

Klient tego nie zweryfikuje, bo nie ma jak. Widzi ładną stronę, słyszy „hostujemy na Render", ufa i klika. Rok później płaci abonament w dolarach za coś, co miał opłacone w złotówkach, i nie umie samodzielnie wgrać zmiany w stopce.

Dlatego jedyne pytanie, które warto zadać na starcie każdego projektu, brzmi: co konkretnie ta architektura daje temu biznesowi, czego nie daje ta, którą już opłaca?

Jeśli odpowiedź jest merytoryczna - świetnie, migrujmy, PaaS potrafi być tego wart. Jeśli odpowiedź brzmi „bo tak się teraz robi" - to nie jest decyzja architektoniczna. To jest przyzwyczajenie, za które ktoś inny płaci.

Prowadzisz firmę i nie masz pewności, czy Twoja infrastruktura jest ustawiona sensownie i czy dostępy są rzeczywiście Twoje? Audyt DNS, hostingu i kosztów to zwykle kilka godzin pracy i konkretna lista rzeczy do naprawienia. Napisz do mnie.