Node.js draaien op een VPS

Heroku schrapte zijn gratis abonnement en verhoogde de minimumprijs. Vercel rekent per gebruiker en breekt langlopende taken af. Bij Render en Railway stijgt de prijs mee met je verkeer.

Open de laatste factuur van je hostingprovider. De Node-app, een Postgres-database en een Redis-cache. Drie factuurregels, drie sets waarschuwingen voor overschrijdingen en één paniekerige Slack-thread op de dag dat marketing eindelijk een campagne lanceert.

Door die factuur kijken veel teams opnieuw naar de VPS. Het maakt Node.js zelf niets uit waar het draait. Het enige waartegen serverless je beschermde, was ontdekken wat er gebeurt na ‘npm start’.

Laten we een productieopstelling voor Node.js bekijken op een Linux-machine die je zelf beheert. Kun je via SSH inloggen op een server en een configuratiebestand lezen? Dan heb je aan het eind een productiestack die je jarenlang kunt draaien met een paar uur onderhoud per maand.

Wanneer is het zinvol om Node.js op een VPS te draaien?

Een VPS is de juiste plek voor Node.js als je een langlopend proces hebt, een stack die je op één factuur wilt samenbrengen, of een rekening voor een beheerde runtime die niet meer opweegt tegen het gemak.

Grofweg zijn er drie situaties waarin het goed past:

• Langlopende processen: WebSocket-servers, wachtrijverwerkers, cron-planners, MCP-servers. Alles wat moet blijven draaien en luisteren. De meeste serverless platforms zijn nog steeds geoptimaliseerd voor kortstondige uitvoering en de levenscyclus van verzoeken. Een Node-proces op een VPS draait gewoon door.
• Kosten bundelen: je Node-app, Postgres, Redis en een kleine build-worker draaien allemaal op dezelfde server van 4 GB. Eén factuurregel in plaats van vier.
• Apps die PaaS ontgroeid zijn: time-outs van functies bij je lange PDF-generatietaak. Prijzen per gebruiker voor een team dat eindelijk een vierde engineer heeft aangenomen. Een Heroku-factuur die boven de $60 per maand uitkomt voor een workload die prima draait op een VPS van $15.

En er zijn drie situaties waarin het niet past:

• Statische sites en SSG-content: een Next.js-export, een Astro-build, een Gatsby-blog. Het gratis abonnement van Vercel is daarvoor het juiste gereedschap. Een VPS is dan overdreven.
• Sporadische, gebeurtenisgestuurde workloads: AWS Lambda of Cloudflare Workers kosten een paar cent voor een webhook die tien keer per dag draait. Een VPS kost hetzelfde, of de app nu druk bezig is of slaapt.
• Horizontaal geschaalde realtime-apps: moet je WebSocket-server 100.000 gelijktijdige verbindingen bedienen, dan is één VPS niet het antwoord. Dan heb je een Kubernetes-cluster, een gedistribueerde edge-infrastructuur of een beheerd realtime-platform nodig.

JavaScript is de meest gebruikte taal in de 2025 Stack Overflow Developer Survey, en Node.js is nog altijd een van de standaardmanieren waarop developers JavaScript in de backend draaien. Dat zijn heel wat mensen die ergens Node draaien. Dit artikel is voor het deel van hen dat liever een server gebruikt die ze zelf in de hand hebben.

Ik heb teams vier Node-productieservices van Heroku zien verhuizen naar één VPS van 4 GB, met dezelfde uptime, een derde van de kosten en langdurige WebSockets die eindelijk zonder omweg werkten.

De migratie is grotendeels een middagje ‘apt install’, een ‘pm2 start’ en een DNS-wijziging.

Welke VPS-specificaties heeft Node.js echt nodig?

Node.js zelf is lichtgewicht. Een minimale Express-server blijft in rust ruim onder de 100 MB werkgeheugen. Het advies Node heeft maar 1 GB nodig dat je nog op oudere blogs vindt, klopt technisch gezien, maar in de praktijk heb je er niets aan. Zodra je Postgres, Redis, logs en een deploymentproces hebt toegevoegd dat niet met hoop aan elkaar hangt, ga je daar op een rustige dag al overheen.

Realistische dimensionering voor veelvoorkomende workloads:

Een paar details om vast te leggen voordat je de server inricht:

