From Express to Hono: A Practical Migration Guide for Node.js Developers

If you’ve built Node APIs in the last decade, you’ve almost certainly used Express. It’s the tutorial default, the mental model for middleware, and the stack behind countless production apps.

It’s also built for a world where “the server” meant a long-lived Node process talking over http.IncomingMessage and ServerResponse.

That world still exists. But it’s no longer the only world.

Edge and serverless runtimes — Cloudflare Workers, Netlify Edge, Deno Deploy, AWS Lambda, Google Cloud Run, Fly.io, Bun, and others — increasingly expose Web Standard Request / Response and fetch, not Express’s req / res. Teams that want one codebase for Node and the edge are hitting a wall with Express-shaped frameworks.

Hono is one answer: a small router that speaks fetch first, with adapters for Node, Workers, Bun, and Deno.

This post is about what an Express → Hono migration actually looks like: the ecosystem map, the wins, the tradeoffs, and how edge deployment fits in. (I recently went through this on an early-stage SSR project; the patterns generalize beyond any single framework.)

Two runtimes, two HTTP models

Express is mature, huge, and well understood. Porting it to Workers means adapters, shims, and often giving up middleware that assumes Node globals or streams.

Hono’s core contract is:

app.fetch(request) → Response

On Node, @hono/node-server turns that into http.createServer. On Cloudflare, you export the same fetch handler. Same app shape, different host.

That’s the strategic reason teams migrate — not because Express is “bad,” but because the platform map changed.

What usually moves when you leave Express

You rarely swap only express for hono. Satellite packages come along.

You gain fewer transitive deps and a stack aligned with modern runtimes. You lose “install one package, everything works exactly like the docs from 2016.”

The pros of moving to Hono

1. Edge and multi-runtime deployment become realistic

Workers and similar edge platforms want a **fetch export**, not app.listen(3000).

Hono is designed for that. Node is an adapter target, not the only target. If your roadmap includes “API on the edge, SSR on Node,” Hono removes the fantasy layer.

2. Smaller core, less per-request overhead

Hono is intentionally minimal. For high-traffic APIs or SSR with many middleware layers, a lighter router can matter. Benchmarks vary by workload; the architectural point is: less framework between you and fetch.

3. Testing without binding ports

const res = await app.fetch(new Request('http://localhost/users'));
const body = await res.json();

Same code path production edge would use. No supertest, no ephemeral port races in CI. Tests get faster and flakier port conflicts go away.

4. Modern async middleware

Hono middleware is async (c, next) => { ... } on a Context object (c.req, c.json(), c.set()). It matches how people write Node today. No callback pyramid unless you bring it yourself.

5. TypeScript-first ergonomics

Routes, bindings, and env types integrate cleanly — especially for Workers where env is part of the contract. Express typings exist but often fight generic route params and edge bindings.

6. Ecosystem momentum

Cloudflare documents Hono prominently. Adapters for Bun and Deno are maintained. For greenfield services targeting “Node now, edge later,” Hono is a credible default — not a science project.

7. First-class fit for edge data (Cloudflare D1, KV, R2 — and equivalents elsewhere)

On Express + Node, talking to Cloudflare usually means HTTP calls from your VPS into Cloudflare’s API — extra latency, API tokens in env, and logic that lives far from where users hit the network.

On Hono + Workers, bindings are injected on every request. Your handler runs next to the storage layer. That unlocks a different architecture:

D1 in practice — migrations are SQL files; you query with the Workers API or ORMs that support D1 (e.g. Drizzle). A minimal Hono route:

type Env = { DB: D1Database }

const app = new Hono<{ Bindings: Env }>()
app.get('/posts', async (c) => {
  const { results } = await c.env.DB.prepare(
    'SELECT id, title FROM posts ORDER BY created_at DESC LIMIT 20'
  ).all()
  return c.json(results)
})

No TCP connection from a datacenter in Virginia to a database in Frankfurt on every request — the query runs in Cloudflare’s network, close to the user. For read-heavy, globally distributed APIs, that latency profile is hard to replicate with Express on a single region.

KV + Hono — cache expensive lookups, store JWT blocklists, or implement sliding-window rate limits without Redis on a sidecar:

app.get('/api/profile', async (c) => {
  const cacheKey = `profile:${c.req.header('Authorization')}`
  const cached = await c.env.KV.get(cacheKey, 'json')
  if (cached) return c.json(cached)

const profile = await loadProfile(c.env.DB, c)
  await c.env.KV.put(cacheKey, JSON.stringify(profile), { expirationTtl: 60 })
  return c.json(profile)
})

R2 + Hono — serve or accept uploads without bolting multer + disk paths on Node; stream from R2 in the same Worker that handles auth:

app.put('/upload/:key', async (c) => {
  const body = c.req.raw.body
  if (!body) return c.text('Missing body', 400)
  await c.env.BUCKET.put(c.req.param('key'), body)
  return c.json({ ok: true })
})

Why this pairs with Express → Hono, not Express → Workers adapter: Express assumes req/res and a Node process. Cloudflare bindings (env.DB, env.KV) are designed for **fetch(request, env, ctx)**. Hono’s Bindings generic and middleware model match that shape; Express on Workers is always a translation layer.

Honest scope: D1 is SQLite — not a drop-in for every Postgres workload (complex analytics, huge writes, exotic extensions). KV is not a relational DB. The advantage is the right tool at the edge, not “replace all databases everywhere.”

8. One router, many platforms (not only Cloudflare)

Hono’s app.fetch is the portable entry. How you host it changes; the route handlers often do not.

AWS Lambda example — same routes, different adapter:

import { handle } from 'hono/aws-lambda'
export const handler = handle(app)

DynamoDB for key-value and single-table designs; S3 for uploads; RDS in a VPC when you need full Postgres but still want Lambda scale-to-zero on the HTTP layer.

Deno Deploy — often the smallest mental leap after Node:

Deno.serve(app.fetch)

Deno KV for cache/config; call external Postgres (Supabase, Neon) over fetch if you outgrow KV.

Bun — stay on one machine or ship a container; Hono is documented as a first-class citizen:

Bun.serve({ port: 3000, fetch: app.fetch })

Fly.io / Railway / Render — treat Hono like any Node app: listen() on a port, health checks, managed DB plugin. You get Hono’s ergonomics without going edge-first; migration from Express here is mostly the router swap, not a new deployment model.

Takeaway: Cloudflare D1/KV/R2 is the most integrated edge data story, but Hono’s value on AWS, Deno, Netlify, Bun, and classic Node is the same core idea — **fetch in, Response out** — so you are not locked to one vendor when you leave Express.

9. Deployment gets simpler (especially away from “always-on Node”)

Express on a VPS is familiar — but you still own process management (PM2, systemd), reverse proxy (nginx/Caddy), TLS certs, scaling, and health checks. Hono does not magically remove all ops, but on modern hosts the deploy unit is often smaller and more repeatable.

Concrete ease wins:

• One export, many hosts — the same app you test with app.fetch() is what Workers/Lambda/Deno execute; no separate “production server” file shape.
• Cloudflare: wrangler deploy pushes code + binds D1/KV/R2 from wrangler.toml; secrets via wrangler secret put. No VM to patch.
• Fly / Railway / Render: git-push or fly deploy; Hono on Node uses the same listen(PORT) habit as Express — swap router, keep deploy pipeline.
• AWS Lambda: hono/aws-lambda maps API Gateway events to your app; pay per request, no idle server cost for sporadic APIs.
• Docker: one Dockerfile with CMD running Node + @hono/node-server — same as Express containers, smaller image potential (fewer deps).
• CI/CD: run unit tests against app.fetch in GitHub Actions without opening ports; deploy step uploads the same bundle Wrangler/Lambda expects.
• Rollbacks: platform dashboards version Worker/Lambda releases; no SSH and git pull on a box at 2 a.m.
• Preview environments: branch deploys on Cloudflare/Netlify/Fly are common — each preview gets its own URL without provisioning a new VPS.

What does not get easier: designing split architecture (edge API + Node SSR), database migrations on D1, or IAM on AWS. Hono shortens the HTTP deploy path, not data modeling.

The cons (read this before you migrate)

1. Express is still the gravity well

More Stack Overflow answers, more legacy middleware, more hiring familiarity. Hono is growing fast but is not Express. Onboarding and “find a package for X” take more research.

2. Breaking changes are real

A compat layer (wrapping Hono context as fake req/res) can defer pain. It adds complexity and hides leaks (e.g. res.render, stream APIs, res.on('finish')).

3. Not everything runs on the edge

