nextjs-coolify-image

The image contains the standalone server and nothing else: the build runs natively in CI, the Dockerfile only copies output, and the container proves its own readiness and leaves within a second when asked. Those three properties make rolling updates safe and images small; everything below enforces them.

Hard rules: never break these

• Build on the runner, never in Docker and never on the server. Registry installs inside container builds hang; the server has no spare CPU. The Dockerfile copies .next/standalone, .next/static and public only.
• output: "standalone" with no NEXT_DIST_DIR override at build time, so the output lands in .next.
• Public env is baked at build time. Every NEXT_PUBLIC_* value and the /api rewrite destination are inlined; set them in the workflow before next build and verify them in .next/routes-manifest.json. Only server-only runtime secrets go to Coolify.
• The health route lives outside anything proxied or localised. /healthz sits beside app/api, not under it, and the proxy matcher excludes it.
• Exit within a second on SIGTERM. Next waits for in-flight requests; a long-lived stream (SSE, a WebSocket) keeps the old container alive for the whole grace period while the proxy still routes to it.
• No latest tags, no root user, no host ports.

Step 1: Audit the app

grep -n "output\|distDir\|rewrites\|headers" next.config.*
grep -rn "process.env" app components lib proxy.ts middleware.ts 2>/dev/null | grep -v NEXT_PUBLIC_ | grep -v node_modules
grep -rln "next/image" app components | head

Classify every env read as build-time (NEXT_PUBLIC_*, anything in next.config) or runtime (read on the server at request time). Note whether next/image optimises local images: sharp is traced into the standalone output automatically when installed, so the runtime image needs no extra packages, but the smoke test must prove it.

Step 2: Add the runtime files

Copy and adapt, from templates/: