What does compatibility_date actually control?

It pins your Worker to the runtime behavior as it existed on that date, so Cloudflare can ship breaking runtime changes behind newer compatibility dates without affecting Workers pinned to an older one. Use today's date for a new project, and only advance it deliberately after checking the compatibility flags changelog.

Do I need both KV and D1 bindings?

No, they're independent toggles for two different storage products: KV is a key-value store good for caching and simple lookups, D1 is a SQLite-based relational database. Enable only the one(s) your Worker actually uses; most projects need at most one or the other.

Where do I get the actual namespace/database IDs this needs?

Run `wrangler kv:namespace create ` or `wrangler d1 create ` first, both commands print the id you need to paste into this generator's binding fields. This tool builds the TOML structure; it doesn't create the underlying Cloudflare resources for you.

What goes in [vars] versus a KV/D1 binding?

[vars] is for plain, non-secret configuration values baked into the deployed Worker (like a feature flag or a public API base URL). Never put real secrets there, use `wrangler secret put` for those instead, since [vars] values are stored in plain text in the file.

wrangler.toml Generator - Cloudflare Workers Config Builder

Overview

Introduction

Setting up wrangler.toml by hand means remembering TOML's array-of-tables syntax for routes, KV namespaces, and D1 databases, and it's easy to typo a bracket or quote and get a confusing parse error.

This tool builds the file from a plain form: fill in the required fields, toggle on the bindings you actually use, and get back ready-to-save TOML.

What Is wrangler.toml Generator?

A wrangler.toml generator covering the fields most Worker and Pages Functions projects need: name, main entry point, compatibility_date, repeatable [[routes]] entries, optional [[kv_namespaces]] and [[d1_databases]] bindings, and a [vars] block.

The output is plain TOML text, matching the structure Wrangler (Cloudflare's CLI) expects when you run `wrangler deploy`.

How wrangler.toml Generator Works

Required top-level keys (name, main, compatibility_date) are written first, validated for TOML-safe values (lowercase-hyphenated name, a YYYY-MM-DD date) before generation.

Each route, KV namespace, and D1 database you add becomes its own `[[routes]]`, `[[kv_namespaces]]`, or `[[d1_databases]]` array-of-tables block, Wrangler's syntax for repeatable binding entries, and any [vars] entries are written as a final `[vars]` table.

When To Use wrangler.toml Generator

Use it when scaffolding a new Cloudflare Worker or Pages Functions project and you want a correct starting wrangler.toml without copying one from an old project and stripping out what doesn't apply.

It's also useful for adding a new KV or D1 binding to an existing setup, generate just that block and merge it into your current file.

Often used alongside Cloudflare Pages _headers File Generator and Cloudflare Pages Deployment Checker.

Features

Advantages

Produces syntactically valid TOML array-of-tables blocks for routes, KV namespaces, and D1 databases without you needing to recall the exact `[[...]]` syntax.
Validates the fields most likely to cause a confusing Wrangler error if malformed (name format, date format, incomplete binding rows).
Keeps KV and D1 bindings as independent toggles so the output stays minimal when you only need one.

Limitations

Doesn't create the actual KV namespace or D1 database in your Cloudflare account, you still need `wrangler kv:namespace create` / `wrangler d1 create` for that.
Covers the fields listed above only; more advanced wrangler.toml features (Durable Objects, cron triggers, service bindings) aren't generated here.

Examples

A Worker with one KV binding and a var

Input

name: my-worker, main: src/index.ts, compatibility_date: 2024-09-23, KV binding: CACHE / id: abc123, var: ENVIRONMENT=production

Output

name = "my-worker"
main = "src/index.ts"
compatibility_date = "2024-09-23"

[[kv_namespaces]]
binding = "CACHE"
id = "abc123"

[vars]
ENVIRONMENT = "production"

Required fields come first, followed by the KV binding as its own array-of-tables block, then the [vars] table last.

Best Practices & Notes

Best Practices

Set compatibility_date to the actual date you're deploying, then only advance it deliberately after reviewing Cloudflare's compatibility flags changelog.
Keep binding names (KV, D1) in SCREAMING_SNAKE_CASE by convention, matching how they're referenced as `env.BINDING_NAME` in Worker code.
Never put real secrets in [vars], use `wrangler secret put <NAME>` for anything sensitive instead.

Developer Notes

TOML string values are wrapped in double quotes with backslashes and embedded quotes escaped; repeatable sections (routes, kv_namespaces, d1_databases) are emitted as separate `[[table]]` blocks per TOML's array-of-tables syntax, which is what Wrangler's own config parser expects for these specific keys.

wrangler.toml Generator Use Cases

Scaffolding wrangler.toml for a brand-new Worker or Pages Functions project
Adding a new KV or D1 binding block to merge into an existing config
Generating a routes block when attaching a Worker to custom domain patterns

Common Mistakes

Forgetting to actually create the KV namespace or D1 database with Wrangler before deploying a config that references its id.
Putting a secret value in [vars] instead of using `wrangler secret put`, exposing it in plain text in version control.

Tips

Run the Cloudflare Pages Deployment Checker afterward if this Worker also backs Pages Functions, to confirm your overall deployment setup is complete.

wrangler.toml Generator