Cloudflare Workers

→ Cloudflare Workers Documentation

What create-faster adds

Cloudflare Workers is a project-level deployment platform. Generation is stack-aware per app: a Hono app gets a direct Workers config, and a Next.js app gets an OpenNext config. Selecting it once with --deployment cloudflare configures every app according to its stack.

Hono apps

Hono already exports a Workers-compatible fetch handler (export default app), so no adapter is needed — local dev keeps running on Bun while Wrangler handles preview and deploy.

{
  "$schema": "node_modules/wrangler/config-schema.json",
  "name": "my-api",
  "main": "src/index.ts",
  "compatibility_date": "2026-06-12",
  "compatibility_flags": ["nodejs_compat"]
}

Scripts:

• deploy - Deploy the Worker (wrangler deploy)
• preview - Run the Worker locally on the Workers runtime (wrangler dev)
• cf-typegen - Generate binding types (wrangler types --env-interface CloudflareEnv cloudflare-env.d.ts)

Next.js apps

Next.js apps deploy through the OpenNext Cloudflare adapter. next.config.ts calls initOpenNextCloudflareForDev() so Cloudflare bindings are available during next dev, and the build emits the Worker output under .open-next/.

{
  "$schema": "node_modules/wrangler/config-schema.json",
  "name": "web",
  "main": ".open-next/worker.js",
  "compatibility_flags": ["nodejs_compat", "global_fetch_strictly_public"],
  "assets": {
    "directory": ".open-next/assets",
    "binding": "ASSETS"
  }
}

import { defineCloudflareConfig } from '@opennextjs/cloudflare';

export default defineCloudflareConfig({});

Scripts:

• build:cf - Generate binding types, Next.js build, then the OpenNext adapter build (wrangler types … && next build && opennextjs-cloudflare build). Types are generated first so the binding globals (e.g. Hyperdrive, D1Database) typecheck during next build.
• preview - Local Wrangler preview of the built output (opennextjs-cloudflare preview)
• deploy - Deploy the built output (opennextjs-cloudflare deploy)
• cf:typegen - Generate binding types (wrangler types --env-interface CloudflareEnv cloudflare-env.d.ts)

Postgres / MySQL via Hyperdrive

A Worker cannot open a raw TCP connection to a Postgres or MySQL server, and forbids reusing a connection across requests. When a Next.js app uses --database postgres (or mysql) with --deployment cloudflare, the database is routed through a Cloudflare Hyperdrive binding (a pooling proxy), and the db package exports a per-request createDb(hyperdrive) factory instead of a module-level singleton.

"hyperdrive": [
  {
    "binding": "HYPERDRIVE",
    "id": "REPLACE_WITH_HYPERDRIVE_ID",
    "localConnectionString": "postgresql://postgres:password@localhost:5432/postgres-my-app"
  }
]

• Setup: wrangler hyperdrive create <name> --connection-string="...", then paste the id into wrangler.jsonc. localConnectionString is used by wrangler dev/local only and matches your local DATABASE_URL.
• Migrations run on Node via drizzle-kit against DATABASE_URL — unchanged by Hyperdrive.
• better-auth / tRPC over a Cloudflare binding database (per-request consumers) is not wired yet, so those combinations are disabled with a reason on Cloudflare (tracked in #153).

Shared behavior

The Worker name is the app name in turborepo mode and the project name in single mode.

Modified files:

• .gitignore - Ignores .wrangler/ and cloudflare-env.d.ts; for Next.js apps it also ignores .open-next/ and .prod.env.

Local secrets:

Wrangler 4.x reads local secrets and variables from .env (already gitignored). Put your local values there and run the preview script. Production secrets are managed with wrangler secret put <KEY>. We standardize on .env rather than .dev.vars because Wrangler ignores .env whenever a .dev.vars file is present, which would silently shadow it.

Turborepo mode: wrangler.jsonc (and open-next.config.ts for Next.js apps) is placed in apps/<name>/, and the Worker is named after the app. Run the scripts from the app directory.