Choose Hono when: Deploying to Cloudflare Workers or any edge runtime Building a standalone REST API (not embedded in Next.js) You need OpenAPI spec generation for a public API You want type-safe API client without the full tRPC setup Migrating from Express and want modern TypeScript Choose tRPC (T3 Stack) instead when: Building a Next.js full-stack app with the server and client in one repo Your team already knows tRPC patterns You need subscriptions (real-time updates via tRPC)

Best Hono Backend Boilerplates 2026

Q: Why Hono in 2026?

Edge-first architecture. Hono was designed for Cloudflare Workers before it was adapted for Node.js. This means the API surface is clean — it works with the Fetch API natively (Request, Response, Headers) rather than Node.js-specific objects. Code written for Cloudflare Workers runs unchanged on Node.js, Bun, and Deno. Type-safe clients without tRPC. Hono's RPC mode exports the app type and an hc client that provides end-to-end TypeScript types without requiring a separate schema layer. It's lig

Hono crossed 1 million weekly npm downloads in 2025 — a milestone that puts it in serious company for a backend framework that's barely three years old. The growth is earned: Hono is a 14 KB TypeScript web framework that runs identically on Node.js, Cloudflare Workers, Bun, AWS Lambda, Deno, and Vercel Edge Functions. Write once, deploy anywhere.

The boilerplate ecosystem has caught up with the downloads. In 2026, there are official starters for every target runtime and a growing collection of community patterns for production API development. Here's what's worth using.

Why Hono in 2026?

Edge-first architecture. Hono was designed for Cloudflare Workers before it was adapted for Node.js. This means the API surface is clean — it works with the Fetch API natively (Request, Response, Headers) rather than Node.js-specific objects. Code written for Cloudflare Workers runs unchanged on Node.js, Bun, and Deno.

Type-safe clients without tRPC. Hono's RPC mode exports the app type and an hc client that provides end-to-end TypeScript types without requiring a separate schema layer. It's lighter-weight than tRPC with less setup.

14 KB total. The entire framework is 14 KB gzipped. Cold start times on Cloudflare Workers are imperceptible — the isolate initializes in under 5ms.

Zod validation built in. The @hono/zod-validator middleware validates request bodies, query params, and headers with Zod schemas, and the validated data is fully typed in route handlers.

Official: create-hono

The fastest starting point for any Hono project:

npm create hono@latest my-api
# Select runtime:
#   ▸ cloudflare-workers  ← Zero cold starts, global deployment
#     nodejs              ← Traditional server
#     bun                 ← Fastest TypeScript runtime
#     aws-lambda          ← Serverless on AWS
#     deno                ← Secure by default
#     vercel              ← Edge or serverless on Vercel
#     lambda-edge         ← CloudFront edge functions

Each template is pre-configured for its target runtime with the correct adapter and build setup.

Cloudflare Workers Template

// src/index.ts — production Cloudflare Workers app:
import { Hono } from 'hono';
import { cors } from 'hono/cors';
import { logger } from 'hono/logger';
import { secureHeaders } from 'hono/secure-headers';
import { rateLimit } from 'hono/rate-limiter';

type Bindings = {
  DB: D1Database;          // Cloudflare D1 (SQLite at edge)
  KV: KVNamespace;         // Cloudflare KV (key-value store)
  R2: R2Bucket;            // Cloudflare R2 (object storage)
  JWT_SECRET: string;
};

const app = new Hono<{ Bindings: Bindings }>();

app.use('*', cors({ origin: process.env.FRONTEND_URL ?? '*' }));
app.use('*', logger());
app.use('*', secureHeaders());

app.get('/health', (c) => c.json({ status: 'ok', runtime: 'cloudflare-workers' }));

export default app;

# wrangler.toml — Cloudflare Workers config:
name = "my-api"
main = "src/index.ts"
compatibility_date = "2026-01-01"

[[d1_databases]]
binding = "DB"
database_name = "my-db"
database_id = "your-db-id"

[[kv_namespaces]]
binding = "KV"
id = "your-kv-id"

Node.js Template

// src/index.ts — Node.js server:
import { Hono } from 'hono';
import { serve } from '@hono/node-server';
import { cors } from 'hono/cors';

const app = new Hono();
app.use('*', cors());
app.get('/', (c) => c.text('Hello from Hono on Node.js!'));

