How We Run Next.js in Production on a VPS
The exact setup we use to host our own Next.js products — process managers, reverse proxies, zero-downtime deploys, and the mistakes we made getting here.
By Anested Engineering
Every Anested product — this website included — runs on the same Anested Clouds infrastructure we sell to customers. That constraint keeps us honest. If a deployment pattern is too fragile for our own products, it has no business being a default on anyone else's VPS.
Our production Next.js stack is deliberately boring, and we mean that as a compliment. A VPS with a pinned Node.js LTS version, a process manager that restarts the app on failure, and a reverse proxy terminating TLS in front. No orchestration cluster, no service mesh, no sidecar containers. None of our workloads have earned that complexity yet, and pretending otherwise would just mean more things breaking at two in the morning.
Zero-downtime deployment is the one place we spend real engineering effort. Each release builds in a separate directory while the old version keeps serving traffic. We run health checks against the new build on an internal port, and only when it answers correctly do we swap the reverse proxy upstream. If anything looks wrong ten minutes later, rollback is a symlink change and a reload — not a frantic redeploy.
The biggest mistake we made early on was treating logs as an afterthought. When something broke, we were SSH-ing into servers and grepping through scattered files. Today every application ships structured logs to a central store from day one, and the on-call engineer can answer the question 'what changed?' in under a minute. That single habit has cut our incident resolution time more than any tooling purchase.
Caching deserves a mention because Next.js gives you so many layers of it — build-time static pages, incremental revalidation, CDN headers. Our rule is to cache aggressively at the edge for anonymous traffic and never for authenticated pages. Boring, explicit rules beat clever ones you cannot explain during an outage.
If you want this same setup without building it yourself, that is literally what Anested Clouds sells. The patterns described in this post are the defaults on every new VPS we provision — because we run our own company on them.
Need help with something we wrote about?
Our engineers answer support queries directly — hosting, databases, code, or anything from this post.