Deploy to Node and Workers

Start from the behavior you can observe. The Node version owns a listener and shutdown; the Worker version exports fetch and uses platform bindings.

Node and Workers differ in process lifecycle, sockets, filesystem access, environment, and platform limits even when Request and Response match. 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 copy the Node entry point into a Worker and patch failures one global at a time. That trades a clear decision for an assumption you will eventually have to debug. The stronger move is to isolate runtime entry points, audit dependencies for compatibility, and test both targets in their native local tools. Make the boundary explicit in code and in the project notes.

Tie the decision back to the larger job: Deploy the same core app to two runtimes while documenting real differences instead of claiming magical portability. Record enough evidence that another developer can repeat the result without relying on your memory.

Deploy health and bookmark routes to both targets and record differences in startup, configuration, storage, and logs. Repeat it once with an invalid or hostile condition and write down the boundary the failure revealed.