add Cloudflare Workers as first-class runtime (default)

New `runtime` config field: `"cloudflare"` (default) or `"lambda"`.
Deploy dispatches to the appropriate backend based on config.

Cloudflare Workers support:
- `deploy-cf.ts`: deploy/destroy/list via CF REST API (no wrangler dep)
- `cloudflare.ts`: Worker entry point using shared `handler.ts` logic
- Config injected into bundle at deploy time via placeholder replacement
- `cloudflare.*` config fields for account ID, worker name, routes

Refactored deploy layer:
- `deploy.ts` → `deploy-lambda.ts` (Lambda-specific)
- New `deploy.ts` dispatcher routes to CF or Lambda
- `tags.ts` lists proxies across both runtimes
- `cli.ts` shows runtime in output, `ls --runtime` filter

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Author: ryan-williams

README.md

@@ -1,12 +1,12 @@
 # cors-prxy
 
-Minimal, security-focused Lambda CORS proxy — deploy per-project allowlisted trampolines via CLI or GitHub Actions.
+Minimal, security-focused CORS proxy — deploy per-project allowlisted trampolines to Cloudflare Workers or AWS Lambda via CLI or GitHub Actions.
 
 ## Why
 
-Frontend apps need CORS proxies to fetch OG metadata, RSS feeds, and other cross-origin resources. Public proxies are unreliable and a security risk. Self-hosting is easy but repetitive — every project reinvents the same Lambda + allowlist pattern.
+Frontend apps need CORS proxies to fetch OG metadata, RSS feeds, and other cross-origin resources. Public proxies are unreliable and a security risk. Self-hosting is easy but repetitive — every project reinvents the same proxy + allowlist pattern.
 
-`cors-prxy` gives each project its own Lambda proxy with an explicit domain allowlist, deployed via CLI or GitHub Actions.
+`cors-prxy` gives each project its own proxy with an explicit domain allowlist, deployed via CLI or GitHub Actions.
 
 ## Install
 
@@ -32,18 +32,35 @@ Create `.cors-prxy.json` in your project root:
 }
 ```
 
+This deploys to **Cloudflare Workers** by default. For AWS Lambda, add `"runtime": "lambda"`.
+
+### Config fields
+
 | Field | Type | Default | Description |
 |-------|------|---------|-------------|
-| `name` | `string` | (required) | Lambda function name / resource identifier |
-| `region` | `string` | `us-east-1` | AWS region |
+| `name` | `string` | (required) | Proxy name / resource identifier |
+| `runtime` | `"cloudflare" \| "lambda"` | `"cloudflare"` | Deployment target |
 | `allow` | `(string \| AllowRule)[]` | (required) | Allowlisted domains/paths |
+| `region` | `string` | `us-east-1` | AWS region (Lambda only) |
+| `methods` | `string[]` | `["GET", "HEAD"]` | Allowed HTTP methods (`["*"]` for any) |
+| `forwardHeaders` | `string[]` | `[]` | Request headers to forward upstream |
+| `urlMode` | `"query" \| "path"` | `"query"` | `?url=` vs `/<host>/<path>` routing |
 | `rateLimit.perIp` | `number` | `60` | Max requests per IP per window |
 | `rateLimit.window` | `string` | `"1m"` | Rate limit window (`"30s"`, `"1m"`, `"1h"`) |
 | `cors.origins` | `string[]` | `["*"]` | Allowed CORS origins (globs) |
 | `cors.maxAge` | `number` | `86400` | `Access-Control-Max-Age` in seconds |
 | `cache.ttl` | `number` | `300` | Response cache TTL in seconds |
 | `cache.maxSize` | `number` | `1000` | Max cached responses (LRU) |
-| `tags` | `Record<string, string>` | `{}` | Additional AWS resource tags |
+| `tags` | `Record<string, string>` | `{}` | Additional resource tags |
+
+### Cloudflare config
+
+| Field | Type | Default | Description |
+|-------|------|---------|-------------|
+| `cloudflare.accountId` | `string` | `$CLOUDFLARE_ACCOUNT_ID` | CF account ID |
+| `cloudflare.workerName` | `string` | `cors-prxy-{name}` | Worker script name |
+| `cloudflare.route` | `string` | — | Custom route pattern |
+| `cloudflare.compatibilityDate` | `string` | `"2024-01-01"` | CF compatibility date |
 
 ### Allow rules
 
@@ -52,21 +69,38 @@ Create `.cors-prxy.json` in your project root:
 
 All non-matching requests return `403`.
 
+### Full proxy mode
+
+By default, only GET/HEAD are proxied (read-only). For APIs that need POST/PUT/etc:
+
+```json
+{
+  "name": "my-api-proxy",
+  "allow": ["api.example.com"],
+  "methods": ["*"],
+  "forwardHeaders": ["content-type", "authorization"],
+  "urlMode": "path",
+  "cache": { "ttl": 0, "maxSize": 0 }
+}
+```
+
+Request bodies are forwarded automatically for non-GET/HEAD methods. Only configured headers are forwarded — no cookies or credentials leak by default.
+
 ## CLI
 
 ```sh
