Choose a runtime adapter

Start from the behavior you can observe. One module exports the app; a Node adapter listens on a port; a Worker entry exports fetch behavior.

The Hono app can be shared, but startup, environment bindings, sockets, and some middleware remain runtime-specific. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.

It is tempting to assume framework portability means every dependency and API works identically everywhere. That trades a clear decision for an assumption you will eventually have to debug. The stronger move is to keep the core on common APIs and isolate adapter, storage, environment, and runtime-specific capabilities. Make the boundary explicit in code and in the project notes.

Tie the decision back to the larger job: Build the smallest portable Hono application and identify exactly which parts depend on its runtime. Record enough evidence that another developer can repeat the result without relying on your memory.

Run the same health route under two runtimes and list every file and dependency that differs. Repeat it once with an invalid or hostile condition and write down the boundary the failure revealed.