What changes for a web application when the HTTP server is embedded in its own process instead of an external server hosting it?

## Two hosting shapes, one contract The seam does not care who owns the process. A framework that speaks the adapter contract can be driven by a server the application started itself, or by a server that was already running and loaded the application into it. That is the whole point of the boundary: application code is the same, hosting is a deployment decision. What differs is **ownership** - and ownership is where operational surprises live. ## What actually differs | concern | embedded server | externally hosted server | |---|---|---| | process lifecycle | the application starts and stops the server | the server process exists independently and loads the application | | listener, port, transport security | configured by the application, versioned with it | configured by the operator, outside the application artifact | | timeouts and size caps | application configuration, shipped together | server configuration, applied to every hosted application | | deployment unit | a self-contained runnable artifact | a package deployed into a running server | | isolation | one application per process by construction | several applications may share one process and its resources | | startup order | application initialises, then binds the listener | the server may start accepting before an application is fully ready | ## The consequences that actually bite 1. **Configuration lives in different places.** With an embedded server, a change to timeouts or caps is a code or config change reviewed and deployed with the application. Hosted externally, the same change is an operations task on a shared server - and it affects every application in it. Teams get caught by this when a limit they believe they raised was raised in the artifact but the enforcing layer was elsewhere. 2. **Graceful shutdown is a negotiation.** Embedded, the application can stop accepting new requests, let in-flight requests drain, run its own cleanup and then exit, because it owns both halves. Hosted externally, draining is the server's behaviour and the application only gets whatever shutdown signal the host chooses to give it; an application that assumes it can finish long requests on the way down may be cut off. 3. **Readiness is not liveness.** Embedded servers commonly bind the listener as part of startup, so a bound port does not prove initialisation finished - the exposed readiness signal must come from the application, not from the port being open. 4. **Pre-hand-off errors look like the host.** Requests refused for size or framing are answered by whichever server parsed them, in that server's default format. Under an external server that format is not yours and may not even be consistent with your other applications. 5. **Resource isolation is coarser when shared.** Several applications in one server share its accept queue, its worker resources and its memory, so one misbehaving application degrades the others. One application per process trades that for more processes to operate. ## What does not differ Because the contract is the same, the things people expect to differ mostly do not: routing, the request object, the response model, how handlers are written, how the application is tested. A test that synthesizes a request and invokes the entry point is valid under both models, which is also the reason it proves nothing about hosting behaviour - limits, timeouts and shutdown are precisely what such a test does not exercise. ## How to choose Argue from operations, not from taste: - **Embedded** favours independent deployability, one artifact per service, configuration versioned with code, and straightforward per-service resource limits. It suits many small services deployed frequently, and it makes the application responsible for settings that used to be somebody else's. - **Externally hosted** favours centrally operated configuration, shared transport-security material, uniform policy applied to many applications at once, and environments where an operations team owns runtime settings by design. It suits fewer, larger deployments with a strong operations boundary. A third arrangement is common and blurs the question: an embedded server behind a reverse proxy. The application still owns its process, but caps, transport security and connection policy are enforced in front of it - so the decision about *who owns each setting* has to be made explicitly rather than inherited from the hosting model. ## The interview-worthy summary The seam keeps application code portable, so answering "nothing much changes in my handlers" is right but incomplete. What changes is who owns the listener, the limits, the shutdown behaviour and the error format for requests your code never sees - and every production incident that hinges on this hinges on that ownership, not on the handlers.