Does it generate the modern ES-modules worker format?

Yes. Every worker uses export default with an async fetch(request, env, ctx) handler — the current ES-modules syntax that supports bindings, scheduled handlers, and Durable Objects. It never emits the deprecated addEventListener("fetch") service-worker style. When you add a cron trigger to an API worker, a scheduled(event, env, ctx) method is added to the same default export.

How are the worker code and wrangler.toml kept in sync?

Both files are emitted from one model. The bindings you add appear as typed fields on the Env interface in the code and as [[kv_namespaces]], [[d1_databases]], [[r2_buckets]] or [vars] blocks in wrangler.toml. Routes become [[routes]] entries and cron triggers become a [triggers] block. Because there is a single source of truth, the code and the config cannot drift apart.

What does the audit check?

It flags the issues that actually break a deploy or leak data: a missing compatibility_date, a cron trigger on a worker that has no scheduled() handler, an env reference with no matching binding, a secret hard-coded in the worker source, an invalid (non-absolute) reverse-proxy target URL, a redirect rule with an empty from/to, and a [vars] entry named like a secret (plain vars are stored in cleartext, so it suggests a secret binding instead).

How should I handle secrets?

Add a Secret binding rather than a plain var. Secrets are never written into wrangler.toml — instead the config includes a wrangler secret put hint, and the code reads the value from env (for example env.AUTH_PASSWORD in the basic-auth worker). This keeps credentials out of source control while still typing them on the Env interface.

Can I add permissive CORS to any worker type?

Yes. Toggle "Add CORS headers" and the generator wraps your worker: it answers OPTIONS preflight requests and adds Access-Control-Allow-Origin, -Methods, and -Headers to responses, while your original logic moves into a handle() function. The dedicated CORS-proxy type already manages CORS itself, so the toggle is disabled there to avoid double-wrapping.

What happens when I switch between TypeScript and JavaScript?

In TypeScript mode the worker includes an Env interface (with KV/D1/R2 bindings typed as KVNamespace, D1Database, and R2Bucket) and typed fetch/scheduled signatures, and wrangler.toml points main at src/index.ts. In JavaScript mode the types are dropped and main points at src/index.js. The generated logic is otherwise identical, so you can compare both outputs instantly.

Cloudflare Worker Generator

Generate a modern ES-modules Cloudflare Worker — an API router, reverse proxy, redirect map, edge cache, CORS proxy, A/B + geo router, basic-auth gate or HTMLRewriter — in TypeScript or JavaScript. Add KV, D1, R2, var and secret bindings, routes and cron triggers, and get a matching wrangler.toml emitted alongside. The worker code, the config, and a deploy-time audit all re-render live as you edit.

About this ToolHow it works, benefits & use cases

This is a real Cloudflare Worker builder, not a single boilerplate template. Pick a worker type — an API router with a tiny path matcher and JSON responses, a reverse proxy that forwards to an upstream origin, a redirect map, an edge cache with a TTL, a CORS proxy, an A/B and geo router that splits on the visitor country, an HTTP basic-auth gate, or an HTMLRewriter — and the tool emits a modern ES-modules worker (export default with async fetch(request, env, ctx)), never the deprecated addEventListener style. Toggle TypeScript or JavaScript, layer permissive CORS on top of any type, set a cache TTL, add KV, D1, R2, plain var and secret bindings, route patterns, and cron triggers. A matching wrangler.toml is generated from the same model so the two never drift, and a deploy-time audit flags the mistakes that break a deploy: a cron with no scheduled() handler, an env reference with no binding, a hard-coded secret, a missing compatibility_date, an invalid proxy target, or a plain var that looks like it should be a secret. Worker code, config, and audit all re-render live as you edit, and the whole setup is captured in a shareable URL.

How to Use

1Start from a preset (Hello API, Reverse proxy, Redirect map, Edge cache, CORS proxy, Cron worker) or choose a worker type from scratch.
2Set the worker name and compatibility_date, and toggle TypeScript or JavaScript output.
3Fill in the type-specific config — API routes, redirect rules, a proxy target, allowed CORS origins, a cache TTL, a geo country, or a basic-auth username.
4Add KV, D1, R2, var or secret bindings, plus route patterns and cron triggers for wrangler.toml.
5Switch the output between the worker code and wrangler.toml, read the audit, then copy or download both files and run wrangler deploy.

