Cum să publicați o pagină pe Cloudflare Workers

Aveți un folder cu o pagină gata și nicio legătură. O publicăm pe Cloudflare Workers, iar procedura o încredințăm lui Claude Code: construim un skill cu care publicarea și actualizarea se reduc la o cerere scurtă.

1. Ce este Cloudflare Workers pentru conținut static

Cuvântul Workers sună ca "programe care rulează pe server", și e adevărat. Dar nu tot adevărul: la un worker se poate atașa un folder de fișiere, iar atunci serverul pur și simplu le servește, ca o găzduire obișnuită. Nu se scrie nicio linie de cod pentru asta.

Pentru o pagină din HTML, CSS și imagini, acest mod este suficient. În documentație acest folder se numește static assets, resurse statice, și în setările proiectului ocupă exact un câmp cu o cale.

Cloudflare distribuie fișierele prin propria rețea de servere și le pune în cache mai aproape de vizitatori.

2. Cât costă

Cererile către fișierele statice sunt gratuite și nu au limită de număr. Aceasta e o condiție a planului, nu o promisiune că nu există statistici de vizite.

Atunci de unde vine numărul cunoscut - 100 000 de cereri pe zi? Este limita apelurilor la scriptul Worker, acel program de pe server. O pagină cu doar un folder atașat nu are script, deci nu intră deloc în acest contor.

Ruta de sus din schemă se potrivește paginii noastre: fișierul este servit fără a apela un program de server. Cea de jos va fi utilă dacă adăugați mai târziu un script Worker.

Planul gratuit are totuși limite, dar acestea privesc altceva - dimensiunea a ceea ce publicați:

Pentru o pagină cu o duzină de imagini, aceste limite sunt de obicei suficiente. Înainte de un proiect mare, verificați condițiile actuale ale Cloudflare: limitele se pot schimba. 25 MB per fișier, apropo, par generoase exact până la primul videoclip.

3. Contul

Înregistrarea pe cloudflare.com este obișnuită: email și parolă, apoi un email de confirmare. Nu e nevoie de card pentru planul gratuit. Nici propriul domeniu nu trebuie adăugat - serviciul vă va propune asta, dar propunerea ține de cealaltă jumătate a produsului, protecția și accelerarea site-urilor deja existente.

După autentificare, secțiunea de care aveți nevoie se numește "Workers & Pages", și nu este la vedere: în meniul din stânga, mai întâi grupul Build, în el Compute, și abia înăuntru - "Workers & Pages". Panoul se rearanjează din când în când, așa că dacă secțiunea nu e pe această cale, căutați-o după nume: căutarea din stânga sus se deschide cu Ctrl + K. Cele două cuvinte din nume sunt două produse Cloudflare; aveți nevoie de prima jumătate, Workers, și ajungeți acolo automat, fără să alegeți nimic anume.

Încă un lucru apare la primul deploy: Cloudflare vă va cere să alegeți un nume de subdomeniu pentru cont. Toate proiectele dumneavoastră vor trăi pe el, iar adresa se compune din două părți - numele proiectului plus subdomeniul dumneavoastră:

my-landing.example-account.workers.dev
|          |               |
|          |               domeniul comun al Cloudflare
|          subdomeniul contului dumneavoastră
numele proiectului

acest nume se schimbă greu mai târziu, așa că e mai bine să nu scrieți primul lucru care vă vine în minte.

4. Primul deploy

Mai întâi să vedem pe scurt cum arată publicarea în panou. E o familiarizare opțională cu serviciul: dacă vreți să configurați direct deploy-ul prin agent și să păstrați o singură adresă, treceți la pregătirea de mai jos.

landing/          <- acest folder îl predăm
  index.html      <- pagina principală, numele e obligatoriu
  wrangler.jsonc  <- agentul îl creează înainte de primul deploy
  style.css
  img/
    hero.png

Înainte de publicare, verificați conținutul folderului ales: fișierele din el devin publice. Scoateți din el fișierele personale și ciornele pe care nu intenționați să le arătați.

Manual, prin panou

În secțiunea cu proiecte există un buton care pornește un proiect nou. Apoi vi se cere să predați fișierele: puteți alege un singur fișier sau un folder întreg. Ați încărcat, ați confirmat - Cloudflare le-a urcat pe serverele sale și v-a dat o legătură. Numele butoanelor și ordinea ecranelor se schimbă aici mai des decât apar articolele, așa că țineți-vă de sens, nu de etichete: porniți un proiect, predați fișierele, obțineți o adresă.

Deschideți adresa primită https://…workers.dev și verificați pagina și imaginile. Puteți face asta de pe același computer. Un telefon e util pentru a verifica în plus accesibilitatea și aspectul mobil.

