Heroku heeft zijn gratis versie beëindigd en de minimumprijs verhoogd. Vercel rekent per gebruiker en beëindigt langlopende taken. Render en Railway schalen de prijs met het verkeer.
Open de meest recente factuur van je hostingprovider. De Node-app, een Postgres-database en een Redis-cache. Drie regelposten, drie sets met waarschuwingen voor overschrijdingen, één hectische Slack-thread op de dag dat marketing eindelijk een campagne lanceert.
Die rekening is waarom veel teams opnieuw naar de VPS kijken. Node.js zelf maakt het niet uit waar het draait. Het enige waar serverless je voor beschermde was erachter komen wat er gebeurt na ‘npm start’.
Laten we kijken naar een productieopstelling-patroon voor Node.js op een Linux box die je beheert. Als je via SSH in een box kunt inloggen en een configuratiebestand kunt lezen, dan heb je aan het einde 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 thuisbasis voor Node.js wanneer je een langlopend proces hebt, een stack die je wilt consolideren in één rekening, of een beheerde-runtime factuur die het gemak is ontgroeid.
In het algemeen zijn er drie goede mogelijkheden:
- Langlevende processen: WebSocket servers, queue workers, cron schedulers, MCP servers. Alles wat moet blijven draaien en luisteren. De meeste serverloze platformen zijn nog steeds geoptimaliseerd voor kortdurende uitvoeringen en verzoeklevenscycli. Een Node proces op een VPS zit er gewoon.
- Kostenconsolidatie: Node app, Postgres, Redis, plus een kleine build worker leven allemaal op dezelfde 4 GB box. Eén factuurregel, niet vier.
- Apps die PaaS ontgroeid zijn: Functietime-outs op je lange PDF-generatiejob. Prijs per zitplaats voor een team dat eindelijk een vierde ingenieur inhuurde. Een Heroku factuur die de $60 per maand passeert voor een werklast die prima draait op een VPS van $15.
En er zijn drie verkeerde passingen:
- Statische sites en SSG-content: Een Next.js export, een Astro build, een Gatsby blog. De gratis versie van Vercel is het juiste gereedschap. Een VPS is overbodig.
- Schaarse, event-gedreven 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 is of slaapt.
- Horizontaal geschaalde real-time apps: Als je WebSocket-server moet uitzenden naar 100.000 gelijktijdige verbindingen, is één VPS niet het antwoord. Dat is een Kubernetes-cluster, een gedistribueerde edge-infrastructuur of een beheerd real-time platform.
JavaScript is de meest gebruikte taal in de 2025 Stack Overflow Developer Survey, en Node.js blijft een van de standaardmanieren waarop ontwikkelaars JavaScript op de backend draaien. Dat zijn heel wat mensen die Node ergens draaien. Dit artikel is voor die groep die het liever op een server draait die ze zelf beheren.
Ik heb teams gezien die vier productie Node-services van Heroku naar een enkele 4 GB VPS verplaatsten, met dezelfde uptime, een derde van de rekening en langlevende WebSockets die eindelijk werkten zonder een tijdelijke oplossing.
De migratie bestaat voornamelijk uit een middag van ‘apt install’, een ‘pm2 start’ en een DNS-wijziging.
Welke VPS-Specificaties Heeft Node.js Daadwerkelijk Nodig?
Node.js zelf is lichtgewicht. Een minimale Express-server kan inactief zijn met minder dan 100 MB aan resident geheugen. Het advies dat “Node slechts 1 GB nodig heeft” dat je nog steeds op oudere blogs kunt vinden, is technisch gezien waar en praktisch nutteloos. Tegen de tijd dat je Postgres, Redis, logboeken en een implementatieproces hebt toegevoegd dat niet alleen op hoop is gebaseerd, zit je op een rustige dag al snel boven die limiet.
Realistische dimensionering voor gangbare werklasten:
| Werklast | RAM | vCPU | Opslag | Aantekeningen |
|---|---|---|---|---|
| Kleine Express API, geen DB op de box | 2 GB | 1-2 | 40 GB NVMe | Realistische minimum voor één productie-app |
| Node API + Postgres + Redis op één box | 4 GB | 2 | 80 GB NVMe | Het ideale punt; de meeste teams belanden hier |
| SSR-zware app (Next.js, Nuxt, Remix) | 8 GB | 4 | 80 GB NVMe | SSR-rendering en build pipelines zijn waar het geheugen naartoe gaat |
| Real-time/WebSocket-app, gematigde schaal | 8 GB | 4 | 80 GB NVMe | Elke persistente verbinding verbruikt geheugen |
Een paar details om vast te leggen voordat je gaat voorzien:
- NVMe-opslag is belangrijker dan de ruwe schijfgrootte: Moderne Node-apps raken duizenden kleine bestanden aan tijdens installaties, builds en opstarten. Trage schijven maken afhankelijkheidsinstallaties, koude starts en SSR-rebuilds merkbaar slechter.
- KVM-virtualisatie, geen OpenVZ: Oudere OpenVZ-gebaseerde plannen delen een kernel met de host, wat kan leiden tot verouderde kernelversies en incidentele compatibiliteitsproblemen met nieuwere runtimes. De meeste gerenommeerde VPS-aanbieders gebruiken nu alleen KVM, maar het is nog steeds de moeite waard om te controleren.
- Swapruimte: Schakel 1-2 GB swap in op kleinere boxes. De V8 heap van Node kan hard schommelen tijdens garbage collection. Zonder swap doodt een tijdelijke piek het proces. Ik heb gezien hoe een box van 4 GB OOM werd tijdens een routine-implementatie omdat iemand swap had uitgeschakeld, denkend dat het een anachronisme uit het Docker-tijdperk was.
- Bandbreedte: De meeste moderne VPS-plannen omvatten 1-4 TB aan maandelijkse bandbreedte, genoeg voor bijna alles behalve videohosting. Zelfbeheerde VPS-plannen bevatten ongemeten bandbreedte, een minder lijn op de capaciteitsplannings-spreadsheet.
Een 4 GB VPS kost ongeveer $15 per maand tegen het markttarief. Dat is 50 cent per dag, of ongeveer één vliegveldkoffie elke twee weken. Vergeleken met het apart betalen voor app-runtimes, beheerde Postgres en Redis op een PaaS, keren de economische voordelen verrassend snel om.
Welke Node.js Versie Moet Je Installeren?
Installeer Node.js 24 (codenaam Krypton). Dit is de huidige actieve LTS-versie, gelanceerd in oktober 2025 en ondersteund tot april 2028 volgens het officiële Node.js uitgaveschema.
Veel handleidingen wijzen mensen nog steeds op Node 22. Die gidsen zijn niet bijgewerkt. Als je vandaag een nieuwe implementatie start, zet dan je CI-afbeelding en je VPS vast op Node 24.x.
| Versie | Codenaam | Status | EOL |
|---|---|---|---|
| Node.js 26.x | (geen) | Huidig | Promoveert naar LTS eind 2026 |
| Node.js 24.x | Krypton | Actieve LTS | April 2028 |
| Node.js 22.x | Jodium | Onderhouds-LTS | April 2027 |
| Node.js 20.x | Ijzer | Einde van levensduur | | Bereikte EOL 30 april 2026. Niet gebruiken. |
Een paar vuistregels:
- Gebruik geen huidige (niet-LTS) releases in productie: Node 26 bestaat voor het testen van toekomstige compatibiliteit en nieuwe runtimefuncties, niet voor de app waarvan je inkomsten afhankelijk zijn.
- Node 22 is de terugvaloptie als een kritieke afhankelijkheid nog steeds niet compatibel is met Node 24: De meeste van het ecosysteem stabiliseerden binnen enkele maanden na de LTS-promotie.
- Zet je Node-versie overal vast: Je CI-afbeelding, Dockerfile, .nvmrc en productie VPS moeten allemaal overeenkomen. “Werkt op mijn machine” wordt snel duur zodra native modules deel uitmaken van het gesprek.
🤔Bun Overwegen? Het is sneller bij sommige werkbelastingen en echt indrukwekkend, maar het ecosysteem is nog kleiner, en het productietraject is korter dan dat van Node. Voor de meeste teams wint saai.
NodeSource, dat de apt en yum repositories beheert waar veel productieteams Node van installeren, benadrukt verbeteringen in de 24.x lijn, beginnend met een nieuwere V8-motor. Node 24 levert nu ook volwassen gereedschappen zoals ingebouwde node –watch en een stabiele native testrunner (node: test), die beide gestabiliseerd zijn in de 20–22 lijnen en hier worden voortgezet. Het is niets opzienbarends. Het verwijdert gewoon elke maand een beetje operationele wrijving.
Hoe Installeer Je Node.js Op Een VPS?
Je hebt twee realistische installatiepaden. Kies op basis van of de server één Node-app of meerdere draait.
NodeSource Voor Een Single-App Server
Dit is het eenvoudigste productiepad. Eén installatiescript en één apt install geven je de huidige Node 24 LTS lijn als een systeempakket, en toekomstige beveiligingsupdates verlopen 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 RHEL-familie distributies (yum/dnf) zijn te vinden in de officiële NodeSource distributies repository.
nvm voor Per-Project Versie Schakeling
nvm (Node Version Manager) installeert Node in je thuismap en laat verschillende projecten verschillende Node-versies draaien. Nuttig als je meerdere apps op dezelfde server host of geen sudo-toegang hebt.
Draai dit 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 dan Node 24:
nvm install 24
nvm use 24
nvm alias default 24 👉Een belangrijke regel: Gebruik sudo ‘npm install -g’ niet voor applicatieafhankelijkheden.
Globale installaties zijn meestal gereserveerd voor machine-niveau CLI-tools zoals pm2, typescript of nodemon. De afhankelijkheden van je app horen in package.json en moeten vanuit de projectmap worden geïnstalleerd met npm ci.
| NodeSource | nvm |
|---|---|
| Één Node-versie per server | Meerdere Node-versies per server |
| Geïnstalleerd voor het hele systeem, draait als elke gebruiker | Per gebruiker geïnstalleerd |
Auto-updates met ‘apt’ | Handmatig beheerd |
Vereist sudo | Geen sudo vereist |
Als je het niet zeker weet, begin dan met NodeSource. De meeste servers voor één specifiek doel hebben geen per-project Node versiewisseling nodig.
👉DreamHost Zelfbeheerde VPS-gebruikers: De Node-app die beschikbaar is bij provisioning wordt geleverd met Node 22 LTS — nog steeds ondersteund tot april 2027. Om Node 24 te gebruiken, volg de NodeSource of nvm stappen hierboven na provisioning.
Moet Je PM2 Of Systemd Gebruiken Om Je App Draaiende Te Houden?
Beide werken. Het eerlijke antwoord is welke jouw team prettig vindt. PM2 is het ontwikkelaarsvriendelijke pad. systemd is het Unix-georiënteerde pad. Beide lossen dezelfde drie problemen op: herstarten bij crash, starten bij opstarten en gracieus afsluiten bij ‘SIGTERM’.
Als je helemaal opnieuw begint, is hier hoe je kunt kiezen:
| PM2 | systemd | |
|---|---|---|
| Installatietijd | 3 minuten | 10 minuten |
| Clustermodus (meerdere kernen) | Ingebouwd | Niet ingebouwd (start N eenheden) |
| Logrotatie | Module: 'pm2-logrotate' | Ingebouwd via 'journalctl' |
| Herladen zonder downtime | 'pm2 herladen' | Meestal handmatig afgehandeld met rollende herstarts of meerdere eenheden |
| Geheugenoverhead (daemon) | Kleine daemon overhead | Geen (geen extra daemon) |
| Beste voor | Enkele box, JS-shop, snelle iteratie | Meerdere app-boxen, comfort voor operationele teams |
De PM2 snelle start is precies dat, snel:
npm install -g pm2
pm2 start app.js --name api
pm2 startup # geeft de systemd opstartopdracht weer om uit te voeren
pm2 save # slaat de huidige proceslijst op PM2 wordt dan het enige waar je mee praat: ‘pm2 logs,’ ‘pm2 reload api,’ ‘pm2 monit.’
👉Ook goed om te weten: ‘pm2 startup‘ schrijft een systemd-eenheid, dus de PM2-configuratie gebruikt daadwerkelijk systemd onder de motorkap.
Een minimale systemd-eenheid voor direct Node-beheer op ‘/etc/systemd/system/api.service’:
[Unit]
Beschrijving=Mijn Node API
Na=network.target
[Service]
Type=simple
User=app
WorkingDirectory=/var/www/api
ExecStart=/usr/bin/node server.js
Restart=on-failure
RestartSec=5
Environment=NODE_ENV=production
StandardOutput=journal
StandardError=journal
[Install]
WantedBy=multi-user.target
Voer dan ‘systemctl enable --now api‘ uit. Logs zijn te vinden in ‘journalctl -u api -f‘.
Als je al PM2 gebruikt en het werkt, migreer dan niet naar systemd alleen omdat iemand op Hacker News dat zei. Het geheugen van de PM2 daemon is niet de reden waarom je ervan zou migreren.
Migreer wanneer je een echte reden hebt, zoals het draaien van een half dozijn Node-processen waar elke megabyte telt, of het verzenden naar een ops-omgeving waar elke andere service een systemd-eenheid is, en PM2 opvalt als de vreemde eend in de bijt.
Hoe Plaats Je NGINX (of Caddy) Voor Je Node App?

