< 10ms
Cold start on every POP
P50 measured at the edge
Open source · Cloudflare Workers · MIT
Deploy Serverless APIs
in Milliseconds.
A config-driven API gateway for Cloudflare Workers. Centralize routing, JWT / Auth0 / Supabase auth, CORS, and request shaping in a single Worker replicated across every Cloudflare POP — no servers, no hand-rolled edge glue.
- Single-file config
- 300+ POPs globally
- Zero servers to run
~/my-gateway · edge.json
$ cat edge.json
"servers": [ "alias": "api", "url": "https://api.example.com" ], "paths": [ "method": "ANY", "path": "/api/{.+}", "jwt": true, "integration": "type": "http_proxy", "server": "api" ]
$ npx wrangler deploy
✓ Built Worker (120 ms)
✓ Deployed to 300+ POPs (2.3 s)
→ https://edge.example.com
300+
Cloudflare POPs
Globally replicated
99.99%
Uptime (Cloudflare SLA)
Inherits Workers availability
0
Servers to manage
Config + Worker only
Capabilities
Everything a Worker gateway needs. Nothing a CMS would ship.
Four primitives, all driven from the same config contract. Each card also calls out its explicit non-goals — because what a tool won’t do matters as much as what it will.
Routing
Exact, parameterized, wildcard, and method-aware paths resolved in config. Proxy to an upstream or respond statically without writing Worker branches.
exactparamwildcardANY
Not a goal: OpenAPI generation or automatic schema management.
Auth
Protect selected routes with JWT, plus Auth0 callback / profile / refresh flows and Supabase OTP + JWT verification flows.
jwtauth0supabaseper-route
Not a goal: hosted identity dashboard or API-key provisioning.
Request shaping
Inject headers and query values from verified claims, path variables, env vars, and gateway config before the upstream service sees the request.
headersqueryclaimsenv
Not a goal: general-purpose transformation studio.
Worker execution
Dispatch into Worker services, service bindings, pre-process hooks, and post-process flows when an HTTP proxy is not the right fit.
servicebindingprepost
Not a goal: replace broader workflow orchestration.
Request path
One request path. Four predictable stages.
Each stage is a single responsibility resolved from config — no tangled branching, no mystery edge glue. Inspect the flow the same way you inspect your routes.
- 01 Ingress
Request arrives at the nearest POP
Traffic lands on Cloudflare’s edge first. Routing and policy checks happen before upstream services ever absorb the request.
- 02 Policy layer
Gateway policy is evaluated once
JWT / Auth0 / Supabase checks, CORS handling, and variable expansion live in one contract instead of being repeated across services.
- 03 Route resolution
The integration is selected from config
Exact, parameterized, wildcard, proxy, and Worker-native service targets are chosen by the route matcher without bespoke branching code.
- 04 Response
The response returns through the same edge path
Mapped headers, static responses, and service outputs return through one gateway entrypoint with behavior that stays visible in code and tests.
Quickstart
Install, configure, deploy.
Three commands between you and a live edge gateway. No dashboards, no vendor wizards — just a Worker running in your account.
Install
Pull the repo and deploy the Worker into your Cloudflare account with Wrangler.
npm create serverless-api-gateway@latestConfigure
Describe routes, auth, CORS, and mapping in a single JSON contract instead of scattering them across handlers.
edit edge.jsonDeploy
Ship one public API entrypoint. Cloudflare replicates it across every POP in seconds.
npx wrangler deploy
Deep dives
Reads that match the stack you’re shipping.
Short, reader-first walkthroughs on routing, auth, CORS, and migration choices — every post is grounded in the code in this repository.
Tutorial
Build a Cloudflare Worker API gateway in 30 minutes
The minimal config contract that gets a first production proxy live without hand-rolling routing or auth.
Read the walkthrough →Auth
Protect one route, not your whole API
How to add JWT checks to selected paths without flipping every upstream route into an auth wall.
Read the walkthrough →CORS
Fix CORS at the gateway, not in every service
Why SPAs keep hitting CORS errors and how centralizing preflight at the edge stops the churn.
Read the walkthrough →Architecture
Proxy multiple backends behind one public domain
A reader-first pattern for composing several upstream services behind a single gateway entrypoint.
Read the walkthrough →Compare
Serverless API Gateway vs AWS API Gateway (2026)
A grounded comparison focused on routing, auth, and pricing — not vendor marketing.
Read the walkthrough →Edge
How to think about latency at the edge
What edge routing actually buys you and what it does not, with measurable signals to watch.
Read the walkthrough → FAQ
Common questions before rollout.
- Why use this instead of writing a custom Worker gateway?
- Because routing, auth, CORS, and request shaping are already implemented as one readable config contract instead of a growing pile of custom edge code.
- Does this replace every API management feature?
- No. It focuses on the gateway behaviors already present in the repo. It does not currently provide rate limiting, analytics dashboards, API key management, OpenAPI generation, or an admin UI.
- Can I keep traffic inside my own Cloudflare account?
- Yes. The project is open source and designed to deploy into your own Cloudflare environment, so you keep control over runtime and configuration.
- Is it production-ready?
- It powers the exact edge patterns described in the docs and repo tests. Adopt it the same way you would any OSS building block — read the code, deploy a staging gateway, and watch the signals described in the latency post.
Ready when you are
One Worker. One config.
Every Cloudflare POP.
Install in a minute, configure in a file, deploy in a command. Open-source, Worker-native, and running in your own account.