Ez a fájl a projekted központi idegrendszere: itt deklarálod, mi a Workered, mihez fér hozzá, hol fut, milyen szabályok szerint. Az eddigi modulokban darabokban látszott — itt egyben van: neve, helye, formátuma, minden mezője, az öröklődés szabályai és egy teljes, kommentált éles példa.
A neve wrangler.jsonc (vagy wrangler.json, vagy a régebbi wrangler.toml) — a Wrangler v3.91 óta mindhárom formátum támogatott, és új projekthez a Cloudflare a wrangler.jsonc-t ajánlja (néhány újabb funkció csak JSON-konfiggal érhető el). A tartalom mindháromban ugyanaz, csak a szintaxis más — a .jsonc előnye, hogy kommentelhető, ami egy ilyen fájlnál sokat ér.
Hol van? A projekt gyökerében, a package.json mellett. A Wrangler az aktuális könyvtárból indulva felfelé keresi. Monorepóban minden Worker-csomag saját mappájában van egy-egy konfig; ilyenkor vagy a csomag mappájából futtatod a parancsot, vagy megadod: wrangler deploy --config apps/api/wrangler.jsonc (a Workers Buildsben ugyanezt a Root directory beállítás oldja meg — 8. modul).
Az első sor mindig ez legyen — ettől kapsz automatikus kiegészítést és validációt a szerkesztődben (VS Code, WebStorm), tehát nem kell fejből tudnod a mezőneveket:
{
"$schema": "./node_modules/wrangler/config-schema.json",
…
}
wrangler deploy felülírhatja a fájl tartalmával. Vagyis: a konfigot a repóban szerkeszd, ne a webes felületen — így lesz a beállítás verziózott, review-zható és környezetenként reprodukálható. (A titkok a kivétel: azok szándékosan nincsenek a fájlban — lásd 12.6.)Bármilyen hosszú is egy konfig, mindig ugyanaz a hat dolog van benne. Ha ezt a hatot a fejedben tartod, bármelyik példát el tudod olvasni:
Ez egy éles jellegű konfig egy Nuxt-alapú, multitenant SaaS-hoz, amiben szinte minden szerepel, amiről a kurzus szólt. Használd sablonként:
wrangler.jsonc{
"$schema": "./node_modules/wrangler/config-schema.json",
/* ---------- ① IDENTITÁS ÉS BELÉPÉSI PONT ---------- */
"name": "my-app", // a Worker neve (a dashboardon is ez)
"main": "./.output/server/index.mjs", // a belépési modul (Nuxt/Nitro build kimenete)
"assets": { // statikus fájlok (3. modul)
"directory": "./.output/public",
"binding": "ASSETS", // env.ASSETS.fetch(...) a kódban
"not_found_handling": "single-page-application",
"run_worker_first": ["/api/*"] // ezekre a Worker fut előbb
},
/* ---------- ② RUNTIME-VISELKEDÉS (2. modul) ---------- */
"compatibility_date": "2026-08-02", // a runtime "verziója" — nem változik alattad
"compatibility_flags": ["nodejs_compat"], // Node API-k engedélyezése
/* ---------- ③ HOL ÉRHETŐ EL ---------- */
"workers_dev": false, // ne legyen *.workers.dev cím élesben
"preview_urls": true, // PR-preview URL-ek (8. modul)
// routes: melyik domainen fut — env-enként adjuk meg lentebb
/* ---------- ④ BINDINGS — MIHEZ FÉR HOZZÁ ---------- */
// (itt csak a közös alapok; a környezetfüggőket az env blokkokban)
"vars": { // NEM titkos konfig (a repóban van!)
"APP_NAME": "MyApp",
"SUPPORT_EMAIL": "help@example.com"
},
"durable_objects": { // 7. modul
"bindings": [
{ "name": "RATE_LIMITER", "class_name": "RateLimiter" }
]
},
"migrations": [ // DO-osztályok életciklusa (nem D1!)
{ "tag": "v1", "new_sqlite_classes": ["RateLimiter"] }
],
"workflows": [ // 7. modul
{ "name": "onboard-tenant", "binding": "ONBOARD",
"class_name": "OnboardTenant" }
],
/* ---------- ⑤ PLATFORM-BEÁLLÍTÁSOK ---------- */
"triggers": { "crons": ["0 1 * * *"] }, // UTC! (7. modul)
"limits": { "cpu_ms": 60000 }, // önvédelem (2. modul)
"observability": { "enabled": true }, // 9. modul
"upload_source_maps": true, // olvasható stack trace-ek
/* ---------- ⑥ KÖRNYEZETEK (8. modul) ---------- */
"env": {
"staging": {
"name": "my-app-staging",
"routes": [{ "pattern": "staging.example.com/*",
"zone_name": "example.com" }],
// FIGYELEM: ha egy nem-öröklődő kulcsot itt megadsz,
// MINDET meg kell adnod ebben a blokkban (12.5)!
"vars": { "APP_NAME": "MyApp (staging)", "SUPPORT_EMAIL": "help@example.com" },
"d1_databases": [{ "binding": "DB", "database_name": "app-staging",
"database_id": "<STAGING_UUID>" }],
"r2_buckets": [{ "binding": "UPLOADS", "bucket_name": "uploads-staging" }],
"kv_namespaces": [{ "binding": "CONFIG", "id": "<STAGING_KV_ID>" }],
"queues": {
"producers": [{ "binding": "JOBS", "queue": "jobs-staging" }],
"consumers": [{ "queue": "jobs-staging", "max_batch_size": 10,
"dead_letter_queue": "jobs-staging-dlq" }]
},
"hyperdrive": [{ "binding": "HYPERDRIVE", "id": "<STAGING_HD_ID>" }],
"durable_objects": { "bindings": [
{ "name": "RATE_LIMITER", "class_name": "RateLimiter" } ] },
"workflows": [{ "name": "onboard-tenant-staging", "binding": "ONBOARD",
"class_name": "OnboardTenant" }],
"observability": { "enabled": true, "head_sampling_rate": 1 }
},
"production": {
"name": "my-app-production",
"routes": [{ "pattern": "app.example.com/*",
"zone_name": "example.com" }],
"vars": { "APP_NAME": "MyApp", "SUPPORT_EMAIL": "help@example.com" },
"d1_databases": [{ "binding": "DB", "database_name": "app-prod",
"database_id": "<PROD_UUID>" }],
"r2_buckets": [{ "binding": "UPLOADS", "bucket_name": "uploads-prod" }],
"kv_namespaces": [{ "binding": "CONFIG", "id": "<PROD_KV_ID>" }],
"queues": {
"producers": [{ "binding": "JOBS", "queue": "jobs-prod" }],
"consumers": [{ "queue": "jobs-prod", "max_batch_size": 50,
"max_retries": 5, "dead_letter_queue": "jobs-prod-dlq" }]
},
"hyperdrive": [{ "binding": "HYPERDRIVE", "id": "<PROD_HD_ID>" }],
"durable_objects": { "bindings": [
{ "name": "RATE_LIMITER", "class_name": "RateLimiter" } ] },
"workflows": [{ "name": "onboard-tenant", "binding": "ONBOARD",
"class_name": "OnboardTenant" }],
"observability": { "enabled": true, "head_sampling_rate": 0.1 }
}
}
}
| Kulcs | Típus | Mit csinál |
|---|---|---|
$schema | string | IDE-autocomplete és validáció — mindig tedd be |
name | string | a Worker neve (kötelező); env-enként felülírandó |
main | string | a belépési modul útvonala |
compatibility_date | string | a runtime viselkedésének dátuma (2. modul) |
compatibility_flags | string[] | opt-in kapcsolók, pl. nodejs_compat |
account_id | string | ha több fiókod van (jellemzően env-változóból jobb) |
keep_vars | boolean | ne törölje a dashboardon kézzel felvett vars-okat deploykor |
| Kulcs | Mit csinál |
|---|---|
routes / route | melyik domain-mintán fut (pattern + zone_name vagy custom_domain) |
workers_dev | legyen-e *.workers.dev cím (élesben tipikusan false) |
preview_urls | verziónkénti preview URL-ek (8. modul); Accessszel védhető |
assets | statikus fájlok: directory, binding, not_found_handling, run_worker_first, html_handling |
| Kulcs | Kötelező mezői | Modul |
|---|---|---|
vars | kulcs-érték objektum (nem titkos!) | 8. |
d1_databases | binding, database_name, database_id (+ migrations_dir, migrations_pattern) | 5. |
r2_buckets | binding, bucket_name (+ jurisdiction) | 6. |
kv_namespaces | binding, id | 6. |
queues | producers[] (binding, queue) és/vagy consumers[] (queue, batch/retry/DLQ opciók) | 7. |
hyperdrive | binding, id | 4. |
durable_objects | bindings[]: name, class_name (+ script_name, ha másik Workerben él) | 7. |
workflows | name, binding, class_name | 7. |
services | binding, service — Worker→Worker hívás | 11. |
ai, vectorize, browser, analytics_engine_datasets | binding (+ dataset/index név) | 9. |
containers | class_name, image, instance_type, max_instances (DO-binding is kell hozzá) | 10. |
bármely binding + "remote": true | lokális devnél az éles erőforrásra kapcsol | 11. |
| Kulcs | Mit csinál |
|---|---|
triggers.crons | ütemezett futások (UTC-ben!) |
limits | cpu_ms, subrequests — plafon önvédelemből vagy emelés |
observability | enabled, head_sampling_rate, logs, traces |
placement | { "mode": "smart" } vagy { "region": "…" } — a Worker futásának helye (5b.) |
migrations | Durable Object osztály-migrációk (tag, new_sqlite_classes, renamed_classes…) — nem a D1 séma-migrációi! |
upload_source_maps | olvasható stack trace-ek a hibakövetőben (9. modul) |
secrets.required | a Worker által elvárt secretek listája (hiányra figyelmeztet) |
build | saját build-parancs deploy előtt (Vite plugin esetén nem kell) |
migrations kulcs a konfigban a Durable Object osztályokra vonatkozik (mikor jött létre, átnevezted-e, SQLite-os-e) — semmi köze a D1 séma-migrációkhoz, amiket a migrations/ mappa .sql fájljai és a wrangler d1 migrations apply kezel. Két teljesen külön dolog, hasonló névvel.A 8. modulban röviden úgy fogalmaztunk, hogy „a bindingok nem öröklődnek". A pontos szabály ennél egy árnyalattal finomabb, és pont ez az árnyalat okozza a hibákat:
main, compatibility_date, compatibility_flags, limits, triggers, observability, assets, workers_dev, preview_urls stb. Ezeket elég a top-levelen megadni; az env-ek megkapják, és felül is írhatják őket.vars, d1_databases, r2_buckets, kv_namespaces, queues, hyperdrive, durable_objects, workflows, services, ai…És a szabály, ami mindenkit megvisel egyszer: ha egy nevesített környezetben akár egyetlen nem öröklődő kulcsot felülírsz, akkor az összes többi nem öröklődő kulcsot is meg kell adnod ugyanabban a blokkban. Nincs részleges öröklés.
// ❌ HIBÁS — lokálisan még működik, deploykor validációs hibát dob:
{
"kv_namespaces": [{ "binding": "CONFIG", "id": "<ID>" }],
"vars": { "API_KEY": "dev" },
"env": {
"production": {
"vars": { "API_KEY": "prod" } // felülírtunk EGY non-inheritable kulcsot…
// …ezért a kv_namespaces-t is KÖTELEZŐ itt megadni!
}
}
}
// ✅ HELYES — minden non-inheritable kulcs szerepel az env-ben:
{
"env": {
"production": {
"vars": { "API_KEY": "prod" },
"kv_namespaces": [{ "binding": "CONFIG", "id": "<PROD_ID>" }]
}
}
}
Ezért néz ki a 12.3-as példa „redundánsnak": a staging és a production blokkban minden binding újra szerepel. Ez nem hanyagság, hanem a modell — és egyben védelem: így nem fordulhat elő, hogy a staging egy kifelejtett sor miatt csendben a production adatbázisára mutat.
| Mi | Hova kerül helyette |
|---|---|
| Titkok (API-kulcsok, DB-jelszó, JWT-secret) | élesben wrangler secret put; lokálisan .dev.vars (gitignore) — a kódban ugyanúgy env.X |
| Cloudflare API-token a deployhoz | a CI secret-tárában (CLOUDFLARE_API_TOKEN) |
| D1 séma-migrációk | migrations/*.sql fájlok + wrangler d1 migrations apply |
| Lokális binding-adat | .wrangler/state/ (gitignore) |
| Generált típusok | worker-configuration.d.ts (wrangler types) |
A database_id, kv id, hyperdrive id viszont nyugodtan mehet a repóba — ezek azonosítók, nem hitelesítő adatok: önmagukban nem adnak hozzáférést, csak a fiókodon belül, hitelesített kontextusban értelmesek.
| Tünet | Ok | Megoldás |
|---|---|---|
env.DB undefined stagingen | a binding hiányzik az env.staging blokkból | vedd fel oda is (12.5 szabály) |
| Deploy validációs hibával áll meg env-nél | részleges non-inheritable felülírás | sorold fel az összes bindinget abban az env-ben |
| „Cannot find module 'node:…'" | hiányzik a nodejs_compat flag vagy régi a compat date | flag + compatibility_date ≥ 2024-09-23 |
| A kód nem látja a legfrissebb bindinget típusban | elfelejtett wrangler types | tedd a dev-script elé |
| A cron nem akkor fut, amikor várod | a cron UTC-ben értendő | számold át (nyáron BP = UTC+2) |
| Dashboardon beállított érték eltűnt deploy után | a konfig az igazság forrása | tedd bele a fájlba (vagy keep_vars) |
| DO-osztály átnevezése után hiba | hiányzó migrations bejegyzés (DO!) | renamed_classes új tag-gel |
| Lokálisan jó, élesben nincs adat | --local vs --remote keveredés a d1/kv parancsokban | package.json-scriptekbe rögzíteni a flageket |
wrangler.jsonc (vagy .json/.toml) a projekt gyökerében, a package.json mellett; monorepóban Worker-csomagonként egy. Új projekthez a .jsonc az ajánlott (kommentelhető, és néhány újabb funkció csak JSON-konfiggal érhető el).
$schema sor?
A szerkesztőd ebből tudja a séma-definíciót: automatikus kiegészítést és validációt kapsz — nem kell fejből tudni a mezőneveket, és az elgépelt kulcs azonnal látszik.
vars-t, majd a production env-ben csak a vars-t írod felül. Mi történik?
Deploykor validációs hiba. Ha egyetlen nem öröklődő kulcsot felülírsz egy env-ben, akkor mindet meg kell adnod ott — tehát a kv_namespaces-t is fel kell venni a production blokkba.
migrations kulcsa és a D1-migrációk között?
A konfig migrations kulcsa a Durable Object osztályok életciklusát írja le (létrehozás, átnevezés, SQLite-tár). A D1 séma-migrációi ettől függetlenül a migrations/*.sql fájlokban élnek, és a wrangler d1 migrations apply futtatja őket.
database_id vagy STRIPE_SECRET_KEY? Miért?
A database_id igen — azonosító, nem hitelesítő adat, önmagában nem ad hozzáférést. A Stripe-kulcs nem: az secret, ami wrangler secret put-tal megy élesbe és .dev.vars-ban él lokálisan.
Mert a konfigfájl az igazság forrása: a következő deploy felülírhatja a kézi módosítást. A fájlban tartva a beállítás verziózott, review-zható és környezetenként reprodukálható.