A team self-hosts a meta-framework app that a managed platform used to run — which responsibilities now sit with them?

Moving from a managed host to your own infrastructure does not change the application; it changes **who does the work the application never asked about**. The renderer is the same code, running in a much less helpful environment. ## The four jobs a managed platform was absorbing 1. **Serving static output.** Hashed assets and prerendered documents are the overwhelming majority of requests a typical app receives. Managed hosts answer them from their own edge, so the render process only ever saw the requests that actually needed rendering. 2. **Request-time asset transforms.** Resizing an image per device, subsetting a font, recompressing a payload — on a managed platform these ran on someone else's capacity. 3. **Transport concerns.** TLS termination, compression, caching headers, HTTP version negotiation. 4. **Traffic gating.** Deciding when a new instance is fit to receive requests, and when an old one should stop receiving them. Self-hosted, each of these lands on your cluster, and three of them land on the same CPU as rendering unless you deliberately move them. ## Put something in front The single highest-value change is a **reverse proxy or CDN in front of the render process**, configured so that: - hashed asset paths and the prerendered document tree are served directly from disk or an object store, never proxied through to the renderer; - long-lived cache headers are set on hashed paths, and short or revalidating ones on documents; - compression happens there, not in the render path; - only the paths that genuinely need rendering reach the application at all. Skipping this is the classic self-hosting mistake. The app "works", latency is mediocre, CPU is high, and nobody connects the two — because from the renderer's point of view it is simply receiving a lot of requests. ## The CPU contention nobody budgets for Request-time asset work is the second trap. Encoding one image is far more expensive than rendering one page, and the two now share cores. The symptom is characteristic: **latency spikes right after a deploy and then settles**, because a cold instance has no transformed assets cached and is generating them all at once while also serving first traffic. | Symptom | Likely cause | Practical lever | |---|---|---| | High CPU, most requests are files | The renderer is serving static output | Terminate those paths at the proxy or CDN | | Latency spikes after each deploy, then settles | Asset transforms regenerating on a cold instance | Persist transformed assets outside the instance, or precompute at build time | | Responses correct but slow under moderate load | Compression and TLS in the render path | Move both in front of the renderer | | Memory climbs for days, then the instance dies | Unbounded in-process caches in a long-lived renderer | Bound cache size and entry lifetime; alert on the trend | | Some users see stale or missing data after scale-out | State that lives on one instance | Make instances interchangeable; keep shared state in a store | ## Instances must be interchangeable A long-running renderer makes it easy to keep things in memory that quietly become **sticky state** — a session map, a rate-limit counter, a regenerated document. It works with one instance and breaks the moment there are two, in the least helpful way: most requests behave, a minority do not, depending on which instance answered. The discipline is that any instance can serve any request, and anything that must be shared lives outside the process. ## Memory is now your problem A per-request function is torn down often enough that leaks rarely surface. A process that runs for days surfaces them all: caches with no eviction, per-request objects retained by a module-level structure, growing buffers. Treat steady memory growth across a flat traffic profile as a defect to investigate rather than a reason to schedule restarts — though a bounded restart policy is a reasonable safety net while you look. ## Do not take traffic too early An instance that has bound its port is not necessarily able to render: the route table may still be loading, configuration may be unvalidated, the first render may need to warm caches. Traffic that arrives in that gap produces errors that look like an application bug and appear only around deploys. The rule is simple — **report ready when a real render can succeed, not when the socket is open** — and the detailed sequencing of startup and shutdown is a discipline of its own. ## What you gain This list reads like a cost, and it is, but it buys real things: full control of the runtime and its dependencies, freedom to run alongside other services on your own network, no constraint from a hosting shape you did not choose, and cost behaviour you can model yourself. The decision is worth making with the list in hand, not from a preference for either side.