Knex, native addons (bcrypt, sharp), filesystem SSR, long CPU work — still belong on Node. Migrating the router does not migrate your database or your Nunjucks templates to Workers. Plan split deployments, not “lift and shift the monolith.”

4. ESM/CJS footguns remain

Example from real migrations: hono-sessions → ohash v2 is ESM-only; require() on Node 18 CI breaks until you pin a CJS-compatible version or use dynamic import(). Edge-first packages sometimes assume ESM; Node 18 LTS still matters in enterprise CI.

5. Middleware marketplace is smaller

Need something exotic? Express probably has a middleware. Hono often needs a Hono-specific package, a thin wrapper, or five lines of custom code. Budget engineering time for gaps.

6. listen() is not the universal entry anymore

On Workers you export fetch. On Node you use @hono/node-server. Docs, examples, and platform tutorials diverge. Teams need a clear “this is how we deploy here” doc per environment.

Migration strategies that work

Strategy A — Big bang (small apps only) Replace Express, rewrite middleware to Hono, update tests to app.fetch. Fine for services with <20 routes and no plugin ecosystem.

Strategy B — Compat layer (medium apps, frameworks) Keep (req, res, next) at the boundary; translate to Hono Context internally. Slower to build, faster for consumers. Pay down compat debt over time.

Strategy C — Strangler (large apps) New routes on Hono (or a sub-app); old routes on Express behind a reverse proxy or mount path. Merge when confidence is high.

Strategy D — Edge split JSON/stateless APIs on Hono @ Workers; SSR, admin, uploads, DB on Node. Most honest architecture for full-stack apps today.

Deployment guide: Cloudflare, AWS, Deno, and the rest

Hono does not ship you to one host. Pick a platform, wire the adapter, keep your routes.

Cloudflare Workers (edge + integrated data)

export default {
  async fetch(request: Request, env: Env, ctx: ExecutionContext) {
    return app.fetch(request, env, ctx)
  },
}

env → D1, KV, R2, secrets (wrangler.toml). Best when you want SQL/cache/objects in the same network as the handler. Local: wrangler dev.

Netlify (edge functions + blobs)

Edge Functions with Hono; Netlify Blobs for object storage. Often used for form handling, lightweight APIs next to static sites. External DB via HTTP (Supabase, Fauna, custom API) is common.

Deno Deploy

Deno.serve(app.fetch) — minimal boilerplate. Deno KV built in; Postgres via hosted providers. Strong fit if you want to avoid Node entirely on the server.

AWS Lambda & API Gateway

hono/aws-lambda — mature adapter, IAM, VPC for RDS, DynamoDB + S3 at scale. Cold starts exist; keep handlers small. Good when compliance or existing AWS spend locks you in.

Google Cloud Run / Functions

Run Hono in a container (Cloud Run) with @hono/node-server for maximum compatibility, or Functions gen2 with a fetch-style handler where supported. Cloud SQL, Firestore, GCS — typical enterprise Google stack.

Fly.io, Railway, Render (always-on Node)

Standard app.listen(PORT) — closest to classic Express hosting. Fly Postgres, regional machines, optional volumes. Railway/Render: managed Postgres + Redis plugins, git-push deploy. Migration win here: swap Express for Hono without changing how you deploy; add edge later on another platform if needed.

Bun

Bun.serve({ fetch: app.fetch }) — fast startup, built-in SQLite for small apps, npm compatibility for most packages. Can deploy as Docker on any PaaS.

What moves easily (most platforms)

• REST/JSON APIs, JWT auth, redirects, webhooks
• BFF layers aggregating third-party HTTP APIs
• Cache layers (KV, Redis, Deno KV)
• Read-heavy routes and config/feature flags

What usually stays on full Node (any host)

• Heavy SSR from disk, large admin UIs
• Long CPU jobs, native addons (sharp, some PDF/crypto libs)
• ORM connection pools to regional Postgres without HTTP/edge drivers

Split architecture (vendor-agnostic)

User
    │
    ├─► Edge (CF / Netlify / Deno)  — Hono: auth, cache, public API
    │
    └─► Node (Fly / Railway / Lambda Node)     — Hono: SSR, admin, batch, Postgres

The win is not “pick Cloudflare or lose.” The win is Express no longer blocks you from deploying the same route style on whichever of these platforms matches your team, budget, and data plane.