După publicarea prin panou, nu apare niciun fișier de configurare local. Skillul din exemplul nostru nu leagă singur folderul de un asemenea proiect: fără fișier de configurare, va crea un nume nou și o a doua adresă. Cloudflare permite actualizarea unui Worker existent prin Wrangler, dar pentru asta trebuie să scrieți separat numele lui în fișierul de configurare.

Ce e nevoie pentru ca agentul să facă asta

Pentru publicările următoare configurăm un skill. Pregătirea e necesară o singură dată pe computerul dumneavoastră.

Va fi nevoie de puține programe. Contul îl aveți deja, mai e nevoie de Node.js - se verifică cu comanda node -v, și dacă nu e găsită, trebuie mai întâi instalat. Wrangler-ul propriu-zis nu trebuie instalat: npx va descărca unul proaspăt singur, când va veni vremea.

Al doilea pas de pe schemă este autentificarea, și merită încheiat chiar acum, înainte de orice altceva:

npx wrangler login    # se deschide browserul, acolo e un buton de confirmare

Executați comanda în terminal. Dacă lipsește acest pas, întreaga procedură se va bloca chiar la prima rulare, și va arăta ca un skill stricat, deși problema nu e deloc acolo. Ca să verificați că totul a mers, folosiți comanda npx wrangler whoami - vă arată sub ce cont sunteți autentificat.

Pentru această rută e suficientă autentificarea prin browser. Token-ul API este explicat în continuarea opțională de la final.

Al treilea pas al schemei, npx wrangler deploy, va fi rulat de agent din folderul paginii. Mai întâi îi dăm regulile de pregătire a fișierului de configurare și de publicare.

5. Propriul skill pentru deploy

Cât timp aveți o singură pagină, ajunge și o cerere în chat. Dar de îndată ce apare a doua, a treia, a zecea - de fiecare dată trebuie explicat agentului același lucru: ce folder luăm, cum numim proiectul, ce facem cu fișierul de setări. A treia oară devine plictisitor.

Ce trebuie să știe să facă skillul

Cinci pași, și fiecare rezolvă o problemă concretă, nu e adăugat de dragul completitudinii:

1. Ia folderul numit și se asigură că index.html stă în rădăcina lui. O verificare ieftină care prinde cea mai frecventă greșeală înainte de deploy, nu după.
2. Stabilește numele proiectului - îl deduce din numele folderului, în loc să întrebe de fiecare dată.
3. Verifică dacă în interiorul folderului, lângă index.html, se află fișierul wrangler.jsonc. Dacă nu - îl creează; dacă da - ia numele de acolo și nu rescrie nimic în el.
4. Rulează deploy-ul din acest folder și arată comanda înainte de rulare.
5. Returnează adresa publică și amintește să verificați pagina și imaginile la ea.

Numele proiectului se deduce din folder

Aceasta este decizia principală a întregii proceduri, și tocmai ea nu poate fi lăsată la improvizația agentului. Dacă numele nu e stabilit printr-o regulă, agentul îl va inventa singur - și data viitoare va inventa altul. Va rezulta un al doilea proiect cu altă adresă, iar primul va rămâne în continuare online.

Regula e simplă: numele folderului este numele proiectului. Numele unui worker poate conține doar litere latine minuscule, cifre și cratimă, așa că tot restul - puncte, spații, underscore-uri - se transformă în cratimă, iar la final se adaugă un sufix scurt de patru caractere aleatorii:

landing/                 ->  landing-42c2
my.first.page/           ->  my-first-page-8e10
portfolio-2026/          ->  portfolio-2026-b7a3

Sufixul e necesar ca două foldere cu același nume din proiecte diferite să nu ocupe aceeași adresă. Se generează o singură dată, la crearea fișierului de setări, și obligatoriu printr-o comandă, nu din capul agentului: altfel va prelua sufixul din exemplu, și la toți cei care au citit același articol va ieși identic. Apoi sufixul se citește mereu din fișierul de configurare. Tocmai de aceea skillul se uită mai întâi la un fișier de configurare existent și abia apoi scrie ceva.

Fișierul de setări îl scrie agentul

În wrangler.jsonc agentul scrie numele proiectului și setările de publicare, ca să ruleze deploy-ul fără întrebări în terminal. Fișierul de configurare stă lângă index.html, deci calea către fișiere din el este un punct, "acest folder":

{
  "name": "landing-42c2",
  "compatibility_date": "2026-09-07",
  "assets": { "directory": "." }
}

Câmpul compatibility_date alege comportamentul compatibil al platformei la data indicată. Pentru un fișier de configurare nou, agentul pune data curentă, așa cum recomandă documentația Cloudflare; la o republicare, o păstrează pe cea veche.