Je wilt een reverse proxy voor Node om vijf redenen: HTTPS-beëindiging, gzip/brotli compressie, statische assetverlening, meerdere apps op dezelfde server draaien en makkelijkere snelheidsbeperking. Node kan dit allemaal doen. NGINX en Caddy doen het beter, en ze laten je event loop niet crashen als er iets misgaat.
Kies NGINX als iemand in je team er al bekend mee is. Kies Caddy als je HTTPS wilt in drie regels configuratie en je tevreden bent met een kleiner geavanceerd-configuratie-ecosysteem.
Minimale NGINX Configuratie
Plaats dit proxyblok in /etc/nginx/sites-available/api, maak een symlink naar sites-enabled, en voer dan 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 ‘Upgrade’ en ‘Connection’ headers zijn de regels die WebSocket-ondersteuning bieden. De eigen documentatie van NGINX geeft aan dat Upgrade een hop-by-hop header is, dus het vereist expliciete afhandeling bij het proxien van WebSocket-verkeer.
Laat ze staan als je app nu WebSockets gebruikt, of dat later misschien doet. Socket.IO, GraphQL-abonnementen via WebSockets en een verrassend aantal “gewone” realtime functies zijn afhankelijk van die upgrade-handdruk.
Het meest voorkomende productieprobleem dat ik zie in Node-opstellingen is een Socket.IO-server achter NGINX zonder die twee regels. Verbindingen mislukken sporadisch, ontwikkelaars geven Socket.IO de schuld, en het eigenlijke probleem is meestal de proxyconfiguratie.
Minimale Caddyfile
De Caddy reverse proxy snelstart versie van hetzelfde:
api.example.com {
reverse_proxy 127.0.0.1:3000
} Dat is het hele bestand. Zolang het domein naar de server wijst en poorten 80/443 bereikbaar zijn, regelt Caddy automatisch HTTPS-provisies en vernieuwingen. Caddy’s documentatie zegt automatische HTTPS-provisies TLS-certificaten voor sites en houdt deze vernieuwd; de snelstartgids voor de reverse proxy merkt ook op dat HTTPS automatisch is wanneer Caddy de hostnaam kent.
Koppel Node Aan localhost, Niet Aan 0.0.0.0
Welke proxy je ook kiest, configureer je Node-applicatie om te luisteren op 127.0.0.1:3000, niet op 0.0.0.0:3000. Het enige dat met het openbare internet verbonden moet zijn op een Node-box is de proxy. Combineer dit met UFW, de gangbare firewall frontend van Ubuntu, om alles te weigeren behalve poorten 22, 80 en 443.
ufw standaard weiger binnenkomend
ufw toestaan 22/tcp
ufw toestaan 80/tcp
ufw toestaan 443/tcp
ufw inschakelen Als SSH draait op een aangepaste poort, sta die poort toe voordat je UFW inschakelt.
Verbind vanaf dag één met localhost. De vergadering waar iemand toegeeft “de app was blootgesteld omdat Node verbond met 0.0.0.0” is niet een vergadering die je wilt hebben.
Hoe Stel Je HTTPS In Voor Je Node.js App?
Gebruik Let’s Encrypt. Het is gratis, geautomatiseerd en vertrouwd door elke browser. Er zijn twee paden, afhankelijk van welke proxy je hebt gekozen.
NGINX + Certbot
Wijs een A-record toe aan je VPS IP en wacht tot de DNS zich heeft verspreid.
Installeer Certbot:
apt install certbot python3-certbot-nginx Start:
certbot --nginx -d api.example.com Certbot werkt je NGINX-configuratie bij en herlaadt de server automatisch.
Op moderne Ubuntu-versies wordt de verlenging automatisch afgehandeld door een systemd-timer die door het Certbot-pakket is geïnstalleerd.
Open https://api.example.com en bevestig het sloticoon.
De officiële Certbot documentatie behandelt ook de snap-gebaseerde installatieroute als jouw distropakket verouderd is.
Caddy
Voeg het domein toe aan het Caddyfile (het voorbeeld hierboven heeft het al), en herstart dan Caddy. Zolang het domein correct oplost en de poorten 80/443 bereikbaar zijn, wordt het certificaat automatisch verstrekt bij de eerste start. Er is geen Certbot.
Zet TLS niet stop in Node zelf voor productie.
Node’s https module werkt perfect, maar reverse proxies zoals NGINX en Caddy zijn speciaal gebouwd voor TLS-terminatie. Ze bieden je OCSP-stapeling, moderne standaardcijfers, automatische certificaatvernieuwing, HTTP/2-ondersteuning en — in het geval van Caddy — HTTP/3-ondersteuning standaard.
Kun je dat allemaal rechtstreeks in Node afhandelen? Zeker. Je zou gewoon infrastructuur herbouwen die je proxy al uiterst goed oplost.
Hoe Ziet Een Productieklare Node.js Setup Eruit?
Acht dingen bijten mensen in productie. De meeste staan niet in installatiehandleidingen omdat ze niet passen in het “installeer Node, draai app” verhaal. Ze vormen het verschil tussen een app die de tweede maand overleeft en een die dat niet doet.
- NODE_ENV=production: De meest gemiste stap. In veel Node frameworks en bibliotheken schakelt het gedrag alleen geschikt voor ontwikkeling uit en activeert het optimalisaties voor productie. Express bijvoorbeeld, slaat gecompileerde weergavesjablonen op en geeft compactere fouten in productie – zijn eigen documentatie noemt een prestatieverbetering tot 3x. Stel de ‘env var’ overal in.
- Graceful shutdown: Wanneer jouw VPS opnieuw opstart of PM2 ‘SIGTERM’ stuurt, heeft je app een paar seconden om lopende verzoeken te verwerken, databaseverbindingen te sluiten en schoon af te sluiten. Stel een ‘process.on(‘SIGTERM’, …)’ handler in. PM2’s standaard shutdown timing hangt af van configuratie en omgeving, dus ga er niet vanuit dat je altijd veel tijd hebt om op te ruimen.
- Logrotatie: PM2’s ‘pm2-logrotate’ module regelt dit voor PM2. Het systemd-journaal handelt het af voor directe systemd-eenheden. Zonder rotatie, vullen je logs de schijf in een kwart van de tijd die je zou verwachten.
- .env discipline: Geef nooit geheimen vrij, log ze nooit. Gebruik ‘dotenv’ voor lokale ontwikkeling. In productie, stel env vars in via je systemd-eenheids ‘Environment=’ of je PM2 ecosysteembestand. De dag dat je per ongeluk ‘console.log(process.env)’ doet, is de dag dat je elke referentie roteert.
- Een reverse proxy voor Node: Verbind Node met localhost; laat NGINX of Caddy het openbare internet onder ogen zien.
- Een firewall: UFW weigert alles behalve 22, 80, 443. SSH verplaatsen van poort 22 stopt geen vastberaden aanvaller, maar het vermindert aanzienlijk de automatische brute-force ruis en ongewenste auth logs.
- Monitoring: Een healthcheck-endpoint dat je monitoringtool elke minuut controleert. PM2 heeft ingebouwde basisfuncties. Voor iets serieus, gebruik Prometheus en Grafana, of gebruik een gehoste uptime service zoals Better Stack of UptimeRobot. Je wilt weten dat je app niet werkt voordat een klant het je vertelt.
Onderhoudsschatting voor de bovenstaande stack: één tot drie uur per maand.
Apt-updates, incidentele afhankelijkheidsverhogingen en een driemaandelijks overzicht van het logboekvolume. Dat is de ruil voor de kosten- en controlevoordelen.
Wanneer Is Een VPS De Verkeerde Keuze Voor Node.js?
Een VPS is de verkeerde keuze als je werklast bedoeld is voor iets anders. Wees eerlijk over welke kant je op gaat voordat je provisioneert.
- Statische Sites En Ssg-Inhoud: Next.js export, Astro, Gatsby en een Eleventy blog. Platforms zoals Vercel, Netlify of Cloudflare Pages bieden je wereldwijd gecachte statische hosting, Git-gebaseerde deployments en automatische herbouwen standaard. Een VPS is meestal overbodige infrastructuur voor puur statische inhoud.
- Sparse, Event-Driven Workloads: Cloudflare Workers en AWS Lambda zijn goedkoop voor webhooks die tien keer per dag draaien.
- Real-Time Apps Die Meer Dan 100.000 Gelijktijdige Verbindingen Nodig Hebben: Eén VPS schaalt niet horizontaal. Je hebt orkestratie nodig (Kubernetes, ECS, Nomad) of een beheerd real-time platform zoals Ably of Pusher.
- Compliance-Intensieve Gereguleerde Workloads: HIPAA, PCI-DSS Level 1, FedRAMP. Een beheerd PaaS met ingebouwde compliance-certificeringen bespaart auditproblemen. Zelf-hosting compliance op een VPS is een project van meerdere kwartalen dat je waarschijnlijk niet wilt.
- Geen Linux Comfort — En Geen Zin Om Dit Op Te Bouwen: Platforms zoals Render, Railway en DigitalOcean App Platform bevinden zich ergens tussen ruwe VPS hosting en volledig beheerd PaaS. Tools zoals Dokploy voegen Heroku-stijl deployment workflows toe aan je eigen VPS-infrastructuur. Je behoudt nog steeds veel van de kosten- en controlevoordelen zonder diep vertrouwd te raken met iptables, systemd internals, of reverse-proxy debugging om 1 uur ‘s nachts.
Er is geen schaamte in een van die antwoorden. De beste technische beslissing is degene die overeenkomt met je werklast.
Je Node Stack Kiezen En Verhuizen
Open die hostingfactuur nog een keer.
Je staat op het punt om een verrassende hoeveelheid ervan te vervangen door één VPS-factuur.
👉De stack: Ubuntu 24.04 LTS, Node 24, PM2 (of systemd), NGINX (of Caddy), Let’s Encrypt via Certbot (of Caddy’s ingebouwde).
Start de kleinste VPS-plan dat voldoet aan de RAM die je hebt berekend, installeer Node, draai je app op ‘127.0.0.1,’ richt NGINX erop, en wijzig je DNS.
Als de app een implementatie, een herstart en een nachtelijke run zonder problemen overleeft, ben je al een heel eind op weg.
Het overige is onderhoud. Een uur of twee per maand, af en toe een ‘apt upgrade’ venster, een driemaandelijkse afhankelijkheidsverhoging. Dat is de afspraak die je hebt gemaakt toen je een per-stoel factuur inruilde voor een vaste, en DreamHost’s Self-Managed VPS Stack 4 is waar je kunt beginnen.

