Production readiness checklist voor Node.js apps

Je staat op het punt om je Node.js applicatie live te zetten. Alles draait lokaal, de tests groen, de feature reviews afgetekend. Toch is dat moment vlak voor productie het moment waarop de meeste problemen ontstaan. Een goede production readiness checklist voor Node.js voorkomt dat je om 3 uur 's nachts wakker gebeld wordt.

In dit artikel krijg je een praktische checklist met 12 punten. Van graceful shutdown tot observability, van secrets management tot deploys. Loop deze lijst door voordat je naar productie gaat, en je zit aan de veilige kant.

1. Environment variables en configuratie

Hardcoded configuratie is een klassieke productiefout. Gebruik environment variables voor alles wat per omgeving verschilt: database URLs, API-keys, ports en feature flags.

• Gebruik dotenv lokaal, maar nooit in productie zelf
• Valideer env vars bij startup (bijvoorbeeld met Zod)
• Faal hard als een verplichte variabele ontbreekt
• Documenteer alle variabelen in een .env.example

Een app die stilletjes draait met ontbrekende configuratie is gevaarlijker dan een app die niet start. Combineer dit met validatie via Zod om type-safe configuratie af te dwingen.

2. Secrets management

Zet secrets nooit in je git repo. Ook niet in .env files die ergens op een server slingeren.

• Gebruik een secrets manager (AWS Secrets Manager, HashiCorp Vault, Doppler)
• Injecteer secrets via environment variables op runtime
• Roteer secrets periodiek
• Scan je repo met tools als gitleaks op gelekte keys

Als een secret ooit in git heeft gestaan, ook al is hij weggecommit: beschouw hem als gelekt en roteer direct.

3. Graceful shutdown

Een Node.js app die abrupt stopt, verliest in-flight requests en laat database connecties open. Implementeer graceful shutdown voor signals zoals SIGTERM en SIGINT.

const server = app.listen(PORT);

const shutdown = async () => {
  console.log('Shutdown started');
  server.close(() => console.log('HTTP closed'));

  await db.end();
  await redis.quit();
  process.exit(0);
};

process.on('SIGTERM', shutdown);
process.on('SIGINT', shutdown);

Geef je app voldoende tijd (bijvoorbeeld 30 seconden) om lopende requests af te ronden. Dit speelt samen met error handling op schaal: onverwerkte errors moeten nooit een abrupte crash triggeren zonder cleanup.

4. Health checks en probes

Je orchestrator (Kubernetes, ECS, of een load balancer) moet weten of je app gezond is.

• Liveness: /healthz, reageert zolang de process loopt
• Readiness: /readyz, reageert pas als DB, cache en dependencies bereikbaar zijn
• Startup: /startupz, voor apps met trage opstart

Houd deze endpoints licht. Zware health checks brengen juist extra load met zich mee. Log ze ook niet standaard mee, anders vervuil je je logs.

5. Logging op productieniveau

console.log is geen logging. Gebruik een structured logger zoals pino of winston.

• Log in JSON-formaat voor machine-leesbaarheid
• Gebruik log levels (debug, info, warn, error)
• Voeg een correlation ID toe per request
• Log nooit wachtwoorden, tokens of PII

Stuur logs naar een centrale plek (Elasticsearch, Loki, Datadog, CloudWatch). Lokaal op de server tailen van logs is geen productiepraktijk.

6. Monitoring en metrics

Zonder metrics werk je blind. Meet minimaal:

• Request latency (p50, p95, p99)
• Error rate per endpoint
• Event loop lag
• Memory en CPU per process
• Database query tijden

Gebruik prom-client voor Prometheus of een APM-tool zoals Datadog of New Relic. Koppel dit aan alerts op je meest kritieke paden. Zie ook onze gids over performance tuning in Node.js voor welke metrics er écht toe doen.

7. Error handling en alerting

Errors die alleen in logs verdwijnen zijn waardeloos als niemand ze ziet.

• Integreer Sentry, Bugsnag of Rollbar voor error tracking
• Definieer alert thresholds (bijv. >1% 5xx errors)
• Onderscheid operational errors van programmer errors
• Crash-en-herstart bij unrecoverable errors (laat je process manager je app weer starten)

Een unhandledRejection of uncaughtException mag nooit silent zijn. Log, alert en herstart.

8. Security hardening

Basisbeveiliging die je niet mag overslaan:

