Hono targets eight runtimes with one request model
Hono builds routing and middleware around the Web-standard Request and Response interfaces. The README names 8 targets: Cloudflare Workers, Fastly Compute, Deno, Bun, Vercel, AWS Lambda, Lambda@Edge, and Node.js. A basic route receives a context and returns text, JSON, or another response. That common shape is the reason to choose Hono. A team can move more application code between an edge worker and a conventional server without replacing its router.
Portability has limits. Static files, WebSockets, environment bindings, and access to a server's native objects differ by adapter. Hono keeps the handler model consistent, while each host still owns process lifetime, filesystem behavior, and platform services. Treat portability as a design constraint: keep most handlers on Web APIs, isolate adapter code, and run acceptance tests on every runtime you intend to support. Copying the same TypeScript file into 2 deployments does not prove identical behavior.
Node.js support starts at version 18 through an adapter
Hono's Node guide says the framework was not originally designed for Node.js and now runs there through @hono/node-server. It documents minimum releases within Node 18.x, 19.x, and 20.x, and recommends a current release in each line. The adapter wraps node:http and returns the underlying server. Your application therefore owns graceful shutdown for signals such as SIGINT and SIGTERM.
Node-specific work is available when needed. The context exposes incoming and outgoing server objects, serveStatic reads from the local filesystem, and WebSockets use the Node server package plus ws. One documented trap is that a static root resolves from process.cwd(), so starting the process from another directory can break file lookup. The guide suggests resolving from import.meta.url when the path must stay tied to the source file.
What happened when we ran it
Our sandbox cloned commit 499c35e with 3 CPUs, 8 GB of RAM, Node 22, and no secrets. The checkout held 486 files, roughly 84,863 lines of source, and used 4.7 MB. Installation succeeded in 35 seconds, added 872 packages, and left 765 MB on disk. The build then succeeded in 12 seconds. Those figures describe repository development, not the dependency footprint of a small app that imports Hono.
The test command failed after 22 seconds with exit code 1. TypeScript compilation ran first, then Vitest stopped during startup. Rolldown tried to import formatWithOptions and styleText from node:util, and the runtime reported that styleText was not exported. No assertion count followed because Vitest did not start its run. The tail does not identify whether the mismatch came from the runtime image, the installed toolchain, or project configuration, so we do not assign a cause.
Our repository scan found 5 CI workflow files, no Dockerfile, and no tests directory. Test files are colocated in the source tree, and the package defines separate commands for Deno, Bun, Node, workerd, Lambda, and Lambda@Edge. That is a serious runtime matrix, but our single failed command remains a failed result. A prospective contributor should reproduce the pinned Bun workflow and the runtime-specific jobs before treating the checkout as green.
The 765 MB contributor install is the hidden setup cost
Starting an application is much lighter than preparing the framework repository. The public quick start is one create-hono command, and a basic app needs no account or secret. By contrast, the contribution guide tells developers to install Bun and use a frozen lockfile. The checked package identifies Bun 1.2.20, while our development install brought 872 packages onto disk. That difference matters for onboarding, CI caches, and source builds.
A Node deployment adds @hono/node-server; WebSockets add ws; other targets bring their own command-line tools, credentials, and resource bindings. Hono does not provision Cloudflare, AWS, Vercel, or Fastly for you. The repository also has no Dockerfile, although the Node guide supplies an example application image based on Node 22 Alpine. Deployment is approachable once a runtime is chosen, but there is no single production recipe that covers all 8 targets.
v4.13.5 fixed three security paths worth checking
Release v4.13.5 arrived on August 26, 2026 with 3 security fixes. One stops query parsing after a URL fragment so Hono does not disagree with a proxy, cache, WAF, or logger about parameters. Another closes a remaining path escape in static-site generation. The third limits dot-notation nesting in body parsing to prevent disproportionate memory allocation. The release specifically urges affected users to upgrade.
That release is evidence of maintenance and a reminder to pin deliberately. Hono covers caching, authentication helpers, parsing, streaming, static generation, and many deployment adapters, so security exposure depends on which pieces an application uses. Open issue 5299, filed August 25, reports that an invalid Server-Sent Events retry value may inject fields into a frame; the report says its finding came from static analysis and was not executed. Verify its status before relying on that path.
The August 27 push and 370-item queue show active maintenance
GitHub recorded the last push on August 27, 2026, one day after v4.13.5. The repository had 31,977 stars and 370 combined issues and pull requests when fetched. Fresh reports and proposed fixes were being updated on August 25 and 26. That activity supports a healthy maintenance judgment, while the combined open figure describes work in progress rather than 370 confirmed defects.
The project also maintains an open v5 feature list. Its wording says the team aims to implement those items, including ESM-only packaging, separate adapter packages, response validation, and type changes. Those are aspirations for the next major release, not promises with a ship date. For a new service, Hono v4 is a strong choice when runtime flexibility pays for adapter testing. A Node-only team with years of Express middleware should demand a clearer migration benefit before switching.