Publikacja strony na Cloudflare — od zera do działającego adresu

Instrukcja krok po kroku, od założenia konta po opublikowany projekt. Spisana na podstawie wdrożeń: strony gabinetu, ankiet Erasmus+ i dwóch generatorów pism.

Co dostajesz: hosting stron za darmo, nielimitowany transfer, certyfikat SSL, serwery na całym świecie. Bez opłat miesięcznych. Płacisz tylko za domenę, jeśli ją podepniesz.

1. Założenie konta

1. Wejdź na dash.cloudflare.com/sign-up
2. Podaj adres e-mail i hasło
3. Potwierdź adres, klikając link w wiadomości, która przyjdzie na skrzynkę
4. Wybierz plan Free — nie podajesz karty płatniczej

Po zalogowaniu trafiasz do panelu. Wszystko, czego potrzebujesz, znajduje się w menu po lewej pod Compute → Workers & Pages.

Uwaga o nazewnictwie. Cloudflare nazywa projekty „Workers". Historycznie istniały też „Pages" — obecnie Cloudflare poleca Workers dla nowych projektów i tego trzymamy się w tej instrukcji.

2. Instalacja Node.js

Node.js to narzędzie, dzięki któremu publikujesz stronę jedną komendą zamiast przeciągania plików w przeglądarce.

Sprawdź, czy już go masz. Otwórz Terminal (⌘Spacja, wpisz Terminal, Enter) i wklej:

node -v

Jeśli zobaczysz numer w rodzaju v24.18.1 — gotowe. Jeśli „command not found", pobierz wersję LTS z nodejs.org, zainstaluj, zamknij Terminal i otwórz na nowo.

3. Podstawy Terminala

Cztery rzeczy, które wystarczą.

Terminal to nie Spotlight. Komendy wpisuje się w aplikacji Terminal, nie w wyszukiwarce systemowej.

Zawsze najpierw wejdź do folderu projektu. Nowe okno Terminala startuje w katalogu domowym. Znak zachęty pokazuje, gdzie jesteś:

cd ~/Desktop/nazwa-projektu

Po tej komendzie znak zachęty zmieni się z ~ % na nazwa-projektu %. Jeśli tego nie widzisz, komendy trafią w złe miejsce.

Wklejaj komendy pojedynczo. Terminal przyjmuje tekst do bufora nawet wtedy, gdy poprzednia komenda pyta o potwierdzenie — łatwo wtedy odpowiedzieć „tak" na pytanie, którego się nie widziało.

Ctrl+C przerywa działającą komendę. Przydaje się przy zatrzymywaniu serwera podglądu.

4. Struktura projektu

Każdy projekt wygląda tak samo:

nazwa-projektu/
├── public/              ← wszystko, co trafia na serwer
│   ├── index.html       strona główna
│   ├── css/, js/, img/
│   └── 404.html
├── src/index.js         kod serwerowy (tylko jeśli potrzebny)
├── wrangler.jsonc       konfiguracja
└── package.json         skróty komend

Kluczowa zasada: na serwer trafia wyłącznie zawartość public/. Notatki, oryginały zdjęć i pliki robocze trzymaj poziom wyżej — nie zostaną opublikowane.

wrangler.jsonc — najprostsza wersja

{
  "name": "nazwa-projektu",
  "compatibility_date": "2026-08-01",
  "assets": {
    "directory": "./public",
    "html_handling": "drop-trailing-slash",
    "not_found_handling": "404-page"
  }
}

package.json

{
  "name": "nazwa-projektu",
  "private": true,
  "scripts": {
    "dev": "wrangler dev",
    "deploy": "wrangler deploy"
  },
  "devDependencies": { "wrangler": "^4.0.0" }
}

5. Logowanie do Cloudflare z terminala

Raz na komputer:

cd ~/Desktop/nazwa-projektu
npm install
npx wrangler login

Otworzy się przeglądarka z ekranem „Wrangler wants to access your account" — kliknij Authorize. Terminal potwierdzi zalogowanie.

