Table of Contents
- How this page ranks
- What Next.js requires, from its documentation
- Providers ranked by price at 2 GB
- Build where, run where
- A production stack on one VPS
- ISR, the data cache and multiple instances
- Image optimization and sharp
- Vercel, from its own plan pages
- What this page could not verify
- FAQ
- Sources
How this page ranks
Every provider on this site sells a Linux server that meets Next.js's stated requirement (Node.js 20.9 or newer installs on any current distribution), so the ranking is by monthly list price of the smallest plan with at least 2 GB of memory in a US datacenter, with larger plans shown where a provider's smallest plan is larger. Prices are the ones verified on each provider's review in September 2026. Next.js requirements and behaviours are quoted from nextjs.org; Vercel plan terms from vercel.com/docs. An earlier version of this page ranked providers by build times, cache read latencies and a "CPU score in our tests", with a narrative of moving a 200-page site off Vercel; none of it could be sourced and it has been removed.
What Next.js requires, from its documentation
- Runtime. The installation page: "Minimum Node.js version: 20.9" and "Operating systems: macOS, Windows (including WSL), and Linux". Install Node from NodeSource or with a version manager on the VPS; distribution packages are often older than 20.9.
- Deployment targets. The self-hosting guide: you can self-host "on a Node.js server, Docker image, or static HTML files (static exports)". A VPS covers all three; static export needs only a web server.
- Standalone output. With
output: 'standalone'in next.config.js, Next.js "can automatically create a standalone folder that copies only the necessary files for a production deployment including select files in node_modules", producing.next/standalone"which can then be deployed on its own without installing node_modules". The public and .next/static folders are not copied by default and "should ideally be handled by a CDN instead", or copied in by hand. - Image optimization. The self-hosting guide says next/image "works self-hosted with zero configuration when deploying using next start", and that "On glibc-based Linux systems, Image Optimization may require additional configuration to prevent excessive memory usage", linking sharp's documentation. Install sharp in the project on Debian and Ubuntu servers.
- Caching and ISR. Works "automatically for a single self-hosted next start instance with persistent local disk"; multiple instances or ephemeral compute need a configured cache handler (section below).
- Proxy and middleware. The guide states proxy "works self-hosted with zero configuration when deploying using next start".
Providers ranked by price at 2 GB
| Provider | Plan | vCPU / RAM / disk / transfer | Monthly | Notes |
|---|---|---|---|---|
| InterServer | 1 slice | 1 / 2 GB / 40 GB / 2 TB | $3 | Monthly, no contract; NYC, Dallas, LA |
| OVHcloud | VPS-1 | 2 / 4 GB / 40 GB / unmetered | $5.35 | No 2 GB plan; 4 GB helps on-server builds; VA, OR |
| Hostinger | KVM 1 | 1 / 4 GB / 50 GB NVMe / 4 TB | $6.49 | 24-month term; renews at $11.99; Boston, Phoenix |
| Contabo | Cloud VPS 4 | 4 / 8 GB / 100 GB / unlimited | $6.60 | Introductory for 24 months; Carlstadt NJ, St. Louis, Seattle |
| BuyVM | Slice 2048 | 1 / 2 GB / 40 GB / unmetered | $7 | Stock-dependent; Las Vegas, NY |
| Hostwinds | Unmanaged Linux 2 GB | 1 / 2 GB / 50 GB / 2 TB | $9.99 | Monthly; Dallas, Seattle |
| Vultr | vc2-1c-2gb | 1 / 2 GB / 55 GB / 2 TB | $10 | Hourly; API; nine US regions |
| Linode | Linode 2GB | 1 / 2 GB / 50 GB / 2 TB | $12 | Hourly; API; ten US regions |
| DigitalOcean | Basic 2 GiB | 1 / 2 GiB / 50 GB / 2 TB | $12 | Hourly; managed Postgres and Redis in region |
| Hetzner | CPX11 (US) | 2 / 2 GB / 40 GB NVMe / 1 TB | $20.49 | US price since June 15, 2026; Ashburn, Hillsboro |
Kamatera ($4 for 1 GB; a $25 sample at 2 vCPU and 2 GB; other sizes in its configurator) and RackNerd (list $20.59 at 2 GB, lower on promotions) also run Next.js and are outside the ranking for the reasons on their reviews. The hyperscalers (Lightsail $12 at 2 GB, Google Cloud, Azure) work too and cost more or bill by the item.
Build where, run where
The one sizing fact the docs give is structural: next build compiles, bundles and statically generates, and next start serves; the first needs more memory than the second, and Next.js publishes no number for either. That gives two workflows. Build on the server: simplest, one machine, but the server must carry the build's peak memory, so buy headroom (OVHcloud 4 GB, Contabo 8 GB, or two InterServer slices at $6) and add swap so a tight build slows rather than dies. Build elsewhere, ship standalone: run next build in CI (GitHub Actions and the like) or on a laptop, rsync .next/standalone, .next/static and public to the server, restart the process. The server then only serves, a 2 GB plan is comfortable for a typical site, and deploys are a file copy. The second workflow is the one this page recommends on a 2 GB server, and it is the same shape on every provider in the table.
A production stack on one VPS
After the first-hour hardening, the stack is Node, a process manager, and a reverse proxy.
# Node.js 22 LTS from NodeSource (Debian/Ubuntu); Next.js needs 20.9 or newer
curl -fsSL https://deb.nodesource.com/setup_22.x | bash - && apt install -y nodejs
node -v
# on your machine or CI: build standalone output, then copy it up
# next.config.js: module.exports = { output: 'standalone' }
npm ci && npm run build
rsync -a .next/standalone/ deploy@SERVER:/srv/app/
rsync -a .next/static/ deploy@SERVER:/srv/app/.next/static/
rsync -a public/ deploy@SERVER:/srv/app/public/
# on the server: run it under systemd
cat > /etc/systemd/system/nextapp.service <<'EOF'
[Unit]
Description=Next.js app
After=network.target
[Service]
User=deploy
WorkingDirectory=/srv/app
Environment=NODE_ENV=production PORT=3000 HOSTNAME=127.0.0.1
ExecStart=/usr/bin/node server.js
Restart=always
[Install]
WantedBy=multi-user.target
EOF
systemctl enable --now nextapp
# nginx in front: TLS, static files, proxy to :3000
# location /_next/static/ { alias /srv/app/.next/static/; expires 1y; access_log off; }
# location / { proxy_pass http://127.0.0.1:3000; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto https; }
PM2 (pm2 start server.js --name app, pm2 save, pm2 startup) does the same job as the systemd unit with a friendlier CLI and log viewer; pick one. For Docker, the standalone docs describe a "singular Docker image that can be promoted through multiple environments with different values" via environment variables; build the image in CI, pull it on the server, run it behind the same nginx. The Docker guide covers the host side. Certbot for TLS, and the hardening guide's firewall rules (22, 80, 443 only; port 3000 stays closed to the internet).
ISR, the data cache and multiple instances
The self-hosting guide describes the default: ISR and the data cache work "automatically for a single self-hosted next start instance with persistent local disk", stored under .next/cache. On one VPS that is the whole story, with one deploy-time rule: do not delete .next/cache on each deploy if you want revalidated pages to survive, and keep it outside the rsync of a fresh standalone folder or copy it forward. ISR "sets the Cache-Control header of s-maxage: <revalidate in getStaticProps>, stale-while-revalidate", which a CDN or nginx cache in front can honour. If you grow to several instances or containers, the guide says to configure the cache location or a cache handler "if you want to persist cached pages and data to durable storage, or share the cache across multiple containers or instances", and points to a Redis cache handler example; DigitalOcean's managed Redis in the same region is one place to put it, or Redis on the same VPS if the instances are containers on one host.
Image optimization and sharp
next/image optimizes on the server at request time when self-hosted. The self-hosting guide: it "works self-hosted with zero configuration when deploying using next start", and "On glibc-based Linux systems, Image Optimization may require additional configuration to prevent excessive memory usage", with a link to sharp's documentation. Debian and Ubuntu are glibc-based, so read that note. Install sharp as a project dependency so the optimizer uses it, and if a site serves many large images on a 2 GB server, either pre-optimize at build time, put a CDN or an image service in front, or set the loader to an external optimizer; the memory note in the docs is the reason.
Vercel, from its own plan pages
Vercel's documentation in September 2026 describes Hobby as "free and aimed at developers with personal projects, and small-scale applications" and says the plan "restricts users to non-commercial, personal use only". Pro is listed as a "Platform fee $20/month" with "1 deploying team seat included" and "$20/month in usage credit", with usage beyond the credit billed at the rates on the pricing page and additional seats priced there too. So a commercial Next.js site on Vercel starts at $20 a month plus usage, and a personal one is free within fair use. A VPS at $3 to $12 replaces the platform fee and the usage lines with one flat number and a transfer allowance, and replaces Vercel's deployment pipeline, preview URLs, CDN and serverless scaling with your own nginx, systemd and CI. Which is cheaper depends on what your time costs; which is better for a commercial site with steady traffic and a team that can run a server is the VPS.
What this page could not verify
- Any memory or CPU figure for
next buildornext start: Next.js publishes none, and this page measured nothing. - Vercel's per-seat and per-unit usage prices: rendered by script on its pricing page; only the documented platform fee, credit and seat inclusion are quoted.
- Whether any provider's default images ship Node.js 20.9 or newer: install Node yourself.
- Contabo's US location fee and Hostinger's renewal after the 24-month term beyond the $11.99 on its page: see their reviews.