Beheer je volledige stack. Apps, AI, databases en meer.
Houd al je inloggegevens en gesprekken op een server die jij beheert, met ingebouwde NVMe-snelheid en ongelimiteerde bandbreedte.
Bekijk VPS-hostingabonnementenVeelgestelde Vragen Over Het Draaien Van Node.js Op Een VPS
Kan Ik Node.js Op Elke VPS Draaien?
De meeste moderne VPS-plannen draaien prima op Node.js. Moderne op KVM gebaseerde VPS-plannen met een 64-bit Linux-distributie zijn de veiligste standaard voor huidige Node.js-releases.
Oudere OpenVZ-gebaseerde plannen hebben soms kernelbeperkingen die nieuwere Node-versies breken. Als je tussen aanbieders kiest, vraag dan of ze op KVM zijn gebaseerd.
Hoeveel RAM heeft Node.js nodig op een VPS?
Een minimale Express-server draait stationair ruim onder de 100 MB, maar een realistische productieapp met middleware, logboeken en een connectiepool draait doorgaans in het bereik van 150-300 MB.
De realistische minimumvereiste voor één productie-app is 2 GB; het optimale punt voor een Node + Postgres + Redis stack is 4 GB. DreamHost’s Self-Managed VPS Stack 4 (4 GB) kan de meeste productie Node werklasten aan. Stap over naar Stack 8 (8 GB) voor SSR-zware of real-time apps.
Wat Is De Huidige Node.js LTS Versie?
De huidige actieve LTS is Node.js 24.x (“Krypton”), gepromoveerd op 28 oktober 2025 en ondersteund tot april 2028. Node.js 22.x (“Jod”) is in onderhouds-LTS tot april 2027 als een afhankelijkheid achterwaartse compatibiliteit vereist. Node.js 26 is gelanceerd op 5 mei 2026, als huidig en zal in oktober 2026 tot LTS worden bevorderd.
De meeste productieteams houden zich aan LTS-releases, tenzij ze specifiek nieuwere runtimefuncties nodig hebben.
Heb Ik PM2 Nodig Als Ik Systemd Heb?
Nee, je hebt niet beide nodig. PM2 en systemd lossen hetzelfde probleem op: ervoor zorgen dat je Node-app blijft draaien bij crashes en herstarts. Veel op Node gerichte teams kiezen PM2 vanwege de ingebouwde clustering, logbeheer en herlaadtools.
Teams die al systemd-eenheden gebruiken voor alles kiezen voor systemd.
Waarom NGINX voor Node.js plaatsen?
NGINX (of Caddy) voor Node.js centraliseert TLS-beëindiging, compressie, het serveren van statische assets en snelheidsbeperking in software die specifiek is ontworpen voor proxying en webserving.
Het stelt je ook in staat om meerdere Node-apps op dezelfde VPS te draaien zonder poortconflicten. In productie luistert Node naar localhost; NGINX staat tegenover het openbare internet.
Is Node.js op een VPS goedkoper dan Heroku of Vercel?
Ja, vaak. Een 4 GB VPS valt doorgaans ergens in de $15-$25/maand range op markttarief en kan app runtime, database, en cache kosten die apart gefactureerd worden op veel PaaS platforms consolideren.
Vercel Pro prijzen zijn gebaseerd op het aantal plaatsen, en serverloze platforms leggen nog steeds uitvoeringsduurlimieten op, afhankelijk van de runtime en het plan.
De afspraak is dat je zelf de operaties beheert, ongeveer één tot drie uur per maand.
Kan ik meerdere Node apps draaien op één VPS?
Ja, en het is de meest voorkomende reden waarom teams overstappen van PaaS naar een VPS. Draai elke app op zijn eigen interne poort (3000, 3001, 3002) en leid verkeer om met NGINX serverblokken op basis van hostnaam. PM2 beheert ze allemaal als afzonderlijke processen; systemd gebruikt één unit-bestand per app.
Een 4 GB VPS kan vaak meerdere lichte Node-services samen met een kleine databasewerklast aan.
Kan Ik Node.js Draaien Op DreamHost Shared Hosting?
Nee. Node.js heeft persistente processen, pakketinstallaties op rootniveau en directe poortbinding nodig, die geen van alle door shared hosting worden geboden. DreamHost’s Self-Managed VPS-plannen (Stack 4 en hoger) zijn geschikt voor Node-werklasten met volledige root-toegang, NVMe-opslag en ongemeten bandbreedte.
