Deploying Next.js: Vercel, Self-Hosted or Containers?

Next.js runs anywhere Node runs, but the deployment story is not uniform: some framework features light up automatically on Vercel and require deliberate engineering elsewhere. We deploy client projects on all three main targets, and the right choice depends on traffic patterns, budget, compliance and how much operational work your team wants to own.

Vercel: the default for a reason

Vercel is built by the company behind Next.js, and it shows. Push to a branch and you get a preview deployment; merge and you are live. ISR, image optimisation, middleware at the edge and cron jobs all work with zero configuration.

• Preview deployments per pull request change how teams review work
• ISR and the data cache are distributed and shared automatically
• Costs are usage-based — predictable for steady traffic, worth modelling for spiky or high-bandwidth sites

The trade-offs are cost at scale and platform coupling. For most agencies and product teams, the engineering time saved comfortably outweighs the invoice — until a specific number says otherwise. Preview environments alone routinely justify it during heavy development phases.

Self-hosting on a Node server

Next.js on your own VPS or PaaS is entirely viable: build, then run the production server behind a reverse proxy. The standalone output mode is the key detail most guides skip — it traces the files actually needed and produces a minimal server folder, cutting deployment size dramatically.

// next.config.ts
const nextConfig = {
  output: 'standalone',
};

// after next build, run:
// node .next/standalone/server.js

Containers

Docker builds on the standalone output and adds reproducibility: the same image runs in CI, staging and production, on any orchestrator or container platform your organisation already trusts. A multi-stage Dockerfile keeps the final image lean.

FROM node:20-alpine AS builder
WORKDIR /app
COPY . .
RUN npm ci && npm run build

FROM node:20-alpine AS runner
WORKDIR /app
ENV NODE_ENV=production
COPY --from=builder /app/.next/standalone ./
COPY --from=builder /app/.next/static ./.next/static
COPY --from=builder /app/public ./public
EXPOSE 3000
CMD ["node", "server.js"]

Two operational details deserve attention before the first deploy. Give the container a health check endpoint and wire it into your orchestrator. And keep the environment variable model straight: NEXT_PUBLIC values are inlined into the client bundle at build time, while server-only secrets are injected at run time and must never be baked into the image.

What breaks when you leave Vercel

The features that need deliberate replacement, not the framework itself:

• ISR cache: multiple instances each keep their own filesystem cache — configure a shared cache handler (Redis is common) or pages regenerate inconsistently
• Image optimisation: sharp runs on your CPU; put a CDN in front or offload to an image service
• Middleware runs in the Node server rather than at a global edge — fine functionally, different latency profile
• Cron, analytics and preview URLs: bring your own equivalents

None of this is an argument against leaving — plenty of teams run Next.js on their own infrastructure happily. It is an argument for leaving deliberately, with each item on that list given an owner and an answer before launch day rather than after.

How we choose

Our default advice: start on Vercel unless something concrete rules it out — data residency requirements, an existing Kubernetes estate, or bandwidth economics at serious scale. Teams with strong DevOps capability lose little by containerising; teams without it underestimate the ongoing cost of owning cache invalidation, scaling and monitoring. When we model this for clients, we compare the platform invoice against the engineering hours the alternative consumes — infrastructure that looks free rarely is. Deployment is a product decision wearing an infrastructure costume.

Weighing up hosting options for a Next.js build? STRCLI has run all three in production and can help you pick with numbers rather than vibes.