12. modulA wrangler konfigurációs fájl: teljes referencia
Cloudflare for Devs · 12. modul — referencia

A wrangler konfigurációs fájl: teljes referencia

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.

12.1Mi ez a fájl, mi a neve, hol van?

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).

my-app/
├── wrangler.jsoncez a fájl (a repóban, verziózva)
├── package.json
├── .dev.vars ← lokális titkok — .gitignore!
├── .wrangler/state/ ← lokális binding-adat — .gitignore!
├── worker-configuration.d.ts ← `wrangler types` generálja
├── migrations/ ← D1 migrációk
└── src/index.ts ← a `main` mutat ide

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",
  …
}
Ez a fájl az igazság forrása. Amit a Cloudflare dashboardon kézzel átállítasz (binding, változó, route), azt a következő 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.)

12.2Az anatómia: hat réteg

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:

① Identitás, belépési pont name · main · assets ② Runtime-viselkedés compatibility_date · flags ③ Hol érhető el routes · workers_dev · preview_urls ④ Bindings — mihez fér hozzá a Worker vars · d1_databases · r2_buckets · kv_namespaces queues · hyperdrive · durable_objects · workflows services · ai · vectorize · analytics_engine_datasets · containers ⑤ Platform-beállítások triggers (cron) · limits · observability · placement · migrations (DO!) ⑥ env — a fenti öt megismétlése környezetenként (staging, production) saját név, saját route, saját erőforrások — az öröklődés szabályaival (12.5)
12/1. ábra — A konfig hat rétege. A ④ a legterjedelmesebb: minden erőforrás, amit az eddigi modulokban láttál, itt kap egy bejegyzést.

12.3Teljes, kommentált példa — a te stackedhez

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 }
    }
  }
}

12.4Mezőreferencia kategóriánként

Alap / identitás

KulcsTípusMit csinál
$schemastringIDE-autocomplete és validáció — mindig tedd be
namestringa Worker neve (kötelező); env-enként felülírandó
mainstringa belépési modul útvonala
compatibility_datestringa runtime viselkedésének dátuma (2. modul)
compatibility_flagsstring[]opt-in kapcsolók, pl. nodejs_compat
account_idstringha több fiókod van (jellemzően env-változóból jobb)
keep_varsbooleanne törölje a dashboardon kézzel felvett vars-okat deploykor

Elérhetőség / routing

KulcsMit csinál
routes / routemelyik domain-mintán fut (pattern + zone_name vagy custom_domain)
workers_devlegyen-e *.workers.dev cím (élesben tipikusan false)
preview_urlsverziónkénti preview URL-ek (8. modul); Accessszel védhető
assetsstatikus fájlok: directory, binding, not_found_handling, run_worker_first, html_handling

Bindings — az erőforrások

KulcsKötelező mezőiModul
varskulcs-érték objektum (nem titkos!)8.
d1_databasesbinding, database_name, database_id (+ migrations_dir, migrations_pattern)5.
r2_bucketsbinding, bucket_name (+ jurisdiction)6.
kv_namespacesbinding, id6.
queuesproducers[] (binding, queue) és/vagy consumers[] (queue, batch/retry/DLQ opciók)7.
hyperdrivebinding, id4.
durable_objectsbindings[]: name, class_name (+ script_name, ha másik Workerben él)7.
workflowsname, binding, class_name7.
servicesbinding, service — Worker→Worker hívás11.
ai, vectorize, browser, analytics_engine_datasetsbinding (+ dataset/index név)9.
containersclass_name, image, instance_type, max_instances (DO-binding is kell hozzá)10.
bármely binding + "remote": truelokális devnél az éles erőforrásra kapcsol11.

Platform-viselkedés

KulcsMit csinál
triggers.cronsütemezett futások (UTC-ben!)
limitscpu_ms, subrequests — plafon önvédelemből vagy emelés
observabilityenabled, head_sampling_rate, logs, traces
placement{ "mode": "smart" } vagy { "region": "…" } — a Worker futásának helye (5b.)
migrationsDurable Object osztály-migrációk (tag, new_sqlite_classes, renamed_classes…) — nem a D1 séma-migrációi!
upload_source_mapsolvasható stack trace-ek a hibakövetőben (9. modul)
secrets.requireda Worker által elvárt secretek listája (hiányra figyelmeztet)
buildsaját build-parancs deploy előtt (Vite plugin esetén nem kell)
A leggyakoribb névütközés: a 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.

12.5Az öröklődés pontos szabálya (ezt érdemes megjegyezni)

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:

É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.

12.6Mi NEM kerül ebbe a fájlba?

MiHova 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 deployhoza CI secret-tárában (CLOUDFLARE_API_TOKEN)
D1 séma-migrációkmigrations/*.sql fájlok + wrangler d1 migrations apply
Lokális binding-adat.wrangler/state/ (gitignore)
Generált típusokworker-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.

12.7Gyakori hibák — gyorsdiagnózis

TünetOkMegoldás
env.DB undefined stagingena binding hiányzik az env.staging blokkbólvedd fel oda is (12.5 szabály)
Deploy validációs hibával áll meg env-nélrészleges non-inheritable felülírássorold fel az összes bindinget abban az env-ben
„Cannot find module 'node:…'"hiányzik a nodejs_compat flag vagy régi a compat dateflag + compatibility_date ≥ 2024-09-23
A kód nem látja a legfrissebb bindinget típusbanelfelejtett wrangler typestedd a dev-script elé
A cron nem akkor fut, amikor vároda cron UTC-ben értendőszámold át (nyáron BP = UTC+2)
Dashboardon beállított érték eltűnt deploy utána konfig az igazság forrásatedd bele a fájlba (vagy keep_vars)
DO-osztály átnevezése után hibahiányzó migrations bejegyzés (DO!)renamed_classes új tag-gel
Lokálisan jó, élesben nincs adat--local vs --remote keveredés a d1/kv parancsokbanpackage.json-scriptekbe rögzíteni a flageket

12.8Ellenőrizd magad

  1. Mi a fájl neve, hol van, és melyik formátumot válaszd új projekthez?
    Válasz

    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).

  2. Mire való a $schema sor?
    Válasz

    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.

  3. Top-levelen definiálsz egy KV-bindinget és egy vars-t, majd a production env-ben csak a vars-t írod felül. Mi történik?
    Válasz

    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.

  4. Mi a különbség a konfig migrations kulcsa és a D1-migrációk között?
    Válasz

    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.

  5. Melyik érték mehet a repóba: database_id vagy STRIPE_SECRET_KEY? Miért?
    Válasz

    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.

  6. Miért nem érdemes a dashboardon állítgatni a bindingokat?
    Válasz

    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ó.

Előző11. modul — Fejlesztői workflow: wrangler, lokális dev, tesztelés, debug Következő 13. modul — Nuxt-fejlesztés Cloudflare-en