Konfiguracja własnej domeny dla aplikacji webowych: DNS, SSL i przełączenie

Co zmienia własna domena (i co może pójść nie tak)

Własna domena to więcej niż ładniejszy adres URL. W chwili, gdy przechodzisz z adresu platformy (np. aplikacji hostowanej na Koder.ai pod subdomeną platformy) na własną domenę, przeglądarki i sieci traktują to jako inną stronę. To wpływa na routing, bezpieczeństwo i zachowanie sesji użytkowników.

Po przełączeniu na własną domenę kilka rzeczy zmienia się od razu:

• Routing DNS: użytkownicy przestają trafiać na stary hostname i zaczynają docierać tam, gdzie wskazuje twój DNS.
• TLS/SSL: certyfikat musi pasować do nowych hostname’ów i musi być aktywny zanim przyjdą prawdziwi użytkownicy.
• Przekierowania: decydujesz, czy użytkownicy mają lądować na www czy na domenie apex, oraz musisz ustalić spójne reguły HTTP → HTTPS.
• Ciasteczka i sesje: ciasteczka są przypisane do domeny. Ciasteczko logowania dla old-platform.example nie zadziała automatycznie na app.yourdomain.com.
• Caching i propagacja: resolver’y DNS i przeglądarki cache’ują odpowiedzi, więc nie wszyscy przełączą się w tym samym momencie.

Krótko trwające przestoje zwykle wynikają z czasu. DNS może zacząć wysyłać ruch do nowego hosta zanim certyfikat SSL będzie gotowy — wtedy pojawiają się ostrzeżenia przeglądarki. Albo odwrotnie: SSL jest gotowy, ale wielu użytkowników wciąż trafia na stare miejsce z powodu nieodświeżonego cache’u DNS.

Przekierowania też potrafią subtelnie zepsuć logowania. Przekierowanie zmieniające hostname (apex ↔ www) może spowodować utratę ciasteczek, jeśli były ustawione dla innego hosta. Dostawcy tożsamości mogą zawieść, jeśli ich callback URL wciąż wskazuje starą domenę.

Przełączenie o niskim ryzyku oznacza planowanie nakładającego się okresu: utrzymaj działanie starego adresu, postaw nową domenę równolegle, przesuń ruch w przewidywalnym momencie i przygotuj prosty rollback polegający na przywróceniu DNS.

Zdecyduj o domenie i hostname’ach zanim ruszysz z DNS

Zanim cokolwiek zmienisz, zapisz dokładnie, jakie nazwy mają wpisywać użytkownicy i które nazwy mają cicho przekierowywać. Większość problemów typu „dlaczego to działa tylko częściowo?” bierze się z braku zgody w zespole co do jedynego prawdziwego hostname’u.

Zacznij od dużej decyzji: apex (example.com) czy www (www.example.com) jako główny. Oba warianty działają, ale wybierz jeden i traktuj drugi jako przekierowanie. To będzie ważne później dla ciasteczek: sesje są najprostsze, gdy aplikacja żyje na jednym spójnym hoście.

Następnie zdecyduj, jakie subdomeny są potrzebne teraz, a które mogą poczekać. Powszechny schemat to app.example.com dla aplikacji webowej i api.example.com dla API, z admin.example.com lub assets.example.com dodawanymi później. Jeśli konfigurujesz własną domenę na platformie takiej jak Koder.ai, wybory te mapują się bezpośrednio na to, co potwierdzisz dla SSL i co wskażesz w DNS.

Wiedz, kto naprawdę kontroluje DNS

Wiele osób kupuje domenę u rejestratora, ale DNS może być hostowany gdzie indziej. Potwierdź, gdzie dziś edytuje się rekordy, kto ma dostęp i czy zmiany są automatyzowane (IT firmy, agencja lub zarządzany dostawca DNS). Jeśli nie możesz się zalogować i zobaczyć aktualnych rekordów, zatrzymaj się i napraw to najpierw.

Przeprowadź też audyt tego, co już korzysta z domeny. Poczta to klasyczna pułapka: możesz przerwać dostarczanie, usuwając lub nadpisując rekordy.

Zanim pójdziesz dalej, zapisz te decyzje:

• Główny hostname (apex lub www) i kierunek przekierowania
• Wymagane subdomeny teraz (app, api, admin) vs pomysły na później
• Gdzie DNS jest hostowany i kto może publkować zmiany
• Istniejące krytyczne rekordy (MX, SPF, DKIM, DMARC, weryfikacyjne TXT)
• Oczekiwania dotyczące ciastek i auth (jeden host vs współdzielenie między subdomenami)