Dostęp można później cofnąć w profilu Cloudflare, w sekcji połączonych aplikacji.

6. Publikacja strony statycznej

Najprostszy przypadek: zwykłe pliki HTML, CSS i obrazki.

cd ~/Desktop/nazwa-projektu
npm run deploy

Na końcu dostaniesz adres w rodzaju:

https://nazwa-projektu.twoja-subdomena.workers.dev

Otwórz go i sprawdź stronę. To wszystko.

Podgląd przed publikacją

npm run dev

Strona ruszy pod http://localhost:8787. Zatrzymanie: Ctrl+C.

Skąd bierze się adres

Adres ma zawsze postać <nazwa-projektu>.<subdomena-konta>.workers.dev. Pierwszy człon to nazwa z wrangler.jsonc, drugi ustawiasz raz dla całego konta w Workers & Pages, przy pozycji „Your subdomain".

Nazwy projektu nie da się później zmienić. Trzeba utworzyć nowy i usunąć stary. Warto więc od razu nadać sensowną — Cloudflare domyślnie proponuje losową, w rodzaju holy-bird-78ce.

7. Projekt z bazą danych

Potrzebny, gdy strona ma coś zapamiętywać — na przykład odpowiedzi z formularza.

Utworzenie bazy

npm run db:create

lub bezpośrednio:

npx wrangler d1 create nazwa_bazy

Wrangler zapyta o nazwę powiązania — wpisz DB wielkimi literami, jeśli tak nazywa się ona w kodzie. Potem zapyta, czy przy pracy lokalnej łączyć się z bazą na serwerze — odpowiedz n, żeby testy nie zaśmiecały prawdziwych danych.

Na koniec Wrangler sam dopisze do wrangler.jsonc:

"d1_databases": [
  {
    "binding": "DB",
    "database_name": "nazwa_bazy",
    "database_id": "df9343c7-838f-4f3a-b309-2d7e7664d9ee"
  }
]

Utworzenie tabel

Przygotuj plik schema.sql z definicją tabel, potem:

npx wrangler d1 execute nazwa_bazy --remote --file=./schema.sql

Cloudflare ostrzeże, że baza będzie chwilowo niedostępna. Przy pustej bazie to formalność — potwierdź.

Wersja lokalna, do testów:

npx wrangler d1 execute nazwa_bazy --local --file=./schema.sql

Sprawdzenie zawartości

npx wrangler d1 execute nazwa_bazy --remote --command="SELECT COUNT(*) FROM nazwa_tabeli"

8. Projekt chroniony hasłem

Gdy strona ma być dostępna tylko dla wybranych osób.

Ustawienie hasła

npx wrangler secret put AUTH_PASS

Wpisz hasło i naciśnij Enter — znaki nie będą widoczne. Jeśli projekt jeszcze nie istnieje na Cloudflare, Wrangler zapyta, czy go utworzyć. Potwierdź.

Hasła zapisanego w ten sposób nie da się później odczytać — można je tylko nadpisać. Zapisz je w menedżerze haseł.

Ważne ustawienie w konfiguracji

"assets": {
  "directory": "./public",
  "run_worker_first": true
}

Bez tego pliki byłyby wydawane z pominięciem sprawdzania hasła. To najpoważniejsza pułapka przy stronach chronionych.

Jeśli chronisz tylko część adresów, na przykład eksport danych:

"run_worker_first": ["/api/*"]

Uwaga o hasłach w samej stronie

Jeśli plik HTML ma własny ekran logowania sprawdzający hasło w JavaScripcie — to nie jest zabezpieczenie. Cała zawartość trafia do przeglądarki przed zalogowaniem i widać ją w podglądzie źródła strony. Ochrona musi działać po stronie serwera.

9. Aktualizacja i wycofanie zmian

Zwykła aktualizacja

1. Popraw plik w public/
2. Sprawdź lokalnie: npm run dev
3. Opublikuj: npm run deploy