• NVMe-opslag is belangrijker dan pure schijfgrootte: moderne Node-apps raken duizenden kleine bestanden aan tijdens installaties, builds en het opstarten. Trage schijven maken het installeren van afhankelijkheden, koude starts en SSR-rebuilds merkbaar trager.
• KVM-virtualisatie, geen OpenVZ: oudere abonnementen op basis van OpenVZ delen een kernel met de host. Dat kan verouderde kernelversies betekenen en af en toe compatibiliteitsproblemen met nieuwere runtimes. De meeste betrouwbare VPS-providers werken inmiddels alleen nog met KVM, maar het is de moeite waard om het te controleren.
• Swapruimte: schakel op kleinere servers 1-2 GB swap in. De V8-heap van Node kan tijdens garbage collection flink schommelen. Zonder swap legt een tijdelijke piek het proces plat. Ik heb een server van 4 GB tijdens een routinematige deploy door geheugentekort zien crashen, omdat iemand swap had uitgeschakeld in de veronderstelling dat het een anachronisme uit het Docker-tijdperk was.
• Bandbreedte: de meeste moderne VPS-abonnementen bevatten 1-4 TB bandbreedte per maand, genoeg voor bijna alles behalve videohosting. Zelfbeheerde VPS-abonnementen hebben ongelimiteerde bandbreedte: één regel minder in je spreadsheet voor capaciteitsplanning.

Een VPS van 4 GB kost tegen marktprijs zo'n $15 per maand. Dat is 50 cent per dag, of ongeveer één koffie op het vliegveld per twee weken. Vergeleken met los betalen voor app-runtimes, beheerde Postgres en Redis op een PaaS slaat de rekensom verrassend snel om.

Welke Node.js-versie moet je installeren?

Installeer Node.js 24 (codenaam Krypton). Dat is de huidige Active LTS-release, gepromoveerd in oktober 2025 en ondersteund tot april 2028 volgens het officiële releaseschema van Node.js.

Veel tutorials verwijzen nog naar Node 22. Die handleidingen zijn niet bijgewerkt. Begin je vandaag aan een nieuwe deployment? Zet je CI-image en je VPS dan vast op Node 24.x.

Een paar vuistregels:

• Draai geen Current-releases (niet-LTS) in productie: Node 26 is er om toekomstige compatibiliteit en nieuwe runtimefuncties te testen, niet voor de app waar je omzet van afhangt.
• Node 22 is de uitwijkoptie als een cruciale afhankelijkheid nog steeds niet compatibel is met Node 24: het grootste deel van het ecosysteem was binnen een paar maanden na de LTS-promotie stabiel.
• Zet je Node-versie overal vast: je CI-image, Dockerfile, .nvmrc en productie-VPS moeten allemaal overeenkomen. Werkt op mijn machine wordt snel duur zodra native modules ten tonele verschijnen.

🤔Overweeg je Bun? Het is bij sommige workloads sneller en echt indrukwekkend, maar het ecosysteem is nog kleiner en het trackrecord in productie korter dan dat van Node. Voor de meeste teams wint saai.

NodeSource, dat de apt- en yum-repository's onderhoudt waarmee veel productieteams Node installeren, wijst op verbeteringen in de 24.x-lijn, te beginnen met een nieuwere V8-engine. Node 24 bevat ook inmiddels volwassen tooling, zoals ingebouwde node –watch en een stabiele native testrunner (node: test). Beide werden stabiel in de 20–22-lijnen en lopen hier door. Niets daarvan is spectaculair. Het neemt gewoon elke maand een beetje operationele frictie weg.

Hoe installeer je Node.js op een VPS?

Je hebt twee realistische installatieroutes. Kies op basis van of de server één Node-app draait of meerdere.

NodeSource voor een server met één app

Dit is de eenvoudigste route voor productie. Met één setupscript en één apt install krijg je de huidige Node 24 LTS-lijn als systeempakket, en toekomstige beveiligingsupdates komen binnen via normale pakketupgrades.

Op Ubuntu of Debian:

curl -fsSL https://deb.nodesource.com/setup_24.x | bash -
apt install -y nodejs

Controleer de installatie:

node -v
npm -v

Je zou een Node 24.x-release moeten zien.

Instructies voor distributies uit de RHEL-familie (yum/dnf) vind je in de officiële NodeSource-distributierepository.

nvm om per project van versie te wisselen

nvm (Node Version Manager) installeert Node in je thuismap en laat verschillende projecten verschillende Node-versies gebruiken. Handig als je meerdere apps op dezelfde server host of geen sudo-toegang hebt.

Voer dit uit als je app-gebruiker, niet als root:

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.5/install.sh | bash

Herlaad je shell en installeer daarna Node 24:

nvm install 24
nvm use 24
nvm alias default 24

👉Eén belangrijke regel: gebruik geen sudo ‘npm install -g’ voor de afhankelijkheden van je applicatie.