Jeśli marketing już obsługuje pocztę na example.com, pozostaw rekordy pocztowe bez zmian i dodaj tylko to, czego aplikacja potrzebuje.

Rekordy DNS, których użyjesz i dlaczego są ważne

Większość ryzyka przy przenoszeniu domeny nie dotyczy samej aplikacji. To jeden zły zapis DNS, który wysyła ruch donikąd, psuje pocztę lub uniemożliwia walidację SSL.

Podstawowe rekordy (A, CNAME i spółka)

A record wskazuje nazwę na adres IP. Mówiąc prościej: „wysyłaj ludzi do tego serwera”. Często używa się go dla domeny apex (example.com), gdy dostawca daje stałe IP.

CNAME record wskazuje jedną nazwę na inną nazwę. Mówiąc prościej: „traktuj tę nazwę jako alias tamtej nazwy”. Często używa się go dla www.example.com wskazującego na hostname platformy.

Wielu dostawców DNS oferuje też ALIAS/ANAME dla apex. Zachowuje się jak CNAME, ale działa dla example.com. Jeśli dostawca to wspiera, zarządzanie może być łatwiejsze, bo cel może się zmieniać bez ręcznej edycji IP.

Prosty model mentalny:

• A: nazwa -> IP (bezpośrednio)
• CNAME: nazwa -> nazwa (alias)
• TXT: nazwa -> tekst (dowód i polityki)
• MX: nazwa -> serwery pocztowe (nie ruszaj, jeśli nie chcesz przestać odbierać maili)

TXT: weryfikacja, SSL i bezpieczeństwo poczty

Często dodasz TXT do weryfikacji własności domeny (wymagane przez platformy) oraz dla walidacji certyfikatu SSL (niektóre CA walidują przez token w TXT). TXT służy też do polityk pocztowych, jak SPF. Przez przypadek usunięte lub nadpisane SPF TXT może zepsuć dostarczanie poczty.

TTL: pokrętło „szybkości zmian"

TTL kontroluje, jak długo inne systemy cache’ują odpowiedź DNS. Na dzień przed przełączeniem obniż TTL rekordów, które zamierzasz zmieniać (powszechnie 300–600 sekund). Po stabilizacji podnieś go znów, aby zmniejszyć obciążenie.

Unikaj nadpisywania istniejących rekordów i dokumentuj rollback

Zanim edytujesz, wyeksportuj lub zrób zrzut ekranu strefy DNS. Zapisz każdy rekord, który zmienisz: jego starą wartość, nową wartość i TTL. Jeśli coś pójdzie nie tak, rollback to przywrócenie poprzednich wartości.

To ma największe znaczenie, gdy domena już ma MX, DKIM lub inne TXT dla poczty.

Wydawanie SSL: walidacja, czas i zakres

SSL (kłódka) szyfruje ruch między przeglądarką a aplikacją. Współczesne przeglądarki i wiele API oczekuje HTTPS domyślnie. Bez tego możesz mieć ostrzeżenia, zablokowane żądania i brak działania pewnych funkcji (service workers, geolokalizacja, płatności).

Aby wystawić certyfikat, urząd certyfikacji musi potwierdzić, że masz kontrolę nad domeną. Typowe metody walidacji to HTTP i DNS TXT:

• HTTP validation: umieszcza się tymczasowy plik/odpowiedź pod określonym URL na aplikacji.
• DNS TXT validation: dodaje się rekord TXT do strefy DNS.

Walidacja przez DNS jest często łatwiejsza, gdy używasz CDN lub gdy aplikacja nie jest jeszcze osiągalna na nowej domenie.

Gdzie certyfikat jest wydawany zależy od twojego układu: niektórzy wystawiają certyfikaty w stacku hostingu, inni w CDN, a platformy obsługujące custom domains (np. Koder.ai) robią to za ciebie. Ważne jest, by wiedzieć, kto zarządza życiem certyfikatu, łącznie z odnawianiem.

Czas i ponowne próby

Wydawanie certyfikatu nie zawsze jest natychmiastowe. Propagacja DNS, sprawdzenia walidacji i limity żądań mogą spowolnić proces. Zaplanuj ponowne próby i nie ustawiaj przełączenia na ostatnią chwilę.

Praktyczny plan czasowy:

• Obniż TTL dzień wcześniej, aby zmiany szybciej się rozchodziły.
• Dodaj rekordy walidacyjne wcześnie (DNS TXT lub token HTTP).
• Poczekaj, aż certyfikat będzie wydany dla wszystkich hostname’ów.
• Dopiero wtedy skieruj ruch na nowy cel.

Zakres: upewnij się, że właściwe hosty są objęte

Certyfikat musi obejmować każdy hostname, na który użytkownicy będą trafiać. Sprawdź listę SAN (Subject Alternative Names). Jeśli aplikacja ma być dostępna zarówno na example.com, jak i www.example.com, certyfikat musi obejmować oba.

Wildcardy (np. *.example.com) pomagają dla wielu subdomen, ale nie obejmują domeny apex (example.com).

Konkretny przykład: jeśli wydasz certyfikat tylko dla www.example.com, użytkownicy wpisujący example.com zobaczą ostrzeżenia, chyba że przekierujesz je na warstwie, która ma ważny certyfikat dla example.com.

Reguły przekierowań: www, apex, HTTP -> HTTPS i bezpieczne domyślne ustawienia

Przekierowania brzmią prosto, ale tutaj pojawia się większość problemów domenowych: pętle, mixed content i wylogowania użytkowników z powodu odbijania między hostami.

Wybierz jeden host kanoniczny i trzymaj się go: www.example.com albo example.com (apex). Drugi punkt wejścia powinien przekierowywać na host kanoniczny, by ciasteczka, sesje i SEO pozostały spójne.

Bezpieczne domyślne ustawienia:

• Jeden host kanoniczny, z jednym 301 z drugiego hosta
• 301 z http:// na https:// dla każdego żądania
• Zachowuj pełną ścieżkę i query string podczas przekierowań (głębokie linki muszą działać)
• Przekierowanie tylko raz (unikaj łańcuchów http -> https -> www)

Dla HTTP -> HTTPS unikaj reguł, które odbijają użytkowników w kółko. Najprostszy sposób na uniknięcie pętli to podejmowanie decyzji na podstawie faktycznego żądania. Jeśli aplikacja stoi za proxy lub CDN-em, skonfiguruj go, aby respektował przekazywane nagłówki (np. nagłówek informujący, że oryginalny schemat był HTTP). W przeciwnym razie aplikacja może myśleć, że każde żądanie jest HTTP i ciągle przekierowywać.

Podczas migracji utrzymuj stare ścieżki przy życiu. Jeśli zmieniasz trasy (np. /login -> /sign-in), dodaj explicite przekierowania dla tych ścieżek. Nie polegaj na zbiorczym przekierowaniu do strony głównej — złamie to zakładki i linki.

Wstrzymaj się z HSTS na początku. Jeśli włączysz go za wcześnie, a potem będziesz musiał serwować HTTP dla walidacji lub debugowania, przeglądarki mogą odmówić połączenia. Poczekaj, aż HTTPS będzie stabilny i potwierdź pokrycie subdomen.

Aby przetestować przekierowania bez wpływu na wszystkich, użyj tymczasowego testowego hostname’a, sprawdź kilka głębokich linków (w tym strony auth) i uruchom żądanie z linii poleceń, które pokaże każdy krok przekierowania i finalne miejsce docelowe.

Krok po kroku: plan bezpiecznego przełączenia (bez przestojów)

Bezpieczne przełączenie to w dużej mierze kwestia czasu. Chcesz, aby nowa domena była gotowa i przetestowana zanim trafi do niej prawdziwy ruch, oraz aby zmiany DNS rozchodziły się szybko, żeby nie czekać w trakcie incydentu.

1) Przygotuj i przetestuj zanim dotkniesz produkcyjnego DNS

Obniż TTL rekordów, które zmienisz, z wyprzedzeniem. Zrób to dzień wcześniej, jeśli możesz, i poczekaj aż minie poprzedni okres TTL, żeby cache’y zdążyły się zaktualizować.

Dodaj najpierw domenę w hostingu/dostawcy i wykonaj wymaganą weryfikację. Jeśli używasz platformy takiej jak Koder.ai, dodaj domenę tam najpierw, aby platforma mogła potwierdzić własność i przygotować routing.

Wystaw SSL wcześniej. Certyfikaty mogą trwać kilka minut lub dłużej w zależności od metody walidacji i ograniczeń.