Zmiana jest widoczna po kilkunastu sekundach.

Gdy widzisz starą wersję

Otwórz stronę w oknie prywatnym (⇧⌘N). Jeśli to nie pomaga, wyczyść bufor w panelu Cloudflare: Caching → Purge Everything.

Wycofanie nieudanej zmiany

Workers & Pages → wybierz projekt → Deployments → przy starszej wersji Rollback. Trwa sekundy, nie wymaga terminala.

10. Podpięcie własnej domeny

Adres workers.dev działa od razu, ale do rozsyłania ludziom lepszy jest własny.

Warunek

Cloudflare musi obsługiwać DNS Twojej domeny. Domena może pozostać u dotychczasowego rejestratora — przenosisz tylko obsługę DNS.

Cloudflare nie sprzedaje domen .pl — te kupujesz u polskiego rejestratora. Uwaga na ceny: promocyjna opłata za pierwszy rok bywa dziesięciokrotnie niższa od odnowienia. Sprawdzaj cenę odnowienia, nie startową.

Kroki

1. Zrób zrzut ekranu obecnych rekordów DNS u rejestratora — to Twoja kopia bezpieczeństwa
2. Cloudflare → Domains → Add a site → Connect a domain
3. Wpisz domenę, wybierz plan Free
4. Cloudflare zeskanuje DNS i pokaże listę — porównaj ją ze zrzutem, dopisz brakujące wpisy
5. Cloudflare poda dwa serwery nazw; wpisz je u rejestratora
6. Poczekaj na propagację — zwykle kilka godzin, czasem do doby
7. W projekcie: Domains → Add custom domain → np. ankiety.twojadomena.pl

Certyfikat SSL powstaje automatycznie i jest darmowy. Subdomen możesz mieć wiele — każdy projekt swoją.

Na co uważać

Rekordy MX to poczta. Jeśli ich zabraknie po przeniesieniu, e-maile przestaną przychodzić. Muszą mieć status „DNS only".

Pomarańczowa chmurka przy rekordzie oznacza, że ruch idzie przez Cloudflare. Zwykle to zaleta, ale bywa, że koliduje z panelem hostingu czy FTP — wtedy kliknij chmurkę, zrobi się szara.

Tryb SSL w zakładce SSL/TLS ustaw na Full. „Flexible" powoduje pętlę przekierowań na hostingach wymuszających HTTPS.

Wszystko jest odwracalne. Wpisujesz z powrotem stare serwery nazw i po kilku godzinach jest jak było.

11. Najczęstsze błędy

12. Ściąga z komend

# --- przygotowanie ---
cd ~/Desktop/nazwa-projektu   # wejście do folderu projektu
npm install                   # instalacja narzędzi (raz na projekt)
npx wrangler login            # logowanie (raz na komputer)

# --- praca ---
npm run dev                   # podgląd na http://localhost:8787
npm run deploy                # publikacja

# --- baza danych ---
npx wrangler d1 create nazwa_bazy
npx wrangler d1 execute nazwa_bazy --remote --file=./schema.sql
npx wrangler d1 execute nazwa_bazy --remote --command="SELECT COUNT(*) FROM tabela"

# --- hasła ---
npx wrangler secret put NAZWA_HASLA
openssl rand -base64 24       # wygenerowanie losowego hasła

# --- diagnostyka ---
npx wrangler tail             # podgląd błędów na żywo
npx wrangler whoami           # sprawdzenie, na jakie konto jesteś zalogowany

Limity darmowego planu

Przy zwykłej stronie firmowej czy szkolnym narzędziu tych granic się nie dotyka.

Zasada, którą warto zapamiętać

Zanim opublikujesz cokolwiek, uruchom to lokalnie i kliknij każdą funkcję. Zajmuje to pięć minut i wychwytuje rzeczy, których nie widać w kodzie — brakujący plik, hasło, które nie działa, eksport zwracający stronę błędu zamiast danych. Publikacja na serwer nie jest testem.