Next.js on a $6.50 VPS: What a Show HN Dokploy Guide Proves About the Vercel Exit

A Next.js SaaS-template author documented the full Vercel exit — VPS purchase to production deploys — posted it to Show HN, and runs several production sites on the result. The scoreboard, up front: git-push deploys, automatic TLS, and custom domains all survive the move; build-vs-runtime env separation, build offloading, ISR cache locality, image-optimization CPU, per-PR previews, and cron all become your job. The headline cost pair is $20 per seat per month plus metered usage on Vercel Pro versus a flat ~$6.50 per month VPS on the Dokploy path. One scoping note before the ledger: this post proves the mechanics end to end from the guide's own steps, but its production-stability evidence is author-attested — no traffic or uptime metrics were disclosed — so read "proves" as "demonstrates working," not "benchmarks at scale."

That honesty matters because the Show HN thread itself is thin: the post earned 1 point and a single comment, the author's own walkthrough summary. There is no community cross-examination to lean on. What carries the weight instead is the guide's unusual completeness — it starts at "buy a VPS" and ends at automated production updates — plus Dokploy's independent traction as the documented landing spot for teams leaving metered hosting.

What the guide actually builds​

The guide is a docs chapter from NEXTY.DEV, a Next.js full-stack SaaS template by developer weijunext (Jude Wei), whose docs notably sit Dokploy alongside parallel chapters for Vercel, Coolify, and Cloudflare Workers — the author is not a single-platform partisan. The Dokploy chapter assumes you start from nothing and walks through server purchase, Dokploy installation, and two deployment paths all the way to automated production updates.

The prerequisite is one line in next.config.mjs: output: "standalone". Since Dokploy deploys via Docker, standalone output — Next.js's dependency-traced minimal server bundle — is what keeps the production image small instead of shipping all of node_modules.