Zanim udostępnisz domenę publicznie, zrób prywatny test: trafić na nowy endpoint w sposób niezależny od publicznego DNS (np. wpisując tymczasowy wpis w /etc/hosts) i potwierdzić, że strona ładuje się przez HTTPS z właściwym certyfikatem.

2) Przełączaj w małych, odwracalnych krokach

Stosuj podejście etapowe, aby móc szybko zatrzymać się, jeśli coś pójdzie nie tak:

• Obniż TTL z wyprzedzeniem, potem poczekaj, aż stary okres TTL upłynie.
• Ukończ weryfikację domeny u hosta i potwierdź, że domena wewnętrznie wskazuje na właściwą aplikację.
• Potwierdź, że SSL jest aktywny dla każdego hostname’u, zanim przełączysz użytkowników.
• Zmieniaj DNS kontrolowanie: zacznij od subdomeny, małego regionu lub ograniczonej grupy użytkowników, jeśli to możliwe.
• Trzymaj starą domenę online i przekierowującą, obserwując stabilizację ruchu i wskaźników błędów.

Jeśli nie możesz wykonać prawdziwego canary na poziomie DNS, możesz etapować przez zmianę tylko jednego hostname’u najpierw (np. www), a domenę apex zostawić, dopóki nie nabierzesz pewności.

3) Zaplanuj rollback póki jesteś spokojny

Zapisz dokładnie, co przywrócisz (które rekordy, jakie wartości) i kto to zrobi. Rollback to z reguły przywrócenie DNS do poprzedniego stanu.

Upewnij się, że stary setup jest nadal ważny (łącznie z SSL), aby użytkownicy mogli wrócić bezproblemowo, podczas gdy naprawiasz nową ścieżkę.

Jak unikać zepsutych ciastek, sesji i auth po zmianie

Zmiana domeny to nie tylko DNS. Dla wielu aplikacji „bycie zalogowanym” zależy od ciasteczek przypisanych do konkretnego hostname’u. Jeśli zmienisz hostname, przeglądarka może przestać wysyłać stare ciasteczka i aplikacja będzie wyglądać, jakby wszystkich wylogowała.

Ustawienia ciastek to zwykle przyczyna:

• Domain decyduje, które hosty otrzymają ciasteczko. Ciasteczko dla app.old.com nie zostanie wysłane do app.new.com. Ciasteczko ustawione dla .example.com zadziała między app.example.com i www.example.com.
• Path ogranicza, gdzie ciasteczko jest wysyłane. Jeśli zbyt wąskie (np. /api), UI może go nie widzieć.
• Secure oznacza, że ciasteczko jest wysyłane tylko przez HTTPS. Po przejściu na HTTPS-only żądania HTTP nie będą go zawierać.
• SameSite wpływa na przekierowania cross-site i osadzone przepływy. Lax często wystarcza, ale niektóre SSO lub płatności wymagają None i Secure.

Aby zmniejszyć ryzyko, zaplanuj krótki okres przejściowy, w którym oba hosty działają. Trzymaj stary hostname odpowiadający i przekierowujący, ale pozwól sesjom odświeżyć się na nowej domenie. Jeśli to możliwe, użyj współdzielonego store’a sesji, żeby użytkownik trafiający na którykolwiek hostname był rozpoznawany.

Jeśli korzystasz z SSO lub OAuth, zaktualizuj ustawienia przed przełączeniem: callback URLs, dozwolone pochodzenia i allowlisty redirect URI. W przeciwnym razie logowania mogą się powieść u providera tożsamości, ale zbankrutować przy powrocie do aplikacji.

Przetestuj przepływy, które zwykle zawodzą jako pierwsze: rejestrację (i weryfikację mailową), logowanie/wylogowanie, reset hasła, powrót z płatności i sesje w wielu kartach.

Przykład: jeśli przekierowujesz www.example.com na example.com, upewnij się, że ciasteczka są ustawione dla .example.com (albo używaj konsekwentnie jednego hostname’u). W przeciwnym razie użytkownicy będą odbijani między hostami i tracili sesję.

Najczęstsze błędy powodujące przestoje lub dziwne zachowanie

Większość problemów domenowych to nie „tajemnicze błędy internetu”. To drobne niezgodności między DNS, certyfikatami i regułami przekierowań, które wychodzą na jaw, gdy prawdziwi użytkownicy trafiają na serwis.

