Your team is deciding whether to run a Next.js App Router app on a managed Next.js platform or self-host it as a container on your own infrastructure. What responsibilities move to you when you self-host, and how would you make the call?

## Start from what is actually the same The application code, the build, and the framework semantics are identical. Server Components, Server Actions, route handlers and caching behave the same way in both places. Anyone framing this as "which one supports more features" has the wrong model. The question is which team operates the layer around the build. ## What a managed platform is doing for you Worth naming explicitly, because these are the exact gaps you inherit: - **A shared regeneration cache.** Every machine serving the app reads one cache, and an invalidation triggered anywhere is visible everywhere. - **Static asset delivery.** Hashed, immutable assets served from a distributed network, so the origin only does rendering. - **Image optimization as a service.** Transformation and its result cache run outside your app's process budget. - **Middleware close to users** rather than as a hop through your single origin region. - **Deploy mechanics.** Atomic cutover, previous-version assets still resolvable during rollover, per-branch preview environments, instant rollback. - **Baseline observability** — request logs, error surfaces, function-level timing — without you assembling it. ## The self-host checklist Self-hosting is entirely viable; it is a checklist, not a compromise. Build a standalone image so the runtime layer is small and starts fast. Put a CDN in front of the hashed asset paths and make sure both the outgoing and incoming build's assets are resolvable during a rollout. Configure a shared cache handler backed by a store all replicas reach, and disable the per-instance in-memory cache so invalidation is not shadowed locally. Decide where image optimization runs — in-process, accepting the CPU and memory, or delegated to an external image service through a custom loader. Wire logs and metrics into whatever your organisation already runs. Set up a rollout strategy that does not leave two builds serving mismatched assets. Then keep all of it working as the app and the framework evolve. ## How to actually decide **Constraints first.** If data must stay inside a private network, if a regulator dictates where compute runs, or if your organisation has a mandated platform, the decision is already made and the rest is implementation. Say this first in an interview; candidates who lead with a features comparison miss that most real decisions are settled here. **Then the cost curve.** Managed platforms are excellent value at low and medium traffic and can become expensive at high, steady, predictable volume — particularly for image transformation and bandwidth. But compare honestly: the alternative cost includes engineer time to build and maintain the checklist above, and that is the line teams systematically under-count. **Then capacity.** A five-person product team with no platform group self-hosting a Next app will spend real weeks on cache handlers, CDN behaviour and deploy atomicity — weeks not spent on the product. An organisation that already runs dozens of containerised services has most of that solved and self-hosting is nearly free. **Then geography and latency.** If your users are global and your infrastructure is one region, you are trading away distribution that the managed option had by default. Sometimes that is fine; it should be a decision rather than a discovery. ## Keep the door open Whichever way you go, keep the escape cheap. Build the standalone output in CI from day one even while deploying managed, so "can we run this ourselves" is a verified fact rather than a hope. Avoid platform-specific APIs in application code, or isolate them behind a thin module. Keep environment configuration portable. The cost of migrating is dominated by how much platform-shaped assumption leaked into the codebase, and that is controllable from the start. ## The anti-patterns to name Two failure modes are worth calling out. The first is self-hosting for ideology and then rebuilding a poor imitation of the platform — a half-working shared cache, no CDN, image optimization eating the app's CPU — for an app whose traffic never justified it. The second is treating the managed platform as a reason not to understand the mechanics: teams that cannot say where their cache lives are equally unable to debug it when something does go wrong, in either environment.