Deployment & Hosting

A production build emits content-hashed client assets, prerendered documents for routes resolved at build time, a server bundle for routes that were not, and manifests mapping routes and assets to those files.

A development server compiles a route on demand and renders it again on every request, with prerendering skipped and the cache tiers switched off. The built output compiles once ahead of time and reuses whatever it is allowed to reuse.

A shared store keeps one copy of regenerated pages and cached data that every instance reads and writes, so all instances agree. Per-instance memory gives each process its own copy, and those copies drift apart.

A static export runs the build once and emits only files - HTML documents, JavaScript, CSS, media - with no server process behind them. The host's job is to map each URL to a file and return its bytes.

Everything that assumed the process stays alive between requests: in-memory caches and regeneration state, work continued after the response, connections held open, and streaming when any layer buffers the whole body before forwarding it.

Because the two sides have different entry points, targets and permitted dependencies. The browser graph must stay small and carry no secrets or server-only code, while the server graph may use anything, so each is traversed from its own roots.

The build executes your code: it compiles every route and renders the prerenderable ones on the build machine, with no browser and no incoming request. Paths a development session never reached fail there for the first time.

Everything that needed code running per request goes: request-time rendering, server-handled writes, regeneration, interception before a route resolves, request-time media work. Each is replaced by a browser fetch, a separate service, host rules, or another build.

Version skew is a browser running one release's client code while the server serves the next: a missing chunk, a moved write identifier, a changed payload shape. Atomic deploys swap only the server; loaded tabs keep the old client.

Serving static output in front of the render process, absorbing request-time asset work that now competes for the same CPU, keeping instances free of sticky state, bounding memory in a long-lived renderer, and withholding traffic until a render succeeds.

The purge ran in one process and cleared only what that process holds. Locate each stale copy by comparing instances against the public URL, then share the cache store and purge the cache in front as a second explicit step.

It must use only the restricted API surface that runtime offers — web-standard request, response, streams and fetch — with no local filesystem or native dependencies, and stay inside tight bundle-size and per-request CPU budgets.

A route manifest maps each URL pattern to how that URL is answered - a prerendered document or a server handler - and to the assets that route needs. Server dispatch and client-side prefetching both read it.

Module-scope state is re-created: the fresh copy of the module runs its initialisation again, so any pool, cache or registry it built is new and empty, while the previous instance can survive unreferenced and still holding its resources.

A small storage contract: get an entry by key, set a whole entry with its metadata, remove entries. Bytes must be opaque and serialisable, keys come from the framework, and a failed read must degrade to a miss.

The host maps the path onto stored bytes. An extensionless path resolves either to a file with an added extension or to a directory's index document, and hosts differ - so one form can work where the other misses.

A navigation fetches the route's data but renders it with code from the release that tab loaded. If the new release renamed, removed or re-nested fields, the old renderer reads what is no longer there and blanks or throws.

Both are baked in at build time, prefixing asset URLs in generated HTML, in manifests, in emitted CSS and in the client runtime that composes chunk URLs later. Get either wrong and documents render while their assets fail to load.

Look for entry points, not file types. Finished documents and hashed assets are results, while a request-handling entry, an on-demand asset transformer or a writable runtime cache directory all mean code still has to execute per request.

Verify against the built output: build on every change in the pipeline so every route is compiled and prerendered, and run the build locally before anything risky ships. Keep the development server for the edit loop.

Anything inside a replaced process dies with it; anything outside survives, so a shared store and the cache in front keep serving copies built by the previous release. Reuse is safe only for entries that cannot differ between builds.

That is a soft 404: the page says missing while the status says fine. Crawlers, link checkers, monitors and caches all read it as healthy, and a missing asset returns HTML. Serve the not-found document with a real 404.

The client posts a write to a handler address the build minted. The new release recomputed that address and no longer answers the old one, so a stale tab posts where nothing is mapped. Reloading downloads current addresses.

Start from a capability matrix of what each target shape can do, name one default target, require a written exception to leave it, and gate every target with a conformance test, because mismatches degrade silently.

Treat the divergence as bought, not accidental: it pays for the edit loop. Buy parity as automated gates and a separate mode, keep the fast loop as the default, and refuse half-measures that lie in a new way.

Put cache authority where a correction must be observable and a miss is expensive. Anonymous URL-addressable documents belong in front of the app, fleet-consistent expensive results in a shared store, and per-instance memory is a latency layer, never the authority.

Decide on the roadmap, not today's feature list. Files-only fits when no delivered HTML has to depend on the requester and publishing can be a build. It becomes a trap when per-request behaviour is inevitable and the exit was never priced.

Measure how long sessions really live and make that the compatibility window: inside it, changes to what a loaded client touches must be additive or retained. Add a cheap escape hatch so an out-of-date client reloads without losing input.

How a response was produced decides who may keep it. A document identical for everyone may be stored by a shared cache in front of the app; one assembled from a session must be marked unstorable there.