Node.js is excellent for building APIs, real-time applications, and server-side tooling. But the patterns that work for prototypes and side projects break down in production. Unhandled promise rejections crash processes, memory leaks accumulate silently, and poorly structured error handling makes debugging a nightmare. Here are the practices we follow at Born Digital to keep Node.js applications reliable in production.
Error Handling That Actually Works
The most common production failure in Node.js applications is unhandled errors crashing the process. Always handle promise rejections — either with try/catch in async functions or with .catch() on promise chains. Register global handlers for unhandledRejection and uncaughtException as safety nets, but treat their invocation as bugs to fix rather than expected behaviour.
Structure your error handling in layers:
- Operational errors: Expected failures like invalid user input, network timeouts, or database connection issues. Handle these gracefully with meaningful error responses and retry logic where appropriate.
- Programmer errors: Bugs like null reference access, type errors, or assertion failures. These should crash the process and be caught by your process manager, which restarts the application.
- Custom error classes: Create specific error classes (NotFoundError, ValidationError, AuthenticationError) that carry HTTP status codes and structured details. This makes error handling in middleware consistent and informative.
Security Essentials
Never run Node.js as root. Validate and sanitise all input — use libraries like Joi or Zod for schema validation. Set security headers using Helmet middleware. Rate-limit your endpoints to prevent abuse, especially authentication routes. Keep dependencies updated and audit them regularly with npm audit or Snyk.
Store secrets in environment variables, never in code or configuration files committed to version control. Use a secrets manager (AWS Secrets Manager, HashiCorp Vault, or Doppler) for production environments. Rotate secrets regularly and implement logging that captures access patterns without logging sensitive data itself.
Performance and Memory Management
Node.js runs on a single thread. CPU-intensive operations block the event loop, making your application unresponsive to all other requests. Offload heavy computation to worker threads or separate services. Use streaming for large data transfers rather than buffering entire payloads in memory. Monitor event loop lag — if it consistently exceeds 100ms, you have a blocking problem.
Memory leaks are insidious in long-running Node.js processes. Common causes include growing arrays or maps used as caches without eviction policies, event listeners that are added but never removed, and closures that retain references to large objects. Monitor heap usage over time — a steadily climbing baseline indicates a leak. Tools like clinic.js and the Node.js inspector make heap snapshots and leak detection accessible.
Structured Logging
Console.log is not a logging strategy. Use a structured logging library like Pino (fastest) or Winston (most popular) that outputs JSON-formatted logs with consistent fields: timestamp, log level, request ID, and contextual data. This structure enables log aggregation and search in tools like Datadog, Elastic, or CloudWatch.
Include correlation IDs (request IDs) in every log entry so you can trace a single request through your entire application stack. Pass the request ID through middleware and make it available to all downstream functions. When debugging production issues, being able to filter logs by a single request ID saves hours.
Process Management and Deployment
Use a process manager to keep your application running. In containerised environments, Docker handles process lifecycle. For bare-metal or VM deployments, PM2 provides clustering, zero-downtime reloads, and process monitoring. Run your application in cluster mode to utilise all available CPU cores — Node.js's built-in cluster module or PM2's cluster mode forks your application across cores automatically.
Implement graceful shutdown: when receiving SIGTERM, stop accepting new connections, finish processing in-flight requests, close database connections and message queues, then exit cleanly. This prevents request failures during deployments and container restarts. At Born Digital, we treat these practices as non-negotiable for any Node.js application heading to production. The investment in proper error handling, security, and observability pays dividends in reduced downtime and faster incident resolution.