const port = Number(process.env.PORT ?? 3000);
serve({ fetch: app.fetch, port }, (info) => {
  console.log(`Server running on http://localhost:${info.port}`);
});

Community Starter: Hono + Drizzle + JWT Auth

The most popular community pattern for production Hono APIs — a complete backend with Drizzle ORM, JWT authentication, and organized route handlers:

npm install hono @hono/node-server @hono/zod-validator
npm install drizzle-orm drizzle-kit
npm install @paralleldrive/cuid2
npm install --save-dev tsx

// src/db/schema.ts:
import { pgTable, text, timestamp, boolean } from 'drizzle-orm/pg-core';

export const users = pgTable('users', {
  id: text('id').primaryKey().$defaultFn(() => createId()),
  email: text('email').notNull().unique(),
  passwordHash: text('password_hash'),
  name: text('name'),
  emailVerified: boolean('email_verified').default(false),
  createdAt: timestamp('created_at').defaultNow().notNull(),
});

export const sessions = pgTable('sessions', {
  id: text('id').primaryKey(),
  userId: text('user_id').notNull().references(() => users.id, { onDelete: 'cascade' }),
  expiresAt: timestamp('expires_at').notNull(),
});

// src/routes/posts.ts — typed route handlers with auth:
import { Hono } from 'hono';
import { zValidator } from '@hono/zod-validator';
import { jwt } from 'hono/jwt';
import { z } from 'zod';
import { db } from '../db';
import { posts } from '../db/schema';
import { eq, desc } from 'drizzle-orm';

export const postsRouter = new Hono()
  .use('*', jwt({ secret: process.env.JWT_SECRET! }))

  .get('/', async (c) => {
    const allPosts = await db.select().from(posts)
      .orderBy(desc(posts.createdAt))
      .limit(20);
    return c.json(allPosts);
  })

  .post('/', zValidator('json', z.object({
    title: z.string().min(1).max(200),
    content: z.string().min(1),
  })), async (c) => {
    const { title, content } = c.req.valid('json');
    const payload = c.get('jwtPayload');

    const [post] = await db.insert(posts).values({
      title, content, authorId: payload.sub,
    }).returning();

    return c.json(post, 201);
  });

// src/index.ts — compose routes:
import { Hono } from 'hono';
import { serve } from '@hono/node-server';
import { cors } from 'hono/cors';
import { postsRouter } from './routes/posts';
import { authRouter } from './routes/auth';

const app = new Hono()
  .use('*', cors({ origin: process.env.FRONTEND_URL }))
  .route('/auth', authRouter)
  .route('/api/posts', postsRouter);

// Export type for Hono RPC client:
export type AppType = typeof app;

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

Hono RPC: Type-Safe Client Without tRPC

Hono's built-in RPC system provides end-to-end type safety without a separate schema layer:

// Frontend — fully typed, no codegen needed:
import { hc } from 'hono/client';
import type { AppType } from '../server/src/index';

const client = hc<AppType>(process.env.NEXT_PUBLIC_API_URL!);

// TypeScript knows the return type automatically:
const response = await client.api.posts.$get();
const posts = await response.json();  // typed as Post[]

const newPost = await client.api.posts.$post({
  json: { title: 'Hello', content: 'World' },
});

This is the Hono equivalent of tRPC — you share the AppType type from the server, and the client has full type inference for all routes, request bodies, and response shapes. The difference from tRPC: no separate schema definition step, no codegen, and it works across different servers (not just Node.js + Next.js).

OpenAPI Documentation Starter

For public APIs that need documentation:

npm install @hono/zod-openapi @hono/swagger-ui

import { OpenAPIHono, createRoute, z } from '@hono/zod-openapi';

const app = new OpenAPIHono();

const PostSchema = z.object({
  id: z.string().openapi({ example: 'clq8a1b2c0000abc123' }),
  title: z.string().openapi({ example: 'Hello World' }),
  content: z.string(),
  createdAt: z.string().datetime(),
});

const createPostRoute = createRoute({
  method: 'post',
  path: '/posts',
  request: {
    body: { content: { 'application/json': { schema: PostSchema.omit({ id: true, createdAt: true }) } } },
  },
  responses: {
    201: { description: 'Post created', content: { 'application/json': { schema: PostSchema } } },
    400: { description: 'Validation error' },
    401: { description: 'Unauthorized' },
  },
  tags: ['posts'],
  summary: 'Create a new post',
});

