株式会社オブライト
Web Development2026-04-24

Hono + Inertia + React Deployment Guide — Cloudflare Workers / Vercel / Bun: Choosing Your Stack and CI/CD [2026]

A practitioner's guide to deploying Hono + Inertia + React in production. Compares Cloudflare Workers, Vercel, Fly.io, Bun on VPS, and Node on ECS; covers SSR, cold start, edge vs region, GitHub Actions, environment variables, and monitoring.


Deploy choice = runtime × location × ops overhead

Because Hono runs everywhere, picking a deploy target is the first big decision. Three axes: - Runtime: Workers / Vercel Functions / Node / Bun - Location: edge (everywhere) or specific regions (Tokyo, Osaka, etc.) - Ops overhead: managed (Workers / Vercel), DIY VPS, or containers (ECS / Cloud Run) Combining these three narrows down to 3–5 plausible options quickly.

Deploy target matrix

TargetRuntimeLocationOps overheadStrengthsWeaknesses
Cloudflare WorkersWorkersEdgeLowFastest cold start, low cost, globalNo long jobs, bundle limits, compat care
Vercel (Functions)Node / EdgeSelectableLowPolished UI, Hono worksVendor flavor, pricing
Fly.ioNode / BunMulti-regionMediumEasy Postgres co-location, long-running OKLearning curve
Bun on VPS / ECSBunRegionHighTotal freedom, Bun startupYou own everything
Node on ECS / Cloud RunNodeRegionMediumReuses existing opsCold start a bit slower

Recommendations by project type

- Global SaaS / marketing-leaning sites: Cloudflare Workers - Domestic Japan business systems / internal tools: Vercel (Tokyo region) or Fly.io (Tokyo). Fly.io / Render / Railway are nice when you want Postgres alongside - AWS-heavy enterprise: ECS Fargate / Cloud Run - Small-scale, single-box: Bun on a VPS (Sakura, Vultr, Hetzner) - Enterprise SLA / audit needs: Vercel Enterprise or a dedicated cloud For Japan-domestic apps, "Workers + Tokyo Postgres via Hyperdrive" is increasingly viable in production.

SSR or not?

Inertia supports SSR, but you don't always need it. - SEO-critical pages: SSR recommended - Behind login walls only: CSR is fine - First-paint speed matters most: SSR tends to win SSR puts a React renderer on your Hono server, raising build/operation overhead. Better to start without it and turn it on per-page when needed.

CI/CD — minimum GitHub Actions

Minimum workflow on GitHub Actions: 1. trigger: push to `main` and PR 2. install: `bun install` 3. lint / typecheck: `bun run lint`, `bun run typecheck` 4. test: `bun test` 5. build: `bun run build` (client + server) 6. deploy: - Cloudflare Workers: `wrangler deploy` - Vercel: `vercel --prod` (or Vercel Git integration auto-deploys) - Fly.io: `flyctl deploy` Production deploys only on `main`; PRs go to preview environments.

Environment variables & secrets

Secret handling per target: - Cloudflare Workers: `wrangler secret put`; locally `.dev.vars` - Vercel: dashboard env vars; or `vercel env` - Fly.io: `flyctl secrets set` - VPS: `.env` encrypted via sops / age, or Vault / AWS Secrets Manager Common rules: never commit secrets, use distinct keys per env, define rotation up front.

Monitoring & logs

Bare-minimum production observability: - Errors: Sentry on both client and server - App logs: Logpush / Logtail on Workers, Vercel Logs on Vercel; otherwise route to Datadog / Better Stack / Loki - Uptime: Better Stack / UptimeRobot - APM: Datadog APM or Cloudflare Workers Analytics, as needed - DB slow query log: especially valuable for business apps Mirroring summaries to a Slack/Discord channel pairs nicely with code-review culture.

Common pitfalls

- Workers size limits: Node-native modules in your bundle blow up — use the `nodejs_compat` flag or alternative libraries - Cookie / session stores: in-memory stores aren't usable on Workers — use KV / D1 / external Redis - File uploads: send large files directly to R2 / S3, not through the server - Cron: Workers Cron Triggers / Vercel Cron / external schedulers — pick per case - Timezones: explicitly set `Asia/Tokyo` for JP audiences and align server, DB, client

Where this lands at Oflight

We mix Cloudflare Workers / Vercel / Fly.io / managed VPS based on project shape. For mid-sized internal-tool / business-system work, "Hono + Inertia + React on Vercel or Fly.io + Postgres" tends to hit the cost / ops / speed sweet spot. When AI features are involved, we combine with AI Consulting or OpenClaw for hybrid setups that take advantage of edge runtimes.

Series wrap-up

This concludes the series: - Part 1: stack overview & why - Part 2: setup guide - Part 3: forms & CRUD - Part 4: authentication - Part 5 (this post): deployment End-to-end, this is a working full-stack alternative to Next.js / Remix. To talk about applying it to your project or to scope a PoC, see Web Development / Software Development / Contact.

FAQ

Q1: Workers or Vercel — what's the first cut? A: Workers for global + cost; Vercel for DX, polish, and team familiarity. For Japan-domestic apps, Vercel Tokyo or Fly.io Tokyo are the easy picks. Q2: Multi-region DB? A: Workers + Hyperdrive can proxy to external Postgres; Neon / Turso / D1 are also options. CRUD-heavy business apps often do fine on a single Tokyo region. Q3: Rollback? A: Both Vercel and Workers support instant rollback to the prior deploy. Just decide up front how DB migrations interact with rollback. Q4: Do we need a staging environment? A: Strongly recommended for business systems. Combine per-PR preview environments with a longer-lived staging environment for pre-release verification.

References

Feel free to contact us

Contact Us