Wrangler TOML Builder

Wrangler TOML Builder

Compose Cloudflare Workers wrangler.toml or wrangler.jsonc with bindings, routes, vars, and triggers.

Worker
compatibility_flags
Routes
Vars (plain text)
KV Namespaces
D1 Databases
R2 Buckets
Durable Objects
Queues — Producers
Queues — Consumers
Hyperdrive
Cron Triggers
Secrets (placeholders)

Secrets ship via wrangler secret put — only names appear in the config.

wrangler.toml
name = "my-worker"
main = "src/index.ts"
compatibility_date = "2025-04-01"
compatibility_flags = ["nodejs_compat"]
workers_dev = true

[vars]
ENVIRONMENT = "production"
wrangler.jsonc
// wrangler.jsonc
// Cloudflare Workers configuration
{
  "$schema": "node_modules/wrangler/config-schema.json",
  "name": "my-worker",
  "main": "src/index.ts",
  "compatibility_date": "2025-04-01",
  "compatibility_flags": [
    "nodejs_compat"
  ],
  "workers_dev": true,
  "vars": {
    "ENVIRONMENT": "production"
  }
}

What This Tool Does

Wrangler TOML Builder is built for deterministic developer and agent workflows.

Compose Cloudflare Workers wrangler.toml or wrangler.jsonc with bindings (KV, D1, R2, Durable Objects, Queues, Hyperdrive), routes, vars, compatibility flags, and triggers. Outputs TOML and JSONC side-by-side.

Use How to Use for execution steps and FAQ for constraints, policies, and edge cases.

Last updated:

This tool is provided as-is for convenience. Output should be verified before use in any production or critical context.

Agent Invocation

Best Path For Builders

Browser workflow

Runs instantly in the browser with private local processing and copy/export-ready output.

Browser Workflow

This tool is optimized for instant in-browser execution with local data handling. Run it here and copy/export the output directly.

/wrangler-toml-builder/

For automation planning, fetch the canonical contract at /api/tool/wrangler-toml-builder.json.

How to Use Wrangler TOML Builder

  1. 1

    Set the Worker basics

    Enter the Worker name (lowercase letters, digits, hyphens), the entry path like src/index.ts, and a recent compatibility_date in YYYY-MM-DD format. Toggle the workers_dev flag if you want a *.workers.dev preview URL.

  2. 2

    Add bindings

    Use the side panel to add KV namespaces, D1 databases, R2 buckets, Durable Objects, Queues producers/consumers, and Hyperdrive bindings. Each row exposes the exact fields wrangler expects, and binding names are checked for duplicates.

  3. 3

    Configure routes, vars, and triggers

    Attach custom domain or pattern routes, set non-secret variables in the [vars] block, list secret names as placeholders, and add cron triggers for scheduled Workers. The validator flags malformed cron expressions.

  4. 4

    Pick TOML or JSONC output

    Switch the output panel between TOML and JSONC, or view both side-by-side. Newer Workers projects use wrangler.jsonc, while existing projects often stay on wrangler.toml — copy the format your repo already uses.

  5. 5

    Copy and commit

    Use the Copy button to grab the generated config, save it as wrangler.toml or wrangler.jsonc at the project root, then run wrangler deploy. Real KV/D1/R2 IDs come from running wrangler kv namespace create or d1 create first.

Frequently Asked Questions

Which output format should I commit, TOML or JSONC?
Both are supported by current wrangler. JSONC is preferred for new projects (better tooling support, multiline edits), TOML stays the default for existing repos. Pick whichever your team already uses and stay consistent.
How do I supply real binding IDs?
Run wrangler kv namespace create, d1 create, r2 bucket create, or queues create on the CLI first. Each command prints the ID to paste into the matching binding row in the builder.
Are secrets included in the generated file?
Only as commented placeholders. Secrets must be uploaded with wrangler secret put NAME and never committed in plaintext to wrangler.toml. The builder lists secret names so you remember which ones to set.
Does it send my data to a server?
No. Every byte stays in your browser. Generation, validation, and the JSONC/TOML rendering all run client-side, so binding IDs and var values never leave the device.
What does compatibility_date control?
It pins the runtime behaviour to a fixed snapshot of Workers semantics, so your Worker keeps behaving the same when Cloudflare ships breaking platform changes. Pair it with compatibility_flags for opt-ins like nodejs_compat.