app.openapi(createPostRoute, async (c) => {
  const body = c.req.valid('json');
  // Implementation...
  return c.json({ id: 'new-id', ...body, createdAt: new Date().toISOString() }, 201);
});

// Auto-generate OpenAPI spec at /doc:
app.doc('/doc', { openapi: '3.0.0', info: { title: 'My API', version: '1.0.0' } });

// Swagger UI at /ui:
app.get('/ui', swaggerUI({ url: '/doc' }));

Hono vs Express vs Fastify

Factor	Hono	Express	Fastify
Bundle size	14 KB	~500 KB	~300 KB
TypeScript	Native	Via @types	Native
Edge deployment	✅ Native	❌	❌
Validation built-in	✅ Zod	❌	✅ JSON Schema
RPC client	✅ Native	❌	❌
OpenAPI generation	✅	❌	Via plugin
Ecosystem maturity	Growing	Very large	Large
Middleware quality	Good	Large legacy	Good

Express has the largest ecosystem but no TypeScript support and no path to edge deployment. Fastify has better TypeScript and performance than Express. Hono wins on edge deployment, bundle size, and the type-safe RPC client.

Starter Templates by Runtime

Target	Template	Key Packages	Best For
Cloudflare Workers	`create-hono` (cloudflare)	Hono + D1 + Drizzle	Zero cold starts, global
Node.js	`create-hono` (nodejs)	Hono + PostgreSQL + Drizzle	Traditional server
Bun	`create-hono` (bun)	Hono + Bun + Drizzle	Fastest TypeScript runtime
Vercel Edge	`create-hono` (vercel)	Hono + KV	Vercel-based edge APIs
Full-stack	Manual	Hono + Next.js + Hono RPC	Type-safe API for Next.js

When to Choose Hono

Choose Hono when:

Deploying to Cloudflare Workers or any edge runtime
Building a standalone REST API (not embedded in Next.js)
You need OpenAPI spec generation for a public API
You want type-safe API client without the full tRPC setup
Migrating from Express and want modern TypeScript

Choose tRPC (T3 Stack) instead when:

Building a Next.js full-stack app with the server and client in one repo
Your team already knows tRPC patterns
You need subscriptions (real-time updates via tRPC)

Hono Middleware Ecosystem

Hono ships a comprehensive middleware library built-in — no separate packages needed for common patterns:

Middleware	Import	What It Does
`cors`	`hono/cors`	CORS headers with origin whitelist
`logger`	`hono/logger`	Request/response logging
`jwt`	`hono/jwt`	JWT verification middleware
`bearer-auth`	`hono/bearer-auth`	Bearer token auth
`rate-limiter`	`hono/rate-limiter`	Rate limiting (requires Redis)
`secure-headers`	`hono/secure-headers`	Security headers (CSP, HSTS, etc.)
`compress`	`hono/compress`	Gzip/Brotli response compression
`cache`	`hono/cache`	Response caching
`etag`	`hono/etag`	ETag header generation
`timeout`	`hono/timeout`	Request timeout handling

Unlike Express where you add express-rate-limit, helmet, cors as separate packages with separate maintenance cycles, Hono's middleware is first-party and always API-compatible with the current Hono version.

Deployment Patterns by Runtime

Cloudflare Workers + D1 (Edge-Native)

# Initialize and deploy:
npm create hono@latest my-api -- --template cloudflare-workers
cd my-api
npm install drizzle-orm @cloudflare/d1  # Add Drizzle for D1

# Create D1 database:
npx wrangler d1 create my-db

# Run migrations:
npx wrangler d1 execute my-db --file=./drizzle/migrations/0000_initial.sql

# Deploy globally:
npx wrangler deploy

The result: a globally distributed API with zero cold starts running on Cloudflare's edge network. Response times are typically 5-30ms anywhere in the world.

Node.js + PM2 (Traditional VPS)

# Build:
npx tsc -p tsconfig.json

# Run with PM2 for process management:
pm2 start dist/index.js --name my-api
pm2 save
pm2 startup  # Auto-restart on server reboot

Bun (Fastest Single-Server)

# No transpile step needed — Bun runs TypeScript natively:
bun src/index.ts

# Or with watch mode:
bun --watch src/index.ts

