Hono on Node vs Edge

Deploy the same Hono API on Node 24 or edge runtimes (Cloudflare Workers, Deno, Bun) with portability trade-offs.

Recipe

Quick-reference portability pattern.

// shared app (runtime-agnostic)
import { Hono } from "hono";
 
export const app = new Hono();
 
app.get("/health", (c) => c.json({ ok: true }));
app.get("/users/:id", (c) => c.json({ id: c.req.param("id") }));
 
// Node entry: src/node.ts
import { serve } from "@hono/node-server";
import { app } from "./app.js";
serve({ fetch: app.fetch, port: 3000 });
 
// Cloudflare Worker entry: src/worker.ts
import { app } from "./app.js";
export default app;

When to reach for this: APIs that must run on both traditional servers and edge/CDN for latency or multi-runtime strategy.

Working Example

Portable app with runtime-specific adapters:

// app.ts - shared routes
import { Hono } from "hono";
import { cors } from "hono/cors";
 
export function createApp() {
  const app = new Hono();
  app.use("*", cors());
  app.get("/api/status", (c) => c.json({ runtime: "hono" }));
  return app;
}
 
// node.ts
import { serve } from "@hono/node-server";
import { createApp } from "./app.js";
 
const app = createApp();
serve({ fetch: app.fetch, port: Number(process.env.PORT ?? 3000) });
 
// worker.ts (Cloudflare)
import { createApp } from "./app.js";
export default createApp();
 
// wrangler.toml
// name = "my-api"
// main = "src/worker.ts"
// compatibility_date = "2024-01-01"

What this demonstrates:

• Shared createApp() factory for all runtimes
• Node uses @hono/node-server; Workers export the app directly
• CORS and routes are runtime-agnostic
• Environment config differs per deployment target

Deep Dive

Runtime Comparison

What Portes Cleanly

• Route definitions and middleware
• JSON request/response handling
• Zod validation via @hono/zod-validator
• JWT auth via hono/jwt
• CORS and security headers

What Does Not Port

• node:fs, node:net direct usage
• Native database drivers (use HTTP-based or edge-compatible)
• Long-running background tasks
• WebSocket (limited on Workers; use Durable Objects)

Gotchas

• Using Node-only APIs in shared code - breaks on Workers. Fix: abstract behind adapters; use fetch for I/O.
• PostgreSQL driver on edge - TCP not available on Workers. Fix: use Neon serverless driver, Supabase HTTP, or Prisma Accelerate.
• Assuming unlimited CPU - Workers have CPU time limits. Fix: keep handlers fast; offload heavy work to queues.
• Environment variables differ - process.env on Node, env binding on Workers. Fix: pass config into createApp(config).
• No persistent connections on edge - each request is isolated. Fix: use Durable Objects or external state store.
• Testing only on Node - edge runtime surprises in production. Fix: test with wrangler dev or Miniflare.

Alternatives

FAQs

Related

• Hono Basics - getting started
• Serverless Basics - serverless patterns
• Cold Start Mitigation - edge cold starts
• Framework Selection Checklist - full matrix
• Lightweight Frameworks Best Practices - section checklist

External Related Links

• Fastify - High-performance web framework docs.
• Koa - Lightweight middleware framework.
• MDN Web Docs – Express/Node.js - Beginner-to-intermediate Express/Node tutorials.
• Get Programming with Node.js - Introductory programming with Node.js.
• Node.js Cookbook, 5th Edition - Practical server-side recipes.

Stack versions: This page was written for Node.js 24.18.0 (Active LTS), npm 10+, TypeScript 5.6+, Express 5, Fastify 5, and NestJS 11.