Globale installaties zijn meestal bedoeld voor CLI-tools op machineniveau, zoals pm2, typescript of nodemon. De afhankelijkheden van je app horen in package.json en installeer je vanuit de projectmap met npm ci.

Twijfel je? Begin dan met NodeSource. De meeste productieservers met één taak hoeven niet per project van Node-versie te wisselen.

👉Gebruikers van een VPS van DreamHost: de Node.js-app die je bij het inrichten kunt kiezen, wordt geleverd met Node.js 24 LTS, plus fnm, PM2, Nginx en Certbot SSL, zodat je de installatiestappen hierboven kunt overslaan.

Gebruik je PM2 of systemd om je app draaiende te houden?

Beide werken. Het eerlijke antwoord: kies waar je team zich prettig bij voelt. PM2 is de ontwikkelaarsvriendelijke route. systemd is de Unix-eigen route. Beide lossen dezelfde drie problemen op: herstarten na een crash, starten bij het opstarten van de server en netjes afsluiten bij ‘SIGTERM’.

Begin je helemaal opnieuw? Zo maak je de keuze:

De snelstart van PM2 doet zijn naam eer aan:

npm install -g pm2
pm2 start app.js --name api
pm2 startup    # prints the systemd startup command to run
pm2 save       # saves the current process list

Daarna praat je alleen nog met PM2: ‘pm2 logs’, ‘pm2 reload api’, ‘pm2 monit’.

👉Ook goed om te weten: ‘pm2 startup’ schrijft een systemd-unit, dus de PM2-opstelling gebruikt onder de motorkap eigenlijk gewoon systemd.

Een minimale systemd-unit om Node direct te beheren, in ‘/etc/systemd/system/api.service’:

[Unit]Description=My Node APIAfter=network.target

[Service]Type=simpleUser=appWorkingDirectory=/var/www/apiExecStart=/usr/bin/node server.jsRestart=on-failureRestartSec=5Environment=NODE_ENV=productionStandardOutput=journalStandardError=journal

[Install]WantedBy=multi-user.target
Daarna ‘systemctl enable --now api’. Logs vind je in ‘journalctl -u api -f’.

Draai je al PM2 en werkt het? Stap dan niet over op systemd alleen omdat iemand op Hacker News dat zegt. Het geheugengebruik van de PM2-daemon is geen reden om ermee te stoppen.

Stap over als je een echte reden hebt. Bijvoorbeeld als je een stuk of zes Node-processen draait waarbij elke megabyte telt, of als je uitrolt in een ops-omgeving waar elke andere service een systemd-unit is en PM2 de vreemde eend in de bijt is.

Hoe zet je NGINX (of Caddy) voor je Node-app?

Je wilt om vijf redenen een reverse proxy vóór Node: HTTPS-terminatie, gzip/brotli-compressie, het serveren van statische bestanden, meerdere apps op dezelfde server draaien en eenvoudiger het aantal verzoeken beperken. Node kan dat allemaal. NGINX en Caddy doen het beter, en ze halen je event loop niet onderuit als er iets misgaat.

Kies NGINX als iemand in je team het al kent. Kies Caddy als je HTTPS wilt in drie regels configuratie en je geen probleem hebt met een kleiner ecosysteem voor geavanceerde configuratie.

Minimale NGINX-configuratie

Zet dit proxyblok in /etc/nginx/sites-available/api, maak een symlink naar sites-enabled en voer daarna nginx -t && systemctl reload nginx uit.

server {
    listen 80;
    server_name api.example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_cache_bypass $http_upgrade;
    }
}

De headers ‘Upgrade’ en ‘Connection’ zijn de regels voor WebSocket-ondersteuning. De eigen documentatie van NGINX wijst erop dat Upgrade een hop-by-hop-header is, dus die moet je expliciet afhandelen als je WebSocket-verkeer via de proxy doorstuurt.

Laat ze staan als je app nu WebSockets gebruikt of dat later misschien gaat doen. Socket.IO, GraphQL-subscriptions via WebSockets en verrassend veel gewone realtime functies zijn afhankelijk van die upgrade-handshake.

De meest voorkomende productiebug die ik in Node-opstellingen zie, is een Socket.IO-server achter NGINX zonder die twee regels. Verbindingen mislukken af en toe, ontwikkelaars geven Socket.IO de schuld, en het echte probleem zit meestal in de proxyconfiguratie.

Minimale Caddyfile

Hetzelfde volgens de snelstartgids voor de reverse proxy van Caddy:

api.example.com {
    reverse_proxy 127.0.0.1:3000
}