• Gebruik helmet voor security headers
• Enforce HTTPS via je reverse proxy
• Rate limiting op publieke endpoints (express-rate-limit)
• CORS strict configureren, geen wildcards in productie
• Dependencies scannen met npm audit of Snyk
• Gebruik JWT of sessions correct en verlopen tokens afdwingen

Draai je app ook niet als root, en beperk filesystem permissies. De OWASP Node.js security cheatsheet is een waardevolle referentie.

9. Database en connection pooling

Connection leaks leggen je app onder load plat.

• Gebruik een connection pool (bijv. pg-pool voor Postgres)
• Stel sensible max connections in, afgestemd op je DB-capaciteit
• Sluit connecties netjes bij shutdown
• Monitor active en idle connecties
• Voorzie retry logic met backoff voor transient failures

Test ook wat er gebeurt als je database even wegvalt. Reconnect je app? Of blijft hij vastzitten? De praktische gids over werken met databases in Node.js gaat hier dieper op in.

10. Process management en clustering

In productie draai je Node.js niet met node index.js.

• Gebruik een process manager: PM2, systemd, of een container orchestrator
• Zorg voor automatische restart bij crashes
• Configureer memory limits om runaway processes af te sluiten
• Gebruik clustering of horizontal scaling om meerdere cores te benutten

In een Kubernetes-omgeving laat je replica management aan de orchestrator. Dan heb je per pod één Node.js proces nodig.

11. CI/CD en deploys

Handmatig SSH'en naar productie is een recept voor ellende.

• Automatiseer deploys via GitHub Actions, GitLab CI of CircleCI
• Run tests in je pipeline (zie testing strategieën)
• Bouw immutable artifacts (Docker images met een git SHA tag)
• Ondersteun rollbacks met één klik
• Gebruik blue-green of rolling deploys voor zero-downtime releases

Een build die in je pipeline werkt, moet exact dezelfde zijn als die in productie draait. Geen last-minute aanpassingen op de server.

12. Backups en disaster recovery

Hoop op het beste, plan voor het slechtste.

• Automatiseer database backups en test restores regelmatig
• Documenteer je runbooks voor incidents
• Ken je RPO (Recovery Point Objective) en RTO (Recovery Time Objective)
• Test failover scenarios minimaal één keer per kwartaal

Een backup die je nooit getest hebt, is geen backup. Doe minstens één keer per kwartaal een echte restore-drill. Het Node.js officiële deployment advies kan je helpen met verdere best practices.

Samenvatting

Een production readiness checklist voor Node.js is geen eenmalige stap, maar een levend document. Je applicatie en team groeien, en je checklist moet meegroeien. Loop deze 12 punten door vóór elke grote release en je voorkomt de meest voorkomende productieproblemen.

Bouw je op een solide fundament met goede projectstructuur, grondige testing en robuuste error handling? Dan zijn deze checklist-punten eerder een formaliteit dan een stressmoment.

Veelgestelde vragen

Wat betekent production ready in Node.js?

Production ready betekent dat je Node.js applicatie stabiel, veilig, schaalbaar en observeerbaar is. Denk aan graceful shutdown, health checks, logging, monitoring, error handling en een werkend deploy- en rollbackproces.

Welke tools heb je minimaal nodig voor productie?

Minimaal heb je een process manager (zoals PM2 of systemd), een logaggregator, een monitoringsoplossing (zoals Datadog of Prometheus), een reverse proxy (nginx of een load balancer) en een CI/CD pipeline nodig voor veilige deploys.

Moet ik altijd clustering gebruiken in productie?

Niet per se. Voor CPU-intensieve apps op multi-core servers is clustering aan te raden, maar vaak laat je orchestration over aan Kubernetes of een load balancer. Begin met één worker en schaal horizontaal zodra de load dat vereist.

Hoe voorkom ik downtime tijdens deploys?

Gebruik zero-downtime deploys via een load balancer, rolling updates of blue-green deployments. Zorg voor graceful shutdown zodat lopende requests netjes afgerond worden en readiness probes nieuwe instances pas bevestigen als ze echt klaar zijn.

Wat is het verschil tussen liveness en readiness probes?

Een liveness probe controleert of je app nog leeft (crashloops detecteren). Een readiness probe checkt of je app klaar is om verkeer te ontvangen (bijvoorbeeld na DB-connect). Beide zijn belangrijk in Kubernetes en moderne orchestrators.