Key Benefits

Eight worker patterns: API router, reverse proxy, redirect map, edge cache, CORS proxy, A/B + geo routing, basic auth, and HTMLRewriter
Modern ES-modules output (export default { async fetch }) in TypeScript or JavaScript — never the legacy addEventListener style
A matching wrangler.toml emitted from the same model, with KV, D1, R2, vars, routes, and cron triggers
Bindings read off env, with secrets kept out of source and surfaced as wrangler secret put hints
A deploy-time audit for missing compatibility_date, cron without scheduled(), unbound env references, hard-coded secrets, and bad proxy targets
Live preview — worker code, config, and audit re-render instantly as you edit
Optional CORS wrapping and an automatic scheduled() handler when a cron is set on an API worker
Shareable URL captures the entire worker and config for handoff

Common Use Cases

Scaffolding a JSON API at the edge with a small path router and typed env bindings
Standing up a reverse proxy or CORS proxy in front of an existing origin
Shipping a redirect map for legacy URLs with the right 301/302/307/308 status codes
Caching origin responses at Cloudflare with a configurable TTL
Splitting traffic by visitor country for A/B tests or regional routing
Generating both index.ts and wrangler.toml for a cron-driven worker and deploying with Wrangler

index.ts

API router · TypeScript

export interface Env {
  // add your bindings here
}

export default {
  async fetch(request: Request, env: Env, ctx: ExecutionContext): Promise<Response> {
    if (request.method === 'OPTIONS') {
      return new Response(null, {
        headers: {
          'Access-Control-Allow-Origin': '*',
          'Access-Control-Allow-Methods': 'GET, POST, PUT, DELETE, OPTIONS',
          'Access-Control-Allow-Headers': 'Content-Type, Authorization',
          'Access-Control-Max-Age': '86400',
        },
      });
    }

    const response = await handle(request, env, ctx);
    const out = new Response(response.body, response);
    out.headers.set('Access-Control-Allow-Origin', '*');
    out.headers.set('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE, OPTIONS');
    out.headers.set('Access-Control-Allow-Headers', 'Content-Type, Authorization');
    return out;
  },
};

async function handle(request: Request, env: Env, ctx: ExecutionContext): Promise<Response> {
  const url = new URL(request.url);
  const route = `${request.method} ${url.pathname}`;

  if (route === "GET /") {
    return json({ "message": "Hello from the edge" });
  }
  if (route === "GET /health") {
    return json({ "status": "ok" });
  }

  return json({ error: 'Not found' }, 404);
}

function json(data: unknown, status = 200): Response {
  return new Response(JSON.stringify(data), {
    status,
    headers: { 'content-type': 'application/json' },
  });
}

Worker looks deploy-ready

Start from a preset

Worker

Worker type

Tiny path router returning JSON responses

Name

compatibility_date

TypeScript

Emit index.ts with a typed Env.

Add CORS headers

Wraps the worker with preflight + CORS.

API routes

Bindings

No bindings. Add KV, D1, R2, a plain var or a secret.

Routes & triggers

Routes (comma-separated)

Route patterns for wrangler.toml. Leave empty for workers.dev.

Cron triggers (comma-separated)

POSIX cron. Adds a scheduled() handler (API workers) and a [triggers] block.

Modern Workers, generated correctly

Every worker uses the current ES-modules format — export default { async fetch(request, env, ctx) {…} } — not the deprecated addEventListener('fetch') style. Bindings are read off env, secrets stay out of source, and the matching wrangler.toml is emitted from the same model so the two never drift.

What the audit catches

A cron trigger with no scheduled() handler to run it.
An env.* reference with no matching binding in wrangler.toml.
A secret hard-coded in source instead of read from env.
A missing compatibility_date, an invalid proxy target, or a [vars] entry that looks like a secret.

Was this tool helpful?

Share Your Experience

Help others discover this tool!

Share on

Cloudflare Worker Generator

How to Use

Key Benefits

Common Use Cases

Start from a preset

Worker

API routes

Bindings

Routes & triggers

Modern Workers, generated correctly

What the audit catches

Was this tool helpful?

Share Your Experience

Related tools

Frequently Asked Questions - Cloudflare Worker Generator