Dat is het hele bestand. Zolang het domein naar de server verwijst en poorten 80/443 bereikbaar zijn, regelt Caddy HTTPS automatisch en vernieuwt het ook zelf. Volgens de documentatie van Caddy zorgt automatische HTTPS voor TLS-certificaten voor je sites en houdt het die up-to-date. De quickstart voor de reverse proxy van Caddy vermeldt ook dat HTTPS automatisch werkt zodra Caddy de hostnaam kent.

Bind Node aan localhost, niet aan 0.0.0.0

Welke proxy je ook kiest, laat je Node-app luisteren op 127.0.0.1:3000, niet op 0.0.0.0:3000. Het enige op een Node-server dat bereikbaar mag zijn vanaf het openbare internet, is de proxy. Combineer dit met UFW, de veelgebruikte firewall-frontend van Ubuntu, om alles te blokkeren behalve de poorten 22, 80 en 443.

ufw default deny incoming
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

Draait SSH op een aangepaste poort? Sta die poort dan toe voordat je UFW inschakelt.

Bind vanaf dag één aan localhost. Een vergadering waarin iemand toegeeft dat de app openlag omdat Node aan 0.0.0.0 was gebonden, wil je niet meemaken.

Hoe stel je HTTPS in voor je Node.js-app?

Gebruik Let’s Encrypt. Het is gratis, geautomatiseerd en wordt door elke browser vertrouwd. Er zijn twee routes, afhankelijk van de proxy die je hebt gekozen.

NGINX + Certbot

Laat een A-record naar het IP-adres van je VPS verwijzen en wacht tot de DNS-wijziging is doorgevoerd.

Installeer Certbot:

apt install certbot python3-certbot-nginx

Voer uit:

certbot --nginx -d api.example.com

Certbot werkt je NGINX-configuratie bij en herlaadt de server automatisch.

Op recente Ubuntu-versies regelt een systemd-timer die met het Certbot-pakket wordt geïnstalleerd de vernieuwing automatisch.

Open https://api.example.com en controleer of je het slotje ziet.

De officiële documentatie van Certbot beschrijft ook de installatie via snap, voor als het pakket van je distributie verouderd is.

Caddy

Voeg het domein toe aan de Caddyfile (in het voorbeeld hierboven staat het er al in) en herstart Caddy. Zolang het domein correct resolvet en poorten 80/443 bereikbaar zijn, wordt het certificaat bij de eerste start automatisch aangemaakt. Certbot is niet nodig.

Laat TLS in productie niet door Node zelf afhandelen.

De https-module van Node werkt prima, maar reverse proxy's zoals NGINX en Caddy zijn speciaal gebouwd voor TLS-terminatie. Ze bieden je direct OCSP-stapling, moderne standaardinstellingen voor ciphers, automatische certificaatvernieuwing, ondersteuning voor HTTP/2 en, in het geval van Caddy, ook voor HTTP/3.

Kun je dat allemaal rechtstreeks in Node regelen? Zeker. Maar dan bouw je infrastructuur na die je proxy al uitstekend afhandelt.

Hoe ziet een productieklare Node.js-setup er echt uit?

Er zijn acht dingen waar mensen in productie tegenaan lopen. De meeste staan niet in installatietutorials, omdat ze niet passen in het verhaal van Node installeren, app draaien. Toch bepalen ze of je app de tweede maand overleeft of niet.