Deployment ergonomics in practice

If you have shipped Express to a single DigitalOcean droplet, “easy deploy” means SSH and PM2. Hono’s sweet spot is platform-native deploy flows — less to glue yourself.

Minimal flows (copy-paste mental model)

Cloudflare Workers

# once
npm i -D wrangler
npx wrangler d1 create my-db

# wrangler.toml: name, main, [[d1_databases]], kv_namespaces, r2_buckets
npx wrangler deploy

No open ports, no TLS config on your side. D1 migrations: wrangler d1 migrations apply. Staging: wrangler deploy --env staging.

Fly.io (Node, always-on)

fly launch          # detects Dockerfile or generates one
fly postgres create # optional managed DB
fly deploy

Hono listens on process.env.PORT; Fly routes HTTPS to your machine. Scale regions with fly scale count / fly regions add.

Railway / Render

Connect the repo → set start command node server.js → env vars in UI → deploy on push. Same as Express, minus Express in package.json.

AWS Lambda

Build with your bundler (esbuild, SAM, CDK) → handler exports handle(app) from hono/aws-lambda → aws lambda update-function-code or CI pipeline. Ideal for APIs with bursty traffic and no 24/7 server bill.

Deno Deploy

deployctl deploy --project=my-api main.ts

main.ts is often ten lines: import app, Deno.serve(app.fetch).

Why this pairs with leaving Express

Express can run everywhere above — but edge runtimes do not natively “require Express.” You add @codegenie/serverless-express, API Gateway adapters, or Workers compatibility layers. Each layer is another deploy risk and cold-start cost.

Hono’s default shape is what those platforms expect. Fewer adapters → fewer “works in dev, 502 in prod” surprises.

Checklist before first production deploy

1. Entrypoint — export default { fetch }, handler = handle(app), or app.listen? Match the platform doc.
2. Env — secrets in dashboard / wrangler secret, not committed. Bind D1/KV IDs in config.
3. Tests — app.fetch in CI for routes; optional smoke curl after deploy.
4. Cold starts — keep middleware lean on Lambda/Workers; lazy-import heavy libs.
5. Node-only deps — if you use sharp or Knex, deploy that slice to Fly/Railway, not the edge Worker.

Quick pick: which platform when?

Express → Hono is the router migration. Platform choice is the ops migration — and with Hono, those two decisions can happen in either order.

VPS, “edge,” and open-source options (2026 reality check)

A fair question: if I only have a plain VPS (Hetzner, DigitalOcean, OVH, your own metal), is edge even possible? And are there open-source alternatives to managed Workers?

Short answer: one VPS in one datacenter is not geographic edge — but you still have good options. Hono fits all of them.

What “edge” actually means (vs one box)

SetupWhat you getSingle VPSOne region, one latency profile for distant users. This is origin hosting, not a global edge network.Multi-region VPS (EU + US + APAC) + geo DNSTraffic routed to nearest your server. “Poor man’s edge” — you operate N boxes.CDN in front of VPS (Cloudflare proxy, Bunny, Fastly)Static assets and cacheable HTML/API responses closer to users; dynamic hits still reach origin.Managed Workers / Lambda@EdgeCode runs on the provider’s PoPs — true edge compute.

Hono on a single VPS with @hono/node-server and app.listen() is the same deployment model as Express on that VPS — and that is perfectly valid. You migrate for a smaller HTTP core and optional fetch portability; you do not need Workers to benefit.

Platform-independent VPS: what Hono gives you there

On any VPS or Docker host you control:

import { serve } from '@hono/node-server'
serve({ fetch: app.fetch, port: process.env.PORT ?? 3000 })

• Full Node APIs (fs, native modules, long-lived DB pools).
• Caddy / nginx for TLS and reverse proxy — same as today.
• systemd / PM2 / Docker Compose — no Wrangler required.
• Postgres/Redis on the same machine or a managed DB — no D1 binding, no vendor lock-in.

Express → Hono on VPS is a router swap, not an edge mandate.

Open-source and self-hosted “Workers-like” runtimes (2026)

Managed Cloudflare Workers are proprietary hosting. The runtime, however, is increasingly available to self-hosters and for local dev.

Important caveats (still true in 2026):