Jedną prostą pułapką jest domena apex (example.com). Wielu dostawców DNS nie pozwala na prawdziwy CNAME na apex. Jeśli spróbujesz wymusić CNAME na apex, może to działać nieregularnie, zawodzić cicho lub łamać się tylko w niektórych sieciach. Używaj tego, co wspiera twój DNS (często A/AAAA lub ALIAS/ANAME).

Inną częstą przyczyną przestojów jest zmiana DNS zanim SSL będzie gotowy na nowym endpointcie. Użytkownicy przychodzą, aplikacja ładuje się, a potem przeglądarka blokuje połączenie, bo certyfikat brak lub nie obejmuje wszystkich hostname’ów. W praktyce warto, żeby certyfikat obejmował oba: example.com i www.example.com, nawet jeśli planujesz przekierować jeden na drugi.

Typowe błędy tworzące przestoje lub dziwne zachowanie:

• Zmiana DNS bez wcześniejszego obniżenia TTL i czekania na wygaśnięcie starych odpowiedzi
• Pozostawienie reguł, które tworzą pętle (www -> apex, potem apex -> www), albo wymuszanie HTTP w jednym miejscu i HTTPS w innym
• Wysyłanie mixed content przez hardkodowanie http:// zasobów, co wywołuje ostrzeżenia przeglądarki
• Zapominanie o rekordach niewebowych, szczególnie MX i TXT, co może złamać pocztę i weryfikacje
• Testowanie tylko w jednej przeglądarce i pomijanie cache’ów HSTS lub problemów z ciasteczkami, które inni użytkownicy napotkają

Szybkie sprawdzenie: otwórz oba hosty (www i apex) przez HTTPS, zaloguj się, odśwież i potwierdź, że pasek adresu nigdy nie wraca do HTTP.

Jeśli robisz to na platformie takiej jak Koder.ai, upewnij się, że custom domains są połączone i SSL jest wydany zanim zmienisz produkcyjne DNS, i miej gotowy plan rollback, żeby złe przekierowanie lub rekord nie wisiało długo.

Szybka lista kontrolna przed, w trakcie i po przełączeniu

Spokojne przełączenie to w dużej mierze praca przygotowawcza. Cel jest prosty: użytkownicy powinni pozostać zalogowani, ciasteczka działać, a ty musisz mieć możliwość szybkiego rollbacku, jeśli coś pójdzie nie tak.

Przed przełączeniem

Wykonaj to, gdy ruch nadal idzie do starej domeny. Daj sobie dzień, jeśli możesz, aby zmiany DNS miały czas się rozpropagować.

• Obniż TTL dla rekordów, które zamierzasz zmieniać, i zapisz bieżące wartości, aby móc je szybko przywrócić.
• Udokumentuj każdy hostname, który będziesz obsługiwać (apex, www, api itp.) i wybierz metodę walidacji SSL (DNS lub HTTP).
• Przygotuj reguły przekierowań i przetestuj je w staging: HTTP -> HTTPS, www -> apex (lub odwrotnie), i jeden host kanoniczny.
• Zaktualizuj ustawienia auth zależne od dokładnych URL: callbacky OAuth, dozwolone pochodzenia, ustawienia domen ciasteczek i konfiguracje SSO.
• Zdecyduj, kto obserwuje co podczas przełączenia (logi, checks, inbox wsparcia) i ustaw krótki okienko na zmiany.

W trakcie i po przełączeniu

Gdy zmieniasz DNS, traktuj pierwszą godzinę jak ćwiczenie na wypadek incydentu. Obserwuj rzeczywiste przepływy użytkowników, nie tylko panele statusu.

• W trakcie: monitoruj skoki 4xx/5xx, pętle przekierowań i błędy logowania (szczególnie „invalid redirect URI” lub nagłe utraty sesji).
• Po: potwierdź łańcuch certyfikatów w różnych przeglądarkach i że ważne strony ładują się przez HTTPS bez mixed content.
• Po: potwierdź zachowanie hosta kanonicznego (tylko jeden host widoczny w pasku adresu) i że krytyczne ciasteczka są ustawione i wysyłane.
• Po: trzymaj stary domain redirectujący przez jakiś czas. Wielu użytkowników wróci przez stare zakładki, maile lub cache’owane linki.

Nawet jeśli Koder.ai (lub inna platforma) obsługuje custom domains i SSL za ciebie, ta lista kontrolna wciąż ma znaczenie. Większość problemów pochodzi z DNS i przekierowań, nie z kodu aplikacji.

