Self-host vs Vercel: standalone anatomy, build-time env baking, and what the platform actually sells

What output standalone actually emits

With output: 'standalone' in next.config.js, next build does more than compile: it runs file tracing over the server build — static analysis of every require/import reachable from your server code — and emits .next/standalone/, containing a minimal server.js (a thin HTTP server wrapping the Next request handler) plus only the subset of node_modules the trace proved necessary. A repo whose node_modules weighs 800 MB typically traces down to 50–150 MB, and a multi-stage node:20-alpine image lands around 150–250 MB instead of a gigabyte-plus.

What the trace deliberately does not include is everything that is not server code. .next/static/ — all client JS, CSS, and build-hashed assets — is emitted by the build but not copied into standalone, because the intended design is that a CDN serves it; server.js will serve those paths only if you copy the folder next to it. Same for public/. And image optimization via next/image needs sharp in the runtime image: modern Next pulls it as an optional dependency, but pruned installs and alpine builds routinely drop it, and without it /_next/image falls back to a slow path or fails outright. The last trap is invisible until the first container deploy: server.js reads PORT and HOSTNAME from the environment, and without HOSTNAME=0.0.0.0 it binds where no load balancer can reach it.

FROM node:20-alpine AS builder
WORKDIR /app
COPY . .
RUN corepack enable && pnpm install --frozen-lockfile && pnpm build
# next.config.js: { output: 'standalone' }

FROM node:20-alpine AS runner
WORKDIR /app
ENV NODE_ENV=production HOSTNAME=0.0.0.0 PORT=3000
COPY --from=builder /app/.next/standalone ./
COPY --from=builder /app/.next/static ./.next/static  # NOT in standalone — copy or 404
COPY --from=builder /app/public ./public              # NOT in standalone — copy or 404
EXPOSE 3000
CMD ["node", "server.js"]

Env vars: baked at build versus read at runtime

NEXT_PUBLIC_* variables do not exist at runtime in the browser — there is no environment there to read. The bundler string-replaces every process.env.NEXT_PUBLIC_X occurrence with the literal value present at next build time, the same way a define-plugin inlines constants. That is the whole mechanism behind the classic incident: ops changes NEXT_PUBLIC_API_URL in the deployment manifest, restarts every pod, and nothing happens — the client bundle still contains the old string, character for character, because no rebuild occurred. Server-side code is the opposite: plain process.env.SECRET in a route handler or server component is read live from the process on each request (with one caveat — values captured while prerendering a static page are frozen at build time too).

This collides head-on with the build-once, promote-everywhere discipline most container shops run. If staging and production share one image, every NEXT_PUBLIC_ value in it belongs to whichever environment built it. Your honest options: rebuild per environment (cheap with build cache, but now images are not identical artifacts); keep environment-varying values out of NEXT_PUBLIC_ entirely and pass them from the server — read process.env in a server component and hand the value down as a prop; or inject a runtime config object into the HTML from a layout. The rule of thumb that survives audits: NEXT_PUBLIC_ is for values that are genuinely constant per build artifact, not per environment.

What Vercel actually sells — and where the cost lines cross

Strip the marketing and the platform sells four hard things. A globally replicated ISR/data cache: revalidation propagates to every region without you running a shared store. An image-optimization fleet: resize-on-demand at the edge, cached, no sharp capacity planning. An anycast edge network in front of everything. And zero-config preview deployments — a full environment per pull request, which is genuinely the hardest item to rebuild yourself. Together, these four items answer the question “what am I actually paying for?” — and without understanding them, you will repay them in engineering hours after switching. A container plus a commodity CDN replicates the rest cheaply: the CDN takes static assets and cached pages, sharp handles images on your CPU, and the load balancer is your edge. One thing does not carry over silently, and it previews the next two lessons: the default ISR cache is per-pod disk, so the moment you run two replicas, the single-truth cache Vercel gave you stops existing.

The cost math has a shape worth memorizing rather than exact prices, because prices drift. Serverless billing is roughly linear in invocations, GB-hours, image transformations, and egress; a VM is a flat constant with a utilization ceiling. Sustained traffic favors flat; spiky traffic favors metered. A steady 50–100 req/s of SSR fits comfortably on two 4-vCPU boxes — order of 50–100 dollars a month plus CDN egress — while the same sustained load on per-request metering lands an order of magnitude higher. Invert the profile and the answer inverts: 0.5 req/s baseline with rare 50× press spikes is exactly what metering absorbs with zero capacity planning, while the VM must be provisioned for the spike and idles the rest of the quarter. The crossover is not subtle in either direction; what is subtle is pricing in the engineering weeks for the shared cache, the image pipeline, and per-PR environments.