• workerd is not a magic “free Cloudflare.” You do not get global anycast, D1, or KV unless you build or buy equivalents. You get the runtime and fetch semantics on hardware you operate.
• Cloudflare’s docs note workerd is not a hardened multi-tenant sandbox alone — do not run untrusted third-party code without extra isolation (VMs, separate accounts).
• Cap’n Proto config (config.capnp) for workerd has a learning curve vs app.listen(3000).

Practical paths on a budget (no vendor edge required)

Path 1 — Hono on Node, one VPS (simplest) Hetzner €5 box + Caddy + Postgres. You are done. No edge compute; honest and common.

Path 2 — VPS + CDN Same as Path 1; put Cloudflare (DNS proxy only), Bunny, or similar in front for cache/TLS/DDoS. Still origin-dynamic for Hono API unless you cache GET routes.

Path 3 — Multi-VPS + geo routing Three regions, three app.listen deploys, Route53/NS1 latency or geo DNS. You operate failover and schema replication.

Path 4 — Self-host workerd on VPS/K8s Write Hono for export default { fetch }; run via workerd in Docker on infrastructure you control. Closer to Workers semantics without Cloudflare account — you are SRE.

Path 5 — Managed edge when ready Same Hono code; add wrangler deploy or Deno Deploy later. VPS was staging; production edge is incremental.

How this fits the Express → Hono decision

• You do not need edge to justify Hono on a VPS.
• You do need fetch-shaped apps if you want the option of workerd, managed Workers, or Lambda without rewriting routes.
• Open source in 2026 means workerd + Deno/Bun + K8s serverless, not a single “Workers ISO” — pick ops complexity you can carry.

Geographic edge is a network and ops product. Hono is an HTTP API shape. A €5 VPS runs Hono happily; global edge is an upgrade path, not a prerequisite.

Where edge and Workers are headed (and why it matters for this migration)

Edge is not a buzzword cycle — it is a different place to run code, with different limits and different strengths. The next few years are less “everything leaves Node” and more “the right slice runs in the right place.”

What is likely to grow

1. Web Standards as the real portability layer WinterCG-style alignment means fetch, Request, Response, streams, and crypto show up in Workers, Deno, Bun, and Node (undici). Frameworks that assume that surface — Hono, not Express’s req/res — age better than adapter stacks bolted onto edge later.

2. More data close to the handler Cloudflare D1 is the visible example; the pattern is broader: SQLite and Postgres over HTTP (Neon, Turso, Supabase), edge KV, and connection poolers (Hyperdrive, similar products) so APIs do not round-trip to a single-region VPS for every read. Expect more “small SQL at the edge” and “cache + origin” patterns, not one giant monolith DB behind one Node process.

3. Stateful edge when it matters Durable Objects (Cloudflare) and analogous primitives elsewhere are for coordination: chat, locks, rate-limit coordinators, per-tenant state. Stateless Workers + regional SQL/KV stays the default; stateful edge is for problems that actually need it.

4. WASM at the edge Image transforms, parsers, sandboxed user logic — CPU work that does not fit JS time limits may move to WebAssembly modules invoked from the same fetch handler. Your HTTP layer still looks like Hono; heavy lifting becomes a WASM call.

5. Hybrid as the default architecture

Edge Worker     → auth, cache, public API, geo routing
  Node / container → SSR, admin, migrations, native libs, long jobs
  Queue / cron     → email, reports, ETL

Express-on-one-box is the legacy default; split deploy is the forward default. Hono makes the edge half of that diagram boring to write.

6. Ops: deploy velocity over server patching Teams will trade SSH and AMI updates for wrangler deploy, fly deploy, and Lambda versions — especially for APIs with global users. Security patches and TLS stay platform-managed; your job is smaller bundles and faster rollbacks.

What will stay hard (realistic limits)

• CPU and memory ceilings — Workers are not for minute-long video transcoding or 2 GB in-memory jobs.
• Incomplete Node APIs — fs, many native addons, some stream patterns — still push work to Node or containers.
• ORM / connection pool culture — Knex with 20 warm connections per instance does not map 1:1 to edge; you adapt with HTTP SQL drivers, smaller transactions, or keep ORM on Node.
• Debugging and observability — improving, but still different from node --inspect on a laptop. Budget time for platform logs and distributed traces.
• Vendor features ≠ portable features — D1 bindings are Cloudflare-specific; Hono routes are portable, data plane choices often are not. Design abstractions at the repository layer if multi-cloud is a goal.

What this means if you are choosing Hono today

Express → Hono is not a prediction that Workers replace Node. It is insurance that when your traffic is global, your API is read-heavy, or your bill for idle servers hurts — you can move the fitting part to the edge without rewriting routes in a different framework.

The platforms will keep competing on data (D1 vs Dynamo vs Deno KV), regions, and pricing. The HTTP layer that survives that competition is the one that speaks **fetch**. That is the future-facing half of this migration.

When to migrate — and when to stay on Express

Consider Hono if:

• You plan edge or multi-runtime deployment within 12–18 months
• You want edge or serverless data (Cloudflare D1/KV/R2, Deno KV, DynamoDB, Neon/Supabase over HTTP, etc.) colocated with HTTP handlers
• You want simpler deploy flows (Wrangler, fly deploy, Lambda handlers) instead of hand-rolled server + proxy + TLS
• You want fetch-native tests and a smaller HTTP core
• You’re greenfield or early enough that breaking changes are cheap
• Your team is comfortable reading Web Standard APIs
• You may stay on a plain VPS today but want workerd, managed Workers, or Lambda later without a second framework

Stay on Express if:

• The app is stable, team knows it cold, no edge plans
• You depend on obscure Express middleware with no Hono equivalent
• Migration cost > 2–3 sprints and nothing strategic improves
• You need maximum copy-paste from decade-old tutorials

Express is not dying tomorrow. Hono is not mandatory. Match the stack to the deployment story.

Lessons from the trenches

1. Document a migration table — old package → new package → breaking API. Future you will thank present you.
2. Run CI on Node 18 and 20 — ESM-only transitive deps still surprise people.
3. Isolate fetch in tests — global mocks in one file break HTTP tests in another (vi.unstubAllGlobals() if you use Vitest).
4. Benchmark after, not before — validate your actual routes, not hello-world.
5. Don’t sell edge until you have a split plan — “we use Hono” is honest; “we’re serverless everywhere” rarely is, on day one.

Bottom line

Express → Hono is a bet on Web Standards, smaller core, and deployment optionality — on Cloudflare, Netlify, Deno Deploy, AWS, GCP, Fly, Railway, Bun, or plain Node.

Pros: portable fetch handler, modern async middleware, better in-process tests, easier platform-native deploys (Workers, Lambda, Fly, Railway), multi-vendor edge/serverless — D1/KV/R2 on Cloudflare, Lambda + DynamoDB, Deno KV, and classic Node hosts without rewriting routes.

Cons: ecosystem gap vs Express, real breaking changes, edge still requires architectural split, ESM/CJS and compat-layer tax.

For new services that might live on Node and the edge, Hono is one of the most pragmatic defaults in 2026. For a quiet CRUD API on a single VPS with no edge roadmap, Hono on Node is still a solid choice — Express remains rational only if you are avoiding any migration cost entirely.

The migration is less about hype and more about not painting yourself into a Node-only corner while the cost of switching is still something you can afford — including a credible path as edge and Workers take a larger share of public APIs.

Sources & further reading

Frameworks & HTTP

• Hono — documentation and guides
• Hono (GitHub)
• @hono/node-server — Node adapter
• Hono AWS Lambda adapter
• Express
• WinterCG — Web-interoperable runtimes community

Cloudflare (Workers, runtime, data)

• Cloudflare Workers docs
• Wrangler CLI
• D1 (SQLite)
• Workers KV
• R2 object storage
• Durable Objects
• Queues
• Hyperdrive
• workerd (GitHub) — open-source Workers runtime
• Introducing workerd (Cloudflare blog)
• Miniflare — local Workers dev
• Hono on Cloudflare Workers

Other platforms & runtimes

• Deno · Deno Deploy · Hono on Deno
• Bun · Hono on Bun
• Netlify Edge Functions
• AWS Lambda
• Google Cloud Run
• Fly.io docs
• Railway · Render

Sessions, security, testing (migration-adjacent)

• hono-sessions
• Hono Secure Headers
• hono-rate-limiter (optional peer)

Self-hosted / OSS serverless

• OpenWorkers — self-hosting docs
• self-workerd (GitHub)
• OpenFaaS
• Knative

ORM / SQL at the edge (examples cited)

• Drizzle ORM — includes D1 support

If this was useful, follow for more on Node, edge runtimes, and framework internals. Questions welcome in the comments.