Przykładowy scenariusz: przenosiny z adresu platformy na własną domenę

Twoja aplikacja działa pod tymczasowym adresem platformy, np. myapp.koder.ai. Działa, ale chcesz, żeby klienci używali example.com, z www.example.com przekierowującym na apex i wszystkim wymuszonym na HTTPS.

Prosty plan DNS utrzyma ryzyko niskie. Zanim cokolwiek zmienisz, zanotuj bieżący działający stan (zrób snapshot, jeśli platforma to wspiera, jak Koder.ai) i obniż TTL na krótko przed zmianą.

Dodaj nowe rekordy, zostawiając istniejący adres platformy bez zmian:

• example.com: rekord A/ALIAS wskazujący na cel hostingu podany przez platformę
• www.example.com: CNAME wskazujący na example.com (lub na cel platformy, zależnie od dostawcy)
• Zachowaj myapp.koder.ai bez zmian, by mieć zawsze znany, działający fallback

Gdy DNS jest skonfigurowany, poproś o SSL dla obu hostname’ów (example.com i www.example.com). Nie przekierowuj ruchu, dopóki certyfikat nie zostanie wydany i nie będzie aktywny — w przeciwnym razie użytkownicy zobaczą ostrzeżenia.

Harmonogram przełączenia z punktami kontrolnymi:

• T-24h: obniż TTL, potwierdź możliwość szybkiego rollbacku
• T-0: włącz domenę w hostingu aplikacji, zweryfikuj, że SSL jest gotowy
• T+15m: przetestuj example.com w trybie incognito (strona główna, zasoby statyczne, wywołania API)
• T+30m: włącz przekierowania (HTTP -> HTTPS oraz www -> apex)
• Moment rollbacku: jeśli logowania lub wywołania API zawodzą, przywróć DNS do poprzedniego celu i trzymaj adres platformy aktywny

Po zmianie sprawdź zachowanie ciasteczek. Zaloguj się, odśwież i upewnij się, że sesja jest zachowana zarówno na www, jak i na apex. Jeśli sesje zawodzą, zwykle winne jest ustawienie domeny ciasteczka lub SameSite, które wciąż zakładają stary host.

Następne kroki: monitoruj, dokumentuj i upraszczaj przyszłe zmiany

Po udanym przełączeniu praca się nie kończy. Większość problemów pojawia się później, gdy nikt nie zauważy: certyfikat zbliża się do wygaśnięcia, ktoś robi pośpieszny update DNS, albo zmiana przekierowania psuje logowanie.

Ustal prostą rutynę monitoringu, której rzeczywiście będziesz się trzymać. Nie potrzebujesz narzędzia klasy enterprise, ale potrzebujesz kilku wiarygodnych sygnałów: kontrole dostępności kluczowych stron (strona główna, logowanie i jedna strona wymagająca autoryzacji), alerty o wygasaniu certyfikatu (np. 30 dni i 7 dni przed), śledzenie wskaźników błędów (sprawdzaj skoki 4xx/5xx, nie tylko uptime) oraz okresowe walidacje przekierowań (HTTP powinien iść na HTTPS, a preferowany host wygrywa).

Przez 24–72 godziny trzymaj przygotowany rollback (stare cele DNS, starą konfigurację hostingu, stare ustawienia TLS), aby móc szybko cofnąć się, jeśli wyjdzie ukryty problem, np. callback płatności lub dostawca OAuth nadal wskazujący starą domenę.

Gdy poczujesz się pewnie, podnieś TTL z powrotem. Niskie TTLy są użyteczne podczas zmian, ale zwiększają obciążenie resolverów i potęgują wpływ drobnych błędów później. Wybierz normalny TTL odpowiadający częstotliwości zmian (wiele zespołów wybiera 1–4 godziny).

Na koniec, udokumentuj finalny stan, póki jest świeżo: jakie rekordy istnieją (typ, nazwa, wartość, TTL), jakie hostname’y są obsługiwane i dokładne reguły przekierowań. Dołącz informacje, gdzie wystawiane są certyfikaty, co obejmują (apex, www, subdomeny) i kto odpowiada za odnowienia.

Jeśli budujesz i wdrażasz na platformie, warto, by domeny były traktowane jako funkcja pierwszorzędna, z prostym rollbackem. Na Koder.ai custom domains siedzą obok snapshotów i rollbacku, co ułatwia przyszłe zmiany i szybkie cofnięcie, gdy trzeba.