From there the guide builds the stack in layers. First the floor: a 2-core, 8 GB VPS ($6.49 per month at the guide's Hostinger referral pricing), firewall rules allowing only ports 22, 80, and 443, and Dokploy itself installed with the standard one-liner (curl -sSL https://dokploy.com/install.sh | sh). Then the control plane: a custom domain for the Dokploy dashboard with DNS in Cloudflare and a connected Git account. Then the app, via one of two paths.

Option 1, direct deployment, is the one the guide tells you not to use. It is the Vercel-like flow — point Dokploy at a GitHub repo and branch, click Deploy, watch the build logs — and the guide is blunt about why it is only suitable for small projects: on a resource-constrained server, a large Next.js build can exhaust memory and crash or restart the server itself. That warning is the most valuable sentence in the chapter, because it names the failure mode every self-hosted PaaS newcomer discovers the hard way: on Vercel the build farm is someone else's problem, while on your VPS the build competes with your running apps for the same RAM.

Option 2, the recommended path, moves the build off the box entirely. GitHub Actions builds a multi-stage Docker image on every push to main, pushes it to GitHub Container Registry, and a repo webhook (scoped to Registry packages events only) tells Dokploy to pull the new image and redeploy. The guide supplies the full workflow file, the multi-stage Dockerfile (standalone output, static assets copied alongside, non-root nextjs user), and a .dockerignore. GitHub's free Actions minutes absorb the build cost, and the VPS only ever runs the finished image.

The remaining wiring is Cloudflare: proxied A records for the apex and www, SSL/TLS mode, and a www-to-apex redirect configured in Dokploy. Every subsequent code push redeploys automatically. That is the whole machine: $6.50 VPS, free Cloudflare tier, free CI minutes, and a dashboard that behaves like a small Vercel.

What survives the move: the Vercel-shaped checklist​

Measured against the expectations a Vercel user brings, the guide demonstrates four clean survivals and one qualified one.

The environment-variable story deserves a callout because it is genuinely well done: the guide separates build-time from runtime explicitly, puts public NEXT_PUBLIC_* values in GitHub Actions variables and everything else in secrets, warns open-source authors that baked-in build args leak through public images, and even ships scripts to sync .env files to Actions automatically. That is production-grade hygiene, not a toy setup.

The stability row is where the scoping note from the top bites. The author's disclosed fleet is concrete — a self-hosted Plausible analytics instance, the NEXTY.DEV documentation site, the Firstlook.Tools directory site, plus lightweight products and scheduled crawlers — and the Show HN comment states plainly that several production sites run on this setup. But there are no visitor counts, no uptime percentages, no "we survived a traffic spike" anecdotes. Treat it as a credible existence proof from a working developer, corroborated by Dokploy's adoption curve rather than by metrics.

What becomes DIY: the Next.js sharp edges​

Each of these is something Vercel does invisibly that the guide — or you, after the guide ends — must handle deliberately.

Build resource isolation. The guide's Option 1 warning is the edge: Next.js builds are memory-hungry, and a 2-core VPS running your database, your apps, and Dokploy itself has no spare gigabytes. The hand-rolled fix is Option 2's architecture — build in ephemeral CI, ship immutable images — which is also just good practice. But notice the trade: Vercel's "push and forget" becomes a workflow file, a registry credential, a webhook, and a Dockerfile you now own.

Build-vs-runtime env separation. On Vercel, environment variables are a dashboard concern with per-environment scoping built in. Here the same variable lives in up to three places (Actions variables/secrets for build args, Dokploy environment for runtime), and forgetting one produces the classic failure: an image built fine but a container that crashes on boot. The guide documents the split carefully, which is exactly why it belongs in this section — it works, but only because someone wrote it down.

ISR cache locality. A self-hosted standalone server keeps its Incremental Static Regeneration cache in memory or on local disk, sized by settings like isrMemoryCacheSize. On a single VPS that is fine. The moment you scale past one replica, each instance holds its own cache and revalidations stop being globally coherent — the problem Vercel's durable distributed cache solves for you. The guide never hits this because its architecture is one box, one container; file it under "works until you outgrow a single server."

Image-optimization CPU. next/image with the default loader shells out to sharp at request time. On Vercel that compute is metered and cached at the edge; on your VPS it is your CPU spiking on first request for every new image size. For content sites with modest image counts this is a non-issue, which is presumably why the guide never mentions it — but it is the kind of line item that should be in your capacity plan, not discovered in htop.

Per-PR previews and cron. The walkthrough wires production and only production. Vercel users get a URL per pull request and scheduled functions as platform primitives; on this stack, preview environments are a second pipeline you design, and scheduled work is infrastructure you own (the author's own fleet includes crawlers, so the need is real — the guide just scopes it out).

None of these is a veto. Every one of them is a small, concrete piece of engineering with a known answer. That is precisely the point: the Vercel exit trades one bill for a checklist, and this guide is valuable because it writes the checklist down instead of gesturing at it.

The money: a before/after cost comparison​

Take a typical small site in the guide's own mold — a content or directory site, one developer, traffic comfortably inside 1 TB of monthly bandwidth — and line up the two bills.

Third-party 2026 audits put shape around the top end: one pricing teardown lands a five-person team at $355–683 per month once seats, usage, and add-ons (analytics, error tracking, session replay) stack up, and another estimates roughly $1,180 per month at 50,000 monthly active users on the Pro shape. Against that, the VPS path stays flat while you can fit more tenants on the box — practitioners routinely report ten-plus apps plus Postgres and Redis sharing one 4-vCPU VPS.

Now the sensitivity pass, because a single flattering data point would be dishonest. The math flips back toward Vercel in three directions:

• Bandwidth spikes. Past 1 TB, Vercel's overage meter runs hard — but a VPS transfer allowance is also finite, and single-box throughput caps out. A viral week tests both sides.
• Team size. Vercel multiplies $20 per seat while the VPS stays flat, which favors self-hosting until headcount buys the managed convenience back in saved ops hours.
• Ops burden. The guide's own "when to choose Dokploy" section warns that without DevOps experience, a 2 a.m. failure on your own server is a very different incident than a Vercel status page. That risk has a price, and for revenue-critical products it can exceed the hosting delta.

The author's criteria (non-critical products, low or no revenue, page-heavy sites like directories and docs) are the honest boundary of where the flat $6.50 wins outright.

Where Next.js teams actually land​

Dokploy is not a lone script; it is the documented endpoint of a visible migration flow. The project, first released in 2024, sits at roughly 34,000–36,000 GitHub stars as of mid-2026 — about 35,000 stars gained in two years — with releases tracking into v0.29.x by May 2026 and a 2026 feature arc (SSO, SCIM, custom roles, audit logs) aimed squarely at teams, not hobbyists. For scale, Coolify leads the self-hosted PaaS pack at roughly 55,000–60,000 stars, with Dokku and CapRover trailing — Dokploy is firmly the second horse in the race teams evaluate, and the TypeScript codebase plus Docker Compose/Swarm + Traefik architecture make it the natural pick for JavaScript shops.

The guide itself corroborates the "documented exit" reading: NEXTY.DEV ships parallel deploy chapters for Vercel, Dokploy, Coolify, and Cloudflare Workers, and the Dokploy chapter's "when to choose" section is explicit that Dokploy earns its place when Vercel stops being cost-effective. The author's own fleet allocation is the revealed preference — metered hosting where the margin justifies it, the $6.50 box for everything page-heavy or pre-revenue. That matches the broader pattern in 2026's self-hosting literature: the dominant move is hybrid, keeping some things managed while the VPS absorbs the long tail of content sites, internal tools, and experiments.

There is a business reason the exit guides keep coming. Vercel's open-source-playbook economics — free Next.js framework, metered hosting platform — reportedly reached a $340M annualized run rate by February 2026 at a $9.3B valuation. Usage pricing is not a bug in that model; it is the engine. Every guide like this one is a rational response from the cohort the engine prices out: teams whose traffic is real but whose margins cannot carry a per-gigabyte meter.

The decision rule​

This guide proves the Vercel exit is mechanically complete for production Next.js: push-to-deploy, TLS, domains, env hygiene, and a live multi-site fleet, all reproducible from one chapter. It does not prove it is operationally free — the sharp edges above are the actual price, payable in engineering hours instead of overages. So the decision rule the evidence supports is conditional, and it rhymes with the author's own: if the site is content-shaped, pre-revenue, or margin-thin, the Dokploy path is proven and the savings are immediate; if the site is revenue-critical, spiky, or team-scaled, price the 2 a.m. incident before you price the VPS.

Either way, the burden of proof has shifted. A year ago "self-host production Next.js" needed defending; after this guide, it is metered hosting that has to justify its meter — per workload, per team, with numbers. Run yours.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.