Nu e o idee bună să puneți fișierul de configurare cu un nivel mai sus, lângă folder: numele fișierului e fix, într-un director poate exista un singur asemenea fișier, iar al doilea folder fie va suprascrie fișierul de configurare al primului, fie se va publica sub numele lui. În interiorul folderului fiecare proiect e de sine stătător, iar deploy-ul rulează direct din el.

Un efect secundar al acestei așezări: fișierul de configurare stă în același folder cu pagina, deci va fi publicat odată cu ea și se va putea deschide prin legătură. Nu are secrete în el - un nume, o dată și un punct -, iar cine e deranjat de asta pune lângă el un fișier .assetsignore și enumeră în el ce nu se publică.

Trei reguli care merită spuse explicit în sarcină, altfel agentul nu le va ghici:

• fișierul nu există - se creează, arătând ce a scris;
• fișierul există - numele și data rămân cum sunt, chiar dacă data de azi e alta;
• fișierul se rescrie doar atunci când conținutul chiar se schimbă.

Patru cereri de ținut la îndemână

Prima este chiar sarcina pentru skill. E mai lungă decât celelalte, pentru că e singura dată când descrieți procedura în întregime:

Construiește un skill pentru deploy-ul paginilor statice pe Cloudflare Workers.
Pune-l în .claude/skills/ al acestui proiect.
La final arată calea către SKILL.md creat și modul de apelare explicită a skillului.

Mai întâi citește documentația actuală Cloudflare despre Workers
și static assets: comenzile și câmpurile configurației s-ar fi putut schimba.
Dacă ceva din descrierea de mai jos diferă de documentație - spune-mi,
nu rescrie pe tăcute.

În descrierea skillului enumeră frazele la care trebuie să reacționeze,
cel puțin: "publică folderul", "publică din nou", "fă deploy pe Cloudflare".

Procedură: iau un folder, verific că în rădăcină există index.html.
Numele proiectului îl deduc din numele acestui folder: în el rămân doar
litere latine minuscule, cifre și cratimă, tot restul (spații,
underscore-uri, majuscule, litere non-latine) îl transform în cratimă.
La final adaug printr-o cratimă un sufix din patru caractere.
Sufixul nu-l inventez, ci îl obțin cu comanda:
node -e "console.log(crypto.randomUUID().slice(0,4))"
Fișierul de configurare wrangler.jsonc stă în interiorul folderului publicat, lângă
index.html, iar assets.directory din el este egal cu ".".
Dacă nu există fișier de configurare - îl creez: name, compatibility_date,
assets.directory. Pentru un compatibility_date nou iau data curentă
în formatul YYYY-MM-DD. Arăt ce am scris.
Dacă există fișier de configurare - iau numele și data de acolo și nu le rescriu.
Rescriu fișierul doar atunci când conținutul chiar se schimbă.
Dacă există fișier de configurare, dar assets.directory indică spre alt folder
sau fișierul de configurare are un câmp main - mă opresc și spun, nu rulez deploy-ul.
Dacă mi se cere să public din nou, iar fișierul de configurare nu există în folder - mă opresc
și întreb, nu creez un proiect nou.
Deploy: npx wrangler deploy din folderul proiectului. Arăt comanda înainte de rulare.
În răspuns returnez adresa publică și amintesc să verific la ea
pagina și imaginile. La o actualizare adresa trebuie să rămână aceeași.
Dacă nu există Node.js sau autentificarea nu e făcută - spun asta,
nu încerc să ocolesc.
Dacă contul nu are încă subdomeniu workers.dev - spun asta:
deploy-ul neinteractiv eșuează în acest punct.

După creare, deschideți fișierul arătat de agent, .claude/skills/<nume>/SKILL.md: în el trebuie să fie regulile de mai sus. Înainte de a doua cerere, apelați explicit skillul creat, în modul arătat de agent. Dacă skillul nu se găsește, cereți-i să verifice calea și disponibilitatea lui în proiectul curent.

A doua - o verificare înainte de acțiune. Utilă înainte de primul deploy al unui folder, când vreți să vedeți planul înainte ca ceva să iasă în lume; dacă sunt mai multe foldere, o trimiteți pentru fiecare:

Nu crea și nu modifica fișiere, nu rula wrangler. Doar arată-mi
ce intenționezi să faci cu folderul landing: ce nume de proiect,
ce fișier de configurare vei scrie, ce comandă vei rula.

O precizare: sufixul apare în momentul scrierii fișierului de configurare, deci pentru un folder unde fișierul de configurare nu există încă, numele din plan și numele de la rularea reală pot să nu coincidă. Restul va coincide.

A treia și a patra sunt cele de lucru, pentru ele s-a pornit toată treaba:

Publică folderul landing pe Cloudflare Workers.

Am modificat index.html în landing. Publică din nou pe Cloudflare Workers.

După prima publicare, deschideți legătura primită, verificați textul și imaginile. Apoi schimbați o frază vizibilă în landing/index.html și trimiteți a patra cerere. Reîmprospătați pagina la aceeași adresă: ar trebui să apară fraza nouă. Dacă adresa s-a schimbat, cereți agentului să verifice numele din fișierul de configurare înainte de următorul deploy.

Cu asta ruta principală s-a încheiat: skillul e creat, pagina e publicată, actualizarea a fost verificată la aceeași legătură. Înainte de fiecare publicare rămâne doar să alegeți folderul potrivit și să vă uitați la comanda agentului.

6. Scenarii suplimentare

Restul îl puteți sări, cât timp nu aveți nevoie să pregătiți multe foldere deodată sau să rulați un deploy fără autentificare prin browser.

Când o procedură nu mai ajunge

Un skill sub formă de instrucțiuni funcționează bine cât timp folderele sunt câteva sau câteva zeci. Mai departe începe să deranjeze faptul că agentul recitește de fiecare dată procedura și o execută manual: la vreo cincizeci de foldere asta durează mult și nu iese mereu la fel.

Atunci procedura se rescrie ca script: el parcurge folderele singur, scrie fișierele de configurare, sare peste cele unde nu s-a schimbat nimic și tipărește un rezumat. Skillul nu dispare cu asta - pur și simplu apelează scriptul în loc să scrie el însuși fișierele de configurare, iar deploy-ul îl rulează în continuare singur.

Nici pe acesta nu trebuie să-l scrieți dumneavoastră. Agentul are deja o descriere detaliată a procedurii - skillul dumneavoastră -, așa că cererea iese scurtă:

Scrie în Python un script care face ce e descris în skillul meu
de deploy, doar că deodată pentru toate folderele proiectului.

Ia folderele unde în rădăcină există index.html;
nu se uită în node_modules, .git și dist.
Pentru fiecare compune numele după regula noastră și scrie wrangler.jsonc
în interiorul folderului.
Dacă fișierul de configurare există deja - ia numele și compatibility_date de acolo,
iar fișierul îl rescrie doar atunci când conținutul chiar s-a schimbat.
Dacă fișierul de configurare nu poate fi citit - nu îl atinge, spune asta
și sare peste folder.
Implicit doar arată planul și nu scrie nimic;
scrierea se face printr-un flag explicit.
E nevoie de un filtru, ca să ruleze doar folderele alese.
Scriptul doar pregătește fișierele de configurare, nu rulează deploy-ul.
La final tipărește un tabel: folder, nume de proiect, ce s-a făcut.
Dacă ceva din această descriere e ambiguu - întreabă, nu completa pe tăcute.

Afișarea planului vă permite să verificați lista de foldere înainte de scriere. Păstrarea numelui și a datei protejează fișierele de configurare existente de modificări accidentale. Scriptul în sine doar pregătește setările; publicarea rămâne treaba skillului.

Token-ul de acces

Pe computerul dumneavoastră v-ați autentificat deja prin npx wrangler login. Wrangler păstrează autorizarea, de care se folosesc și comenzile agentului.

Dacă e nevoie de rulare automată fără autentificare prin browser sau de drepturi mai restrânse, se folosește un token API. Poate fi creat în profil: avatar, profil, secțiunea de token-uri API. Adresa directă este dash.cloudflare.com/profile/api-tokens.

Formularul de creare arată intimidant: grupuri de drepturi, resurse, tot felul de filtre. De fapt sunt patru decizii acolo, iar jumătate din câmpuri pot fi lăsate neatinse.

1. Numele token-ului. Peste șase luni nu vă veți aminti la ce folosea, așa că scrieți la obiect: "deploy pagini de pe laptop", nu "token 2".
2. Drepturi. Nu trebuie și nu merită să le adunați unul câte unul. În lista de seturi gata făcute există Edit Cloudflare Workers - în el e deja adunat tot ce e necesar pentru publicare.
3. Resurse. Limitați token-ul la un singur cont, chiar cel unde publicați. Chiar dacă aveți un singur cont, alegeți-l explicit: conturile se pot înmulți, iar token-ul va rămâne același.
4. Durata de viață și filtrul după IP. Câmpuri opționale. Are sens să setați o durată când token-ul e necesar pentru o seară sau pentru mașina altcuiva; în munca obișnuită se lasă cum sunt.

Apoi token-ul se pune în variabila de mediu CLOUDFLARE_API_TOKEN, iar contul se indică în CLOUDFLARE_ACCOUNT_ID. O variabilă de mediu este o setare a mașinii dumneavoastră, pe care programele o citesc singure; wrangler le va găsi pe amândouă fără participarea dumneavoastră. Cum funcționează variabilele și unde trebuie ținute corect e o discuție separată, aici e suficient să știți că e un loc, nu un rând într-o conversație.