• NODE_ENV=production: de stap die het vaakst wordt vergeten. In veel Node-frameworks en -bibliotheken schakelt deze instelling gedrag uit dat alleen voor ontwikkeling bedoeld is en zet ze productie-optimalisaties aan. Express cachet bijvoorbeeld gecompileerde view-templates en geeft in productie beknoptere foutmeldingen. Volgens de eigen documentatie levert dat tot 3x betere prestaties op. Stel de ‘omgevingsvariabele’ overal in.
• Netjes afsluiten: als je VPS opnieuw opstart of PM2 ‘SIGTERM’ stuurt, heeft je app een paar seconden om lopende verzoeken af te handelen, databaseverbindingen te sluiten en netjes af te sluiten. Koppel daarvoor een ‘process.on(‘SIGTERM’, …)’-handler. Hoeveel tijd PM2 standaard geeft om af te sluiten, hangt af van de configuratie en de omgeving, dus ga er niet van uit dat je altijd veel tijd hebt om op te ruimen.
• Logrotatie: voor PM2 regelt de module ‘pm2-logrotate’ van PM2 dit. Bij losse systemd-units doet de systemd-journal het. Zonder rotatie vreten je logs je schijf vier keer zo snel op als je zou verwachten.
• Discipline met .env: commit nooit geheimen en log ze nooit. Gebruik ‘dotenv’ voor lokale ontwikkeling. Stel omgevingsvariabelen in productie in via ‘Environment=’ in je systemd-unit of via je PM2-ecosystem-bestand. De dag dat je per ongeluk ‘console.log(process.env)’ uitvoert, is de dag dat je alle inloggegevens moet vervangen.
• Een reverse proxy voor Node: bind Node aan localhost en laat NGINX of Caddy het contact met het openbare internet afhandelen.
• Een firewall: laat UFW alles blokkeren behalve 22, 80 en 443. SSH naar een andere poort dan 22 verplaatsen houdt een vastberaden aanvaller niet tegen, maar het scheelt wel enorm in geautomatiseerde brute-force-pogingen en rommel in je authenticatielogs.
• Monitoring: een healthcheck-endpoint dat je monitoringtool elke minuut aanroept. PM2 heeft de basis ingebouwd. Voor serieus werk draai je Prometheus en Grafana, of gebruik je een gehoste uptimedienst zoals Better Stack of UptimeRobot. Je wilt weten dat je app plat ligt voordat een klant het je vertelt.

Geschat onderhoud voor de stack hierboven: één tot drie uur per maand.

Apt-updates, af en toe een dependency bijwerken en elk kwartaal een blik op het logvolume. Dat is de prijs voor de besparing en de controle die je terugkrijgt.

Wanneer is een VPS de verkeerde keuze voor Node.js?

Een VPS is de verkeerde keuze als je workload voor iets anders is gemaakt. Wees eerlijk over aan welke kant je staat voordat je iets aanmaakt.

• Statische sites en SSG-content: een Next.js-export, Astro, Gatsby of een Eleventy-blog. Platforms als Vercel, Netlify of Cloudflare Pages bieden je direct wereldwijd gecachete statische hosting, deploys via Git en automatische rebuilds. Voor puur statische content is een VPS meestal overbodige infrastructuur.
• Sporadische, event-gestuurde workloads: Cloudflare Workers en AWS Lambda zijn goedkoop voor webhooks die tien keer per dag draaien.
• Realtime-apps met meer dan 100.000 gelijktijdige verbindingen: één VPS schaalt niet horizontaal. Je hebt dan orkestratie nodig (Kubernetes, ECS, Nomad) of een beheerd realtime-platform zoals Ably of Pusher.
• Gereguleerde workloads met zware compliance-eisen: HIPAA, PCI-DSS Level 1, FedRAMP. Een beheerd PaaS met ingebouwde compliancecertificeringen bespaart je audithoofdpijn. Zelf compliance regelen op een VPS is een project van meerdere kwartalen waar je waarschijnlijk niet op zit te wachten.
• Geen Linux-ervaring, en ook geen zin om die op te doen: platforms als Render, Railway en DigitalOcean App Platform zitten ergens tussen kale VPS-hosting en volledig beheerd PaaS in. Tools als Dokploy voegen deploymentworkflows in Heroku-stijl toe bovenop je eigen VPS-infrastructuur. Zo krijg je nog steeds veel van de kosten- en controlevoordelen, zonder dat je je hoeft te verdiepen in iptables, de binnenkant van systemd of het debuggen van een reverse proxy om 1 uur 's nachts.

Geen van die antwoorden is iets om je voor te schamen. De beste technische beslissing is de beslissing die bij je workload past.

Je Node-stack kiezen en verhuizen

Open die hostingfactuur nog één keer.

Je staat op het punt een verrassend groot deel ervan te vervangen door één VPS-rekening.

👉De stack: Ubuntu 24.04 LTS, Node 24, PM2 (of systemd), NGINX (of Caddy), Let’s Encrypt via Certbot (of de ingebouwde functie van Caddy).

Start het kleinste VPS-abonnement met het RAM dat je hebt berekend, installeer Node, draai je app op ‘127.0.0.1’, laat NGINX ernaar verwijzen en pas je DNS aan.

Overleeft de app een deploy, een herstart en een nacht draaien zonder drama? Dan ben je al een heel eind.

De rest is onderhoud. Een uur of twee per maand, af en toe een moment voor ‘apt upgrade’ en elk kwartaal je dependencies bijwerken. Dat is de deal die je sloot toen je een factuur per gebruiker inruilde voor een vast bedrag, en de zelfbeheerde VPS Stack 4 van DreamHost is een goed startpunt.

Veelgestelde vragen over Node.js draaien op een VPS