Production Operations & DevOps
Deploying enterprise Next.js applications requires deep understanding of runtime targets, containerization, and observability.Learn how output: "standalone" leverages file tracing to produce minimal Docker containers (<120MB) ready for Kubernetes and Cloud Run.Evaluate architectural tradeoffs between Node.js and Edge runtimes, instrument distributed OpenTelemetry spans via instrumentation.ts, and debug production memory leaks.
Docker Containerization with output: "standalone"
Next.js provides the output: "standalone" configuration option, which automatically traces and packages only the production dependencies needed by your application. This shrinks Docker container image sizes from over 1.5GB down to ~120MB, eliminating node_modules bloat and enabling secure, multi-stage, rootless Docker deployments on AWS ECS, Kubernetes, or GCP Cloud Run.
Node.js Runtime vs Edge Runtime Tradeoffs
Next.js supports two server runtimes: the full Node.js Runtime and the lightweight Edge Runtime (V8 isolates). The Node.js runtime supports the full Node API ecosystem, heavy npm libraries, and native database drivers, but has higher cold starts (~200ms). The Edge runtime boots instantly (<10ms) across global edge locations, but restricts API access (no fs, no eval, limited crypto) and has strict bundle size limits (1-4MB).
Distributed Tracing & OpenTelemetry Integration
Next.js supports standard OpenTelemetry (OTel) instrumentation out of the box. By implementing instrumentation.ts and the register() hook, developers can trace distributed HTTP requests across microservices, measure database query spans, track Server Component rendering bottlenecks, and export traces to observability platforms like Datadog, New Relic, or Honeycomb.
Managing Environment Variables & Build-Time Inlining
Next.js differentiates between private server-side environment variables and public client-side variables prefixed with NEXT_PUBLIC_. Private variables are evaluated at runtime on the server, while NEXT_PUBLIC_ variables are statically inlined (hardcoded) into client JavaScript bundles during next build. Modifying NEXT_PUBLIC_ variables requires a complete rebuild.
Diagnosing Production Memory Leaks & Cold Starts
Production memory leaks in Next.js typically stem from unbounded global caches, event listener retention, circular React Flight payload references, or module-scoped closures in Server Components. Cold starts in serverless functions are mitigated through bundle reduction, lazy loading heavy libraries, connection pooling, and Partial Prerendering (PPR).