Bun's startup time is ~3ms vs Node.js's ~50ms. For development iteration cycles, this difference is noticeable.

When Hono Outperforms tRPC

The Hono vs tRPC decision comes up frequently for Next.js developers considering a separate API service. Key differences:

Choose Hono when your API is standalone. If the frontend and backend are in separate repos, separate deployments, or consumed by multiple clients (web, mobile, third-party), Hono with its RPC client or OpenAPI spec is cleaner than tRPC's monorepo assumptions.

Choose tRPC when you're in a Next.js monorepo. tRPC's integration with Next.js Server Components, React Query, and the App Router is seamless. If your whole stack is in one repo and Next.js is the only consumer, tRPC reduces ceremony.

The hybrid approach: Some teams use tRPC for the Next.js app routes and Hono for a separate API service exposed to third parties. The internal product uses tRPC's type safety; external developers use the Hono OpenAPI endpoint with Swagger docs.

See the best Bun + Hono SaaS starter kits guide for starters that combine Bun's runtime speed with Hono's edge deployment capabilities. For backend API comparisons with other frameworks, browse StarterPick with the API and backend filter.

Authentication in Hono APIs

Hono ships without auth built in — it is a routing and middleware framework, not a full-stack kit. Adding auth to a Hono backend is a deliberate design exercise rather than a configuration task. Understanding the patterns before starting saves architectural confusion.

JWT authentication is the most common pattern for standalone Hono APIs. The client (web or mobile app) authenticates against a separate auth service (Clerk, Better Auth, Supabase Auth) and receives a JWT. The Hono backend validates the JWT on each request using Hono's built-in JWT middleware. The token validation adds 1-3ms of latency on the server side — for edge deployments, this is negligible; for local development, it is invisible.

Session authentication is appropriate when Hono is serving a full-stack app where the browser is the primary client. Hono has a cookie middleware; sessions can be stored in a database (Drizzle + D1 or Drizzle + PostgreSQL) or in a Redis-compatible store (Cloudflare Workers KV for edge deployments). The Better Auth library integrates with Hono directly and handles session management, OAuth providers, and email magic links within the Hono runtime.

API key authentication is the right pattern for Hono APIs consumed by server-to-server integrations or developer tools. The pattern is simple: hash the API key on creation, store the hash in the database, and verify the hash on each request. Hono's middleware architecture makes this straightforward — create a middleware function that extracts the Authorization header, looks up the hashed key, and either populates the request context with the authenticated account or returns a 401. Never store API keys in plaintext; store the SHA-256 hash and compare hashes.

For teams building Next.js + Hono hybrid architectures, see the best SaaS boilerplates guide to understand which full-stack starters use Hono as their API layer versus which use Next.js API routes exclusively.

OpenAPI and Documentation for Hono APIs

One of Hono's most practical features for SaaS APIs is first-class OpenAPI support through @hono/zod-openapi. Unlike tRPC (which is TypeScript-only and not accessible to external developers), a Hono API with OpenAPI docs is self-documenting and accessible to any HTTP client — mobile apps, third-party integrations, internal tools, and external developers.

The @hono/zod-openapi package connects Zod schemas (the same schemas you use for runtime validation) to OpenAPI spec generation. Define your request and response schemas once in Zod, and the OpenAPI spec is generated automatically. Add Swagger UI with a single endpoint and your API has browser-accessible documentation without any separate documentation tooling. This pattern is particularly valuable for B2B SaaS products where enterprise customers want to verify API capabilities before committing.

The practical setup for a Hono API with OpenAPI documentation is an /api/spec endpoint that returns the OpenAPI JSON spec and a /docs endpoint that serves Swagger UI or Scalar (a more modern OpenAPI viewer). Both can be added in under an hour to any existing Hono application using the @hono/zod-openapi adapter.

For SaaS products that eventually need to expose a public API — allowing customers to automate workflows, build integrations, or access their data programmatically — starting with Hono and OpenAPI from day one is significantly less work than retrofitting OpenAPI onto a Next.js API route structure later. The production SaaS free tools guide covers how to expose a public API as part of a zero-cost infrastructure setup.

Browse Hono and backend boilerplates at StarterPick.

See the best SaaS boilerplates guide for full-stack starters that use Hono as their API layer.

Read the production SaaS free tools guide for the complete zero-cost API infrastructure stack.

The SaaS Boilerplate Matrix (Free PDF)