Publieke testfase We zitten in een publieke testfase — kijk gerust rond, maar bestellen kan nog niet. Bestellen kan vanaf 1 oktober 2026. Bekijk prijzen →

Node.js-apps: Next.js, Nuxt, SvelteKit en Express

Een JavaScript-app-site draait je eigen Node.js-server: Next.js, Nuxt, SvelteKit, Express, of wat dan ook dat op een poort luistert. Wij bouwen hem vanuit Git, starten hem als bewaakte service en zetten nginx ervoor. Dit artikel beschrijft wat je app moet doen — en wat wij ervoor doen.

Hoe het draait

  • Node.js 22 of 24 (LTS-versies), te wisselen op de sitepagina onder Geavanceerd → Node.js.
  • Je app wordt gestart door de servicemanager van het systeem als eigen gebruiker, herstart bij een crash en krijgt een geheugenlimiet die bij je abonnement past.
  • nginx luistert aan de buitenkant. Alles in de map public/ van je project wordt rechtstreeks van schijf geserveerd; elk ander verzoek — pagina's, API-routes, WebSockets — gaat door naar je app.
  • TLS, je domein, back-ups en monitoring werken precies zoals bij elke andere site.

Deployen

Koppel een repository onder Publiceren → Deployen vanuit Git (zie Deployen vanuit Git). Bij elke deploy doen wij:

  1. je installatiecommando (npm ci, tenzij je een ander instelt) en je build-commando (npm run build als je package.json een build-script heeft) in een aparte build-container;
  2. het gebouwde project — zonder node_modules — naar je site kopiëren;
  3. daar de productie-afhankelijkheden installeren met de Node-versie van je site (npm ci --omit=dev);
  4. je app herstarten en wachten tot hij op zijn poort antwoordt. Een deploy telt pas als klaar wanneer dat gebeurt — een fout startcommando of een ontbrekende afhankelijkheid laat de deploy mislukken en bewaart de log voor je.

Het startcommando

Standaard draaien we npm start als je package.json dat definieert, anders node server.js of node index.js. Heeft je framework iets anders nodig, stel het dan in op de sitepagina onder Geavanceerd → Node.js → Startcommando:

FrameworkBuild-commandoStartcommando
Next.jsnpm run buildnpm start (de standaard)
Nuxtnpm run buildnode .output/server/index.mjs
SvelteKit (adapter-node)npm run buildnode build
Express / gewone Nodemeestal geennode server.js (de standaard)

Het commando draait vanuit de hoofdmap van je project, met de Node-versie van je site vooraan op het PATH.

De omgevingsvariabele PORT

Je app moet luisteren op de poort in process.env.PORT (wij zetten die op 3000), op 127.0.0.1 of op alle interfaces — nginx verbindt er lokaal mee. Next.js, Nuxt en de Node-adapter van SvelteKit lezen PORT zelf; in Express is het één regel:

app.listen(process.env.PORT || 3000);

We zetten ook NODE_ENV=production en een passende V8-heapgrootte voor je abonnement. Voeg je eigen variabelen toe — API-sleutels, database-URL's — onder Geavanceerd → Omgevingsvariabelen; ze worden naar de omgeving van de service geschreven en je app wordt herstart, zodat hij ze bij het volgende verzoek ziet. Praat je app met de beheerde database, dan staan de DB_*-variabelen er al: lees ze met process.env.DB_HOST en consorten.

Achter een proxy

Verzoeken bereiken je app als gewoon HTTP vanaf nginx, met de echte gegevens in headers: X-Forwarded-Proto (https), X-Forwarded-For, X-Real-IP en X-Forwarded-Host. Laat je framework ze vertrouwen, zodat het https://-links maakt en het adres van de bezoeker ziet — in Express: app.set('trust proxy', 1); Next.js en Nuxt regelen dit standaard.

Statische bestanden en WebSockets

Zet bestanden die nooit veranderen — afbeeldingen, lettertypen, downloads — in public/: nginx serveert ze zonder je app wakker te maken en geeft ze een week browsercache mee. Asset-routes van je framework (/_next/static, /_nuxt) serveert je app zoals gewoonlijk. WebSocket-upgrades worden doorgegeven, dus Socket.IO, live reload of een chatfunctie hebben geen extra instellingen nodig.

Als er iets stuk is

Het tabblad "Logs" toont de eigen uitvoer van je app (alles wat hij naar de console schrijft), nieuwste eerst — een mislukte start staat bovenaan. Veelvoorkomende oorzaken: de app luistert op een vaste poort in plaats van PORT, een afhankelijkheid staat in devDependencies maar is tijdens het draaien nodig, of het startcommando wijst naar een bestand dat de build niet heeft gemaakt. Repareren, pushen, opnieuw deployen.