In a meta-framework, what is a deployment adapter and what does it change about the build output?

A **deployment adapter** is the step between "the build finished" and "the host can run it". Application code is written once against the framework; the adapter decides what that build turns into for one specific hosting shape. ## What the build hands the adapter Before any target is involved, a typical meta-framework build has produced: - **Hashed client assets** — JavaScript chunks, CSS and static files whose names carry a content hash so they can be cached forever. - **Prerendered documents** — HTML produced at build time for routes that did not need a request. - **A server bundle** — the code that can turn a request for a not-prerendered route into a response, conceptually `render(request) -> response`. - **Manifests** — a route table saying which handler serves which path pattern, and an asset graph saying which chunks a route needs. That set is a description of an application, not a deployable unit. Every host has its own contract, and the contract is what the adapter writes. ## What the adapter emits per target | Target shape | What it runs | What the adapter must emit | What it cannot offer | |---|---|---|---| | Long-running process | one process, started once, serving many requests | a start entry that binds a port and mounts the route table | nothing inherent — but you operate it yourself | | Per-request functions | a handler invoked per request, possibly on a fresh instance | one or more handler bundles in the platform's signature, plus a path-to-handler routing config | state kept in memory between requests; responses held open indefinitely | | Edge runtime | a restricted runtime close to the user | a small bundle using only the APIs that runtime provides | local filesystem, native dependencies, heavy request-time CPU | | Plain file host | static files, plus redirect and rewrite rules | prerendered documents and assets, plus rules for deep links and the not-found path | anything that has to happen at request time | ## Why it is a translation, not a copy Four things genuinely differ between targets, which is why a copy of the output folder is not enough: 1. **The entry signature.** A process target needs something startable; a function target needs an exported handler shaped the way that platform calls it. 2. **Who owns routing.** On a process, the framework's own route table matches the path. On a function or file host, the platform matches first, from a config file the adapter generates, and only then calls in. 3. **Who serves static files.** A process target can serve them itself; on the other shapes the host serves them and the render code never sees those requests. 4. **How configuration arrives.** Values read from the environment, and the base path assets are requested from, are wired differently per host. ## What the adapter cannot invent An adapter packages for a target; it does not add capabilities the target lacks. If the chosen shape has no place to keep state that every instance can read, a server-side data cache or on-demand regeneration cannot work there just because the adapter succeeded. If the shape cannot hold a response open, a held-open connection will end early. Most of these fail *quietly*: the build is green, the page renders, and the behaviour is simply different — a cache that never hits, a stream that arrives in one chunk, a regenerated page that reverts on the next request. That silence is why "which adapter" is a design decision and not a deployment detail. ## Switching targets Because the adapter is chosen at build time, moving hosts is mostly mechanical: pick a different adapter, rebuild, deploy. The real work is the audit that goes with it — list the features the app relies on (request-time rendering, streaming, regeneration, request-time asset work, long-held connections) and check each against what the new shape can actually provide. Meta-frameworks differ in how much of this they tell you: some fail the build when a route uses something the target cannot support, others build happily and let the difference show up in production. A last practical note: some hosts offer **more than one runtime** for the same application, so a single build can be split across shapes. That flexibility is a property of the target, not of the adapter, and it is worth knowing which of your candidate hosts have it before the choice is made.