Jeśli Twoją stronę firmową zbudowano w Astro, w 2026 roku wydarzyły się wokół niej dwie rzeczy, o których wykonawca mógł Ci nie wspomnieć. Po pierwsze, 16 stycznia twórcy tego narzędzia dołączyli do Cloudflare — firmy, która najpewniej hostuje Twoją stronę albo przynajmniej ją chroni. Po drugie, 10 marca wyszła wersja 6, która podniosła minimalne wymagania techniczne i usunęła kilka funkcji, na których opierały się starsze strony.
Dobra wiadomość jest taka, że żadna z tych zmian nie wymusza pilnego działania na działającej stronie. Pokazujemy, co dokładnie ogłoszono, co wynika z dokumentacji, a co jest na razie domysłem — i jak wygląda rozsądna rozmowa z osobą, która Twoją stronę utrzymuje.
1. Czym jest Astro i dlaczego temat dotyczy też Ciebie
Astro to narzędzie (programiści mówią: framework), z którego buduje się strony internetowe. Najłatwiej porównać je do warsztatu stolarskiego: Ty widzisz gotowy mebel — stronę — a wykonawca używa maszyn, które mają swoje wersje, wymagania i producenta. Gdy producent maszyn zmienia właściciela albo wydaje nową generację, ma to znaczenie dla serwisu, a pośrednio dla rachunku, który dostajesz.
Astro jest nastawione na strony z treścią: firmowe, blogowe, dokumentacje. Większość podstrony to zwykły, szybki plik, który nie wymaga bazy danych ani panelu logowania wystawionego w internecie. Dlatego narzędzie jest popularne wśród wykonawców, którzy chcą dostarczyć tanią w utrzymaniu stronę. Pisaliśmy o tym szerzej w tekście Astro vs WordPress — kiedy mała firma powinna migrować stronę w 2026. Tamten artykuł dotyczył decyzji „czy w ogóle zmieniać silnik”. Ten dotyczy czegoś innego: co się dzieje, gdy wybrane narzędzie zmienia właściciela i wersję.
Dla właściciela firmy liczą się trzy pytania:
- czy narzędzie nie zniknie albo nie stanie się płatne,
- czy strona nadal będzie dostawać poprawki bezpieczeństwa,
- czy aktualizacja nie zepsuje czegoś, za co zapłacisz drugi raz.
Na wszystkie trzy odpowiadamy niżej, opierając się na dokumentach samych twórców.
2. Przejęcie przez Cloudflare — co ogłoszono, a czego nie
Zespół stojący za Astro — The Astro Technology Company — dołączył do Cloudflare. Ogłoszenie ukazało się 16 stycznia 2026 roku na blogu Cloudflare. Najważniejsze, co w nim stoi, tłumaczymy poniżej.
Astro pozostanie otwartym oprogramowaniem na licencji MIT, otwartym na wkład społeczności, z publiczną mapą drogową i otwartym zarządzaniem. Wszyscy etatowi pracownicy The Astro Technology Company są teraz pracownikami Cloudflare i nadal pracują nad Astro. — Cloudflare Blog, „Astro is joining Cloudflare”, 16 stycznia 2026
W tym samym tekście Cloudflare zapewnia, że Astro nadal ma działać na dowolnej platformie i w dowolnej chmurze, a nie tylko u niego. To ważne, bo najczęstszy lęk przy takich transakcjach brzmi: „czy teraz będę zmuszony do jednego dostawcy”. Deklaracja jest jednoznaczna, że nie. Licencja MIT oznacza przy okazji, że kod można swobodnie używać i kopiować — jeśli kiedyś projekt wyjdzie z obiegu, strona i tak się nie zepsuje, bo narzędzie, na którym stoi, nadal istnieje w postaci kodu.
Czego w ogłoszeniu nie ma? Nie ma w nim warunków finansowych ani planu płatnych wersji. Wszelkie przewidywania, że „za rok coś zostanie zamknięte w Cloudflare”, są dziś domysłami, nie faktami. Nie ma też obietnicy, że wszystkie funkcje zawsze będą działać tak samo dobrze poza infrastrukturą Cloudflare. Są natomiast widoczne sygnały kierunku: w tekście autorzy piszą, że wersja 6 przynosi ulepszone wsparcie dla środowiska Cloudflare (wg bloga Astro), o czym w następnym rozdziale.
Dlaczego Cloudflare chciał tego zespołu
Z ogłoszenia wynika, że Astro już wcześniej było w centrum kilku usług działających na infrastrukturze Cloudflare. Autorzy wymieniają platformy Webflow Cloud i Wix Vibe: według ich opisu, gdy publikujesz stronę w Webflow Cloud, strona oparta na Astro trafia do sieci Cloudflare, a nowy projekt założony w Wix Vibe jest pod spodem właśnie stroną Astro uruchomioną na Cloudflare. Sam Cloudflare przyznaje też, że używa Astro do własnej dokumentacji dla programistów, strony głównej, bloga i stron lądowania. Jako użytkowników narzędzia autorzy podają również firmy znane z innych branż, wśród nich Porsche i IKEA.
Dla właściciela firmy płynie z tego jeden wniosek: to połączenie ma uzasadnienie w istniejącej praktyce, a nie jest ruchem czysto finansowym. Producent maszyn przejęty przez dużego dostawcę, który sam z tych maszyn korzysta, ma większą motywację, żeby je rozwijać, niż producent, którego nikt duży nie używa. Nie jest to gwarancja — to rozsądna przesłanka, którą zapisujemy jako przesłankę, nie jako fakt.
Co to oznacza praktycznie? Jeśli strona stoi już na Cloudflare Pages, jak nasza, przejęcie raczej wzmacnia ten układ. Jeśli stoi gdzie indziej, nie ma powodu do przeprowadzki. Porównanie platform hostingowych znajdziesz w artykule Cloudflare Pages vs Vercel vs Netlify 2026 — ta decyzja zależy od kosztów i potrzeb, nie od tego, kto jest właścicielem Astro.
3. Astro 6 — co nowego, tłumaczone na język właściciela
Wersja 6 została opublikowana 10 marca 2026 roku, co opisano na blogu Astro. Lista zmian jest długa i w większości dotyczy wykonawcy. Wybraliśmy te, które dotykają również Ciebie.
1. Programista testuje stronę w warunkach zbliżonych do prawdziwych
Twórcy przebudowali lokalne środowisko pracy programisty. Według ich opisu pozwala ono uruchamiać stronę w tym samym środowisku, w którym działa na serwerze, dzięki czemu mniej jest sytuacji typu „u mnie działało, a po wdrożeniu nie”. Dla Ciebie to mniej niespodzianek po publikacji zmian.
2. Wbudowana obsługa czcionek
Astro 6 ma wbudowany mechanizm czcionek: pobiera pliki, zapisuje je na własnym serwerze strony, przygotowuje zapasowe warianty na czas ładowania i dodaje podpowiedzi przyspieszające wczytanie. Twórcy wprost podają, że chodzi o szybkość i prywatność użytkowników. To ma związek z tematem, który opisywaliśmy w tekście Google Fonts na stronie firmowej — ryzyko RODO — tam opisujemy, dlaczego ładowanie czcionek z cudzych serwerów bywa problemem, a Astro 6 daje wbudowany sposób na hostowanie ich u siebie.
3. Wbudowane nagłówki bezpieczeństwa (CSP)
CSP (Content Security Policy) to zestaw reguł, który mówi przeglądarce: „na tej stronie wolno uruchamiać skrypty tylko z tych źródeł”. Chroni przed wstrzyknięciem obcego kodu. Autorzy Astro 6 informują, że obsługa CSP jest stabilna i włącza się jedną flagą — narzędzie samo liczy odciski wszystkich skryptów i stylów na stronie. Dla właściciela to praktyczna korzyść: zabezpieczenie, które twórcy nazywają zaskakująco trudnym we wdrożeniu, staje się opcją w ustawieniach.
4. Zawartość odświeżana bez przebudowy strony
Tak zwane żywe kolekcje treści (Live Content Collections) są w wersji 6 stabilne. W opisie Cloudflare przykładem jest aktualny stan magazynu w sklepie: dane można pobierać przy każdym wejściu, bez przebudowywania całej strony. Dotyczy to tylko tych stron, które takiej świeżości potrzebują. Zwykła strona firmowa z ofertą i kontaktem nie zyska z tego nic.
5. Eksperymentalny nowy kompilator
Twórcy dodali też wersję eksperymentalną nowego kompilatora napisanego w języku Rust, który ma być szybszy. Sami podkreślają, że to wczesny etap. Wykonawca nie powinien używać go na produkcyjnej stronie klienta bez własnych testów — sam napis „eksperymentalny” wystarcza jako sygnał.
4. Co się zepsuje przy aktualizacji — i dlaczego strona stoi dalej
Zmiany, które przy aktualizacji mogą kosztować pracę, zebrano w oficjalnym przewodniku migracji do wersji 6. Najważniejsze dla zamawiającego:
Wymagany nowszy Node. Node to środowisko, w którym uruchamiają się narzędzia budujące stronę — czyli „silnik maszyny”, a nie sama strona. Astro 6 wymaga Node w wersji 22.12.0 lub nowszej. Według dokumentacji Astro wersja 18 przestała być wspierana w marcu 2025, a wersja 20 w kwietniu 2026 roku. Strona Node.js Releases pokazuje 20 jako zakończoną (EOL — koniec wsparcia), a 22 jako wersję z długoterminowym wsparciem (LTS). Praktycznie oznacza to, że ktoś musi sprawdzić, jaka wersja pracuje zarówno na komputerze programisty, jak i w środowisku, które buduje stronę przy publikacji. Ustawienie wersji zwykle jest jedną opcją w panelu hostingu albo jedną linijką w projekcie.
Usunięte funkcje. Przewodnik wymienia m.in. usunięcie dawnych kolekcji treści w trybie zgodności wstecznej, komponentu <ViewTransitions /> oraz funkcji Astro.glob(). Jeśli strona korzystała z nich, wykonawca musi je zastąpić nowszymi odpowiednikami. To praca jednorazowa, ale nie darmowa.
Zmiany w bibliotekach. Według dokumentacji Astro 6 używa nowszych wersji Vite 7 i Zod 4. Jeśli projekt przypina własną wersję Vite, trzeba ją podnieść przed aktualizacją. Dla zamawiającego to szczegół, ale warto go znać, żeby zrozumieć wycenę.
Zmiany w łączniku do Cloudflare. Dokument migracyjny mówi wprost, że oficjalny adapter do Cloudflare przeszedł „istotne zmiany”, a w istniejących konfiguracjach należy spodziewać się zmian niezgodnych wstecz. Dotyczy to stron, które wykorzystują funkcje po stronie serwera, jak formularze, API czy renderowanie na żądanie. Czysto statyczna strona jest tym dotknięta mniej.
Ostrzeżenie: aktualizację głównej wersji (z 5 na 6) rób najpierw na kopii strony i na osobnej gałęzi w repozytorium, nie na produkcji. Zmiany niezgodne wstecz wychodzą dopiero przy budowaniu i testowaniu, a nie przy samym uruchomieniu polecenia aktualizacji.
Czy to oznacza dodatkowe koszty? Narzędzie jest darmowe na licencji MIT, więc sama aktualizacja nie kosztuje licencji. Koszt to czas osoby, która ją wykona i przetestuje. Jego wielkość zależy od trzech rzeczy: ile funkcji po stronie serwera ma strona, czy korzystała z usuniętych elementów i czy środowisko budowania wymaga zmiany wersji Node. Dlatego rozsądna wycena nie jest jedną kwotą „za aktualizację do szóstki”, tylko rozpisaniem tych trzech składników. Jeżeli wykonawca podaje cenę bez pytania o te elementy, ma ona niewiele wspólnego z rzeczywistą pracą — to sygnał do dopytania, nie do sprzeczki.
Dlaczego strona stoi dalej? Wersja 5 nie przestaje działać w dniu premiery wersji 6. Zbudowane i opublikowane pliki są zwykłymi plikami — przeglądarka nie wie ani nie dba, w jakim narzędziu je zrobiono. Ryzyko leży gdzie indziej: narzędzia starszej generacji z czasem przestają dostawać poprawki, a hosting może zmienić domyślną wersję Node. O terminie, do którego Astro 5 będzie jeszcze poprawiane, nie znaleźliśmy w dokumentach twórców konkretnej deklaracji, dlatego nie podajemy żadnej daty — to pytanie do wykonawcy albo do dokumentacji projektu.
5. Pięć pytań do osoby, która utrzymuje Twoją stronę
Zamiast uczyć się technikaliów, zadaj wykonawcy pięć pytań. Dobre odpowiedzi są krótkie i konkretne.
- Na jakiej wersji Astro jest moja strona? Powinna to być liczba, np. „5.x” lub „6.x”. Odpowiedź „nie wiem” oznacza brak kontroli nad utrzymaniem.
- Jaka wersja Node jest ustawiona w środowisku, które buduje stronę przy publikacji? Jeśli to 18 albo 20, to wersje po terminie wsparcia — według informacji Astro i strony Node.js.
- Czy strona używa funkcji po stronie serwera (formularze, własne API, logowanie)? Jeśli tak, aktualizacja będzie większa i wycena się zmieni. Jeśli jest czysto statyczna, jest tańsza.
- Czy aktualizacja jest w zakresie umowy utrzymaniowej, czy to osobne zlecenie? Rozstrzygnij to przed pracą, nie po niej.
- Czy po aktualizacji wykonacie test formularzy, mapy, szybkości i dostępności? Zmiany wersji frameworka dotykają miejsc, które trudno zauważyć bez sprawdzenia.
Każde z tych pytań ma też drugą stronę: zapisz odpowiedzi. Za rok, gdy będziesz zmieniać wykonawcę, rozmawiać z audytorem albo planować większą przebudowę, taka jednostronicowa notatka — wersja narzędzia, wersja Node, miejsce hostingu, lista funkcji po stronie serwera — oszczędzi Ci kilku godzin płatnego odtwarzania stanu strony od zera.
Jeśli wykonawca odpowiada na te pytania bez wahania, strona jest w dobrych rękach. Jeśli się plącze, masz informację, której potrzebowałeś, bez czytania dokumentacji.
Kiedy NIE ruszać działającej strony
Nie każda nowa wersja to powód do działania. Oto sytuacje, w których rozsądnie jest poczekać:
- Strona jest statyczna, działa, a środowisko budowania ma Node 22 lub nowszy — brak pilnej potrzeby.
- Zbliża się duża kampania, Black Friday albo sezon — aktualizacja frameworka tuż przed szczytem ruchu to niepotrzebne ryzyko. Wpływ szybkości i stabilności strony przed szczytem sezonu omawiamy w tekście Strona firmowa przed Q4.
- Wykonawca nie ma czasu na pełne testy — lepiej przesunąć niż robić na szybko.
Natomiast jeśli środowisko budowania działa na Node 20 lub starszym, a strona ma być aktualizowana, ta kwestia powinna wejść na listę zadań na najbliższy kwartał.
Jak my to robimy
W Monaltro własną stronę prowadzimy na Astro i Cloudflare Pages. Zmianę głównej wersji traktujemy jak osobny projekt: osobna gałąź, sprawdzenie wersji Node w środowisku budowania, przegląd listy usuniętych funkcji z przewodnika migracji i test wszystkiego, co działa po stronie serwera, zanim cokolwiek trafi na produkcję. Nie spieszymy się z aktualizacją „tylko dlatego, że wyszła” — nowa wersja wchodzi, gdy mamy czas ją przetestować i gdy przynosi coś, czego strona potrzebuje, na przykład wbudowane nagłówki bezpieczeństwa albo hostowanie czcionek. Jeśli chcesz sprawdzić, w jakim stanie jest Twoja strona, chętnie podpowiemy, od czego zacząć.
Podsumowanie
Przejęcie Astro przez Cloudflare nie zmienia licencji ani zasady „działa wszędzie” — tak deklarują sami zainteresowani, a plan komercyjny nie został ujawniony. Astro 6 podnosi wymagania (Node 22.12.0 lub nowszy), usuwa kilka starszych funkcji i wprowadza zmiany w łączniku do Cloudflare, ale nie psuje stron już opublikowanych.
Wskazówka: poproś wykonawcę o jedno zdanie na piśmie — jaka jest wersja Astro i jaka wersja Node buduje Twoją stronę. Jeśli odpowiedzi to „5” i „20”, wpisz aktualizację do planu na najbliższy kwartał, poza okresem szczytu sprzedaży.