Next.js without Vercel.
Full runtime. Your VM.
App Router, RSC, ISR, server actions — all work on a self-hosted Next.js deploy. vxcloud handles the standalone Dockerfile, Traefik routing, and Let's Encrypt SSL. Multi-cloud.
Why self-host Next.js in 2026
Vercel built Next.js and Vercel is excellent at hosting Next.js. The question isn't 'is Vercel good?' — it is 'when does self-hosting win?'
- Bandwidth bills. Vercel's pricing scales with bandwidth; once you cross ~1 TB/mo, overages add up fast. A self-hosted Next.js app on a VM behind Cloudflare runs at flat cost.
- Backend workloads. Next.js app code, the API routes that hit your database, plus long-running background jobs and queue workers can all live on the same VM. With Vercel, the API routes go to Vercel Functions and the workers go to Inngest / Trigger.dev / another vendor.
- Multi-cloud / compliance. Vercel is one provider. vxcloud lets you deploy Next.js to AWS in the US, GCP in the EU, Linode in APAC, Alibaba in China — same deploy command for all four.
- Lock-in mitigation. Self-hosted Next.js means your app runs identically on any Node 18+ host. Leaving the platform is a DNS change away.
One command, full production stack
Standalone Dockerfile
Multi-stage build, Node 20-alpine runtime, automatically injects `output: 'standalone'` if missing, ships only the runtime files (~150 MB).
Free SSL via Traefik
`--enable-ssl --domain X --ssl-email Y`. Traefik handles ACME on :80, routes :443 to your Next sidecar. Auto-renews.
Postgres / Redis in one call
`vxcli cloud create-rds` / `create-redis` provisions managed instances. Connection strings flow into your Next app via env vars.
App Router + RSC + ISR
All modern Next.js features work the same as on Vercel. Server actions, route handlers, middleware (Node runtime), parallel routes — supported.
Per-PR preview deploys
CI script pattern: `vxcli vm create preview-${PR}` + `vxcli deploy nextjs`. Comment the URL on the PR. Tear down on PR close.
Multi-cloud, multi-region
Same command, different `--cloud` / `--region`. Run primary on AWS us-east-1 and edge on Linode Frankfurt + Singapore from one deploy script.
Quickstart — Next.js live with HTTPS in two commands
vxcli vm create \
--name web-vm --cloud aws --region us-east-1 \
--instance-type t3.medium --key-pair-name AWSPRODKEY2
export WEB_IP=<paste-public-ip>vxcli deploy nextjs \
--source-dir ./ \
--app-name marketing-site \
--http-port 80 \
--env DATABASE_URL=postgres://... \
--env NEXT_PUBLIC_API_URL=https://api.example.com \
--enable-ssl \
--domain www.example.com \
--ssl-email [email protected] \
--host $WEB_IP --ssh-user ubuntu --key-pair-name AWSPRODKEY2
# https://www.example.com now serves your Next.js app with a valid cert.Self-hosting Next.js — production checklist
- Add `output: 'standalone'` to your next.config.js explicitly. vxcloud injects it if missing, but the explicit version is clearer for your team.
- Use `next/image` with the sharp loader (default on Node runtime). Put CloudFront / Cloudflare in front for edge caching of optimized images.
- For ISR across multiple VMs, swap the default filesystem cache for a Redis-backed cache handler — Upstash Redis or vxcloud-provisioned ElastiCache.
- Configure `productionBrowserSourceMaps: true` and ship the sourcemaps to Sentry/equivalent — debugging RSC errors without them is brutal.
- Set the `NODE_OPTIONS=--max-old-space-size=4096` env var for the Next process if you see OOM kills on a 4 GB VM. Default is 1.5 GB; bumping prevents server-action OOMs.
- Run a separate `vxcli deploy nodejs` for your background workers (queue consumers, cron jobs) — keep the web tier and worker tier on separate VMs so a runaway worker can't kill the front-end.
- Health-check `/api/health`. Make it a fast 200 with no DB call. Trying to be clever (check DB, check Redis) means a brief DB hiccup restarts your Next process.
Next.js hosting FAQ
Deploy Next.js to a VM you own — without leaving the workflow you like
`vxcli deploy nextjs` feels like `vercel deploy`. The app runs on AWS / GCP / Azure / Alibaba / Linode.