-cors-prxy deploy              # create or update Lambda proxy
+cors-prxy deploy              # deploy proxy (CF Workers or Lambda)
 cors-prxy deploy -c custom.json
 
-cors-prxy ls                  # list all cors-prxy Lambdas in account
-cors-prxy ls -r us-east-1,eu-west-1
+cors-prxy ls                  # list all proxies (both runtimes)
+cors-prxy ls --runtime cloudflare
 cors-prxy ls --json
 
 cors-prxy status              # show current project's proxy info
-cors-prxy logs                # tail CloudWatch logs
+cors-prxy logs                # tail logs (CloudWatch for Lambda, wrangler for CF)
 cors-prxy logs -f             # follow
 
-cors-prxy destroy             # remove Lambda + IAM role
+cors-prxy destroy             # remove proxy
 cors-prxy destroy -y          # skip confirmation
 
 cors-prxy dev                 # local proxy on :3849
@@ -75,9 +109,14 @@ cors-prxy dev -p 4000         # custom port
 
 ### What `deploy` creates
 
-- **Lambda function** (Node.js 22.x, ESM) with a [Function URL] (no API Gateway)
-- **IAM execution role** with CloudWatch Logs permissions
-- All resources tagged for discovery (no local state file needed)
+**Cloudflare Workers** (default):
+- Worker script on `workers.dev` subdomain
+- Requires `CLOUDFLARE_API_TOKEN` and `CLOUDFLARE_ACCOUNT_ID` (or `cloudflare.accountId` in config)
+
+**AWS Lambda**:
+- Lambda function (Node.js 22.x, ESM) with a [Function URL] (no API Gateway)
+- IAM execution role with CloudWatch Logs permissions
+- All resources tagged for discovery
 
 `deploy` is idempotent: creates if missing, updates if changed.
 
@@ -112,61 +151,37 @@ Supports both OIDC and static credentials (`aws-access-key-id` / `aws-secret-acc
 ## How it works
 
 ```
-Browser → Lambda Function URL → Upstream
-         (allowlist check)      (fetch + cache)
+Browser → CF Worker / Lambda → Upstream
+         (allowlist check)     (fetch + cache)
          (CORS headers)
          (rate limit)
 ```
 
-Request: `GET /?url=<encoded-url>`
+Request: `GET /?url=<encoded-url>` (query mode) or `GET /<host>/<path>` (path mode)
 
 1. Parse + validate URL against allowlist
 2. If denied: `403 { error: "Domain not allowed", allowed: [...] }`
-3. Check in-memory LRU cache
+3. Check in-memory LRU cache (GET/HEAD only)
 4. Fetch upstream (10s timeout, 5MB size limit)
 5. Return response with CORS headers, cache result
 
-### Response headers
-
-```
-Access-Control-Allow-Origin: <matched origin>
-Access-Control-Allow-Methods: GET, HEAD, OPTIONS
-Access-Control-Max-Age: <from config>
-Cache-Control: public, max-age=<ttl>
-X-Cors-Prxy: <function-name>
-```
-
 ### Security
 
 - **Domain allowlist**: only configured domains are proxied, glob matching via [picomatch]
 - **Path allowlist**: optional per-domain path restrictions
 - **Rate limiting**: per-IP, in-memory (resets on cold start)
-- **Read-only**: only `GET` and `HEAD` are proxied
+- **Methods**: configurable — read-only by default, opt-in for mutations
+- **Header forwarding**: explicit allowlist only — no cookies/credentials forwarded by default
 - **Size limit**: responses >5MB rejected
 - **Timeout**: 10s upstream fetch timeout
-- **No credential forwarding**: request headers/cookies are not forwarded
 
 [picomatch]: https://github.com/micromatch/picomatch
 
-## Resource tagging
-
-All AWS resources are tagged for discovery:
-
-| Tag | Example |
-|-----|---------|
-| `cors-prxy` | `true` |
-| `cors-prxy:name` | `my-app` |
-| `cors-prxy:version` | `0.1.0` |
-| `cors-prxy:allow` | `github.com,*.github.com` |
-| `cors-prxy:repo` | `user/my-app` |
-
-`cors-prxy ls` discovers proxies via these tags — no local state file needed.
-
 ## Development
 
 ```sh
 pnpm install
-pnpm build    # tsc + esbuild Lambda bundle
+pnpm build    # tsc + esbuild bundles (Lambda + CF Worker)
 pnpm test     # vitest
 ```
 

package.json

@@ -10,8 +10,8 @@
     "dist"
   ],
   "scripts": {
-    "build": "tsc && node scripts/bundle-lambda.js",
-    "bundle": "node scripts/bundle-lambda.js",
+    "build": "tsc && node scripts/bundle-lambda.js && node scripts/bundle-cloudflare.js",
+    "bundle": "node scripts/bundle-lambda.js && node scripts/bundle-cloudflare.js",
     "clean": "rm -rf node_modules/.vite dist",
     "test": "vitest run",
     "prepublishOnly": "pnpm build"

scripts/bundle-cloudflare.js

@@ -0,0 +1,19 @@
+import { build } from "esbuild"
+import { resolve, dirname } from "node:path"
+import { fileURLToPath } from "node:url"
+
+const __dirname = dirname(fileURLToPath(import.meta.url))
+
+await build({
+  entryPoints: [resolve(__dirname, "../src/cloudflare.ts")],
+  bundle: true,
+  platform: "browser",
+  target: "es2022",
+  format: "esm",
+  outfile: resolve(__dirname, "../dist/cloudflare-bundle/index.mjs"),
+  minify: true,
+  external: ["node:*"],
+  conditions: ["worker", "browser"],
+})
+
+console.log("Cloudflare Worker bundle written to dist/cloudflare-bundle/index.mjs")

specs/cloudflare-workers-runtime.md

@@ -0,0 +1,169 @@
+# Cloudflare Workers runtime
+
+## Summary
+
+Add first-class Cloudflare Workers support as a deployment target alongside Lambda. CFW becomes the default runtime — better cold-start performance, global edge deployment, simpler auth model.
+
+## Config changes
+
+### `runtime` field
+
+```typescript
+interface CorsProxyConfig {
+  // ... existing fields ...
+
+  /** Deployment runtime. Default: "cloudflare" */
+  runtime?: "cloudflare" | "lambda"
+
+  /** Cloudflare-specific config (when runtime is "cloudflare") */
+  cloudflare?: {
+    /** CF account ID. Can also be set via CLOUDFLARE_ACCOUNT_ID env var. */
+    accountId?: string
+    /** Worker name. Defaults to config `name`. */
+    workerName?: string
+    /** Custom route pattern, e.g. "proxy.example.com/*". Optional — uses workers.dev by default. */
+    route?: string
+    /** Compatibility date. Default: "2024-01-01" */
+    compatibilityDate?: string
+  }
+}
+```
+
+When `runtime` is `"lambda"` (or unset in legacy configs that already have `region`), behavior is unchanged. When `runtime` is `"cloudflare"` (or unset and no `region`), deploy as a CF Worker.
+
+### Default runtime detection
+
+- If `runtime` is set explicitly: use it
+- If `region` is set but `runtime` is not: assume `"lambda"` (backwards compat)
+- Otherwise: default to `"cloudflare"`
+
+## CLI behavior
+
+No new subcommands. Existing commands dispatch on runtime:
+
+| Command | Lambda | Cloudflare |
+|---------|--------|------------|
+| `deploy` | Create/update Lambda + Function URL + IAM role | Create/update CF Worker via API |
+| `destroy` | Delete Lambda + IAM role | Delete CF Worker |
+| `status` | Query Lambda tags | Query CF Worker metadata |
+| `logs` | CloudWatch Logs | `wrangler tail` or CF API |
+| `ls` | Scan tagged Lambdas | Scan CF Workers by naming convention / tags |
+| `dev` | Local HTTP server (unchanged) | Local HTTP server (unchanged) |
+
+`ls` scans both backends by default. `--runtime lambda|cloudflare` flag to filter.
+
+## CF Workers deploy implementation
+
+### Auth
+
+CF API token via `CLOUDFLARE_API_TOKEN` env var (same as wrangler). Account ID from config or `CLOUDFLARE_ACCOUNT_ID` env var.
+
+No CF SDK needed — the CF API is simple enough to call via `fetch`:
+- `PUT /client/v4/accounts/{account_id}/workers/scripts/{script_name}` — upload worker
+- `GET /client/v4/accounts/{account_id}/workers/scripts/{script_name}` — check existence
+- `DELETE /client/v4/accounts/{account_id}/workers/scripts/{script_name}` — delete
+- `GET /client/v4/accounts/{account_id}/workers/scripts` — list workers
+- `PUT /client/v4/accounts/{account_id}/workers/scripts/{script_name}/subdomain` — enable workers.dev subdomain
+
+### Worker bundle
+
+The worker code is the same `handler.ts` logic, wrapped in a CF Workers entry point:
+
+```typescript
+import { handleProxyRequest } from "./handler.js"
+
+const config = CONFIG_JSON // replaced at bundle time by esbuild `define`
+
+export default {
+  async fetch(request: Request): Promise<Response> {
+    const url = new URL(request.url)
+    const result = await handleProxyRequest({
+      method: request.method,
+      url: url.pathname + url.search,
+      origin: request.headers.get("origin") ?? undefined,
+      ip: request.headers.get("cf-connecting-ip") ?? undefined,
+      body: request.body,
+      headers: Object.fromEntries(request.headers.entries()),
+    }, config)
+    return new Response(result.body as BodyInit, {
+      status: result.status,
+      headers: result.headers,
+    })
+  },
+}
+```
+
+Bundle with esbuild, inject config as a `define` constant (similar to Lambda's env var approach but baked into the bundle — CF Workers don't have a great env var story for large configs).
+
+### Upload format
+
+CF Workers API expects a multipart form upload with:
+- `metadata` part: JSON with `{ "main_module": "index.mjs", "compatibility_date": "..." }`
+- `index.mjs` part: the bundled worker code
+
+### Endpoint
+
+After deploy, the worker is available at `https://{worker-name}.{account-subdomain}.workers.dev`. The deploy command prints this URL.
+
+### Worker metadata / discovery
+
+For `ls` to discover CF Workers deployed by cors-prxy, embed metadata in the worker script name or use the CF Workers API to list scripts and check for a naming convention: `cors-prxy-{name}`.
+
+## New files
+
+```
+src/
+  cloudflare.ts      # CF Workers entry point (bundled + uploaded)
+  deploy-cf.ts       # CF API interactions (deploy, destroy, list)
+scripts/
+  bundle-cloudflare.js  # esbuild bundler for CF Worker
+```
+
+`deploy.ts` becomes `deploy-lambda.ts` (rename for clarity), and `deploy.ts` becomes a dispatcher:
+
+```typescript
+export async function deploy(config: CorsProxyConfig) {
+  const runtime = resolveRuntime(config)
+  if (runtime === "cloudflare") {
+    const { deployCf } = await import("./deploy-cf.js")
+    return deployCf(config)
+  }
+  const { deployLambda } = await import("./deploy-lambda.js")
+  return deployLambda(config)
+}
+```
+
+Same pattern for `destroy`.
+
+## `ls` across runtimes
+
+```sh
+cors-prxy ls                    # list all (both runtimes)
+cors-prxy ls --runtime lambda   # Lambda only
+cors-prxy ls --runtime cloudflare  # CF only
+```
+
+Output table adds a RUNTIME column:
+
+```
+NAME              RUNTIME      ENDPOINT                                    ALLOW
+aws-static-sso    cloudflare   https://cors-prxy-aws-static-sso.x.workers.dev  oidc.*.amazonaws.com
+og-crd            lambda       https://abc123.lambda-url.us-east-1.on.aws      github.com
+```
+
+## Migration path
+
+Existing `.cors-prxy.json` configs without `runtime` that have `region` set continue to deploy as Lambda (backwards compat). New configs default to Cloudflare.
+
+To migrate an existing Lambda proxy to CF:
+1. Add `"runtime": "cloudflare"` + `cloudflare.accountId` to config
+2. `cors-prxy deploy`
+3. Update consumers to new endpoint
+4. `cors-prxy destroy --runtime lambda` to clean up old Lambda
+
+## Environment variables
+
+| Var | Description |
+|-----|-------------|
+| `CLOUDFLARE_API_TOKEN` | CF API token (same as wrangler) |
+| `CLOUDFLARE_ACCOUNT_ID` | CF account ID (fallback if not in config) |