Node.js Lifecycle Under a Process Supervisor

A Node.js service has a lifecycle beyond its request handler. Startup includes loading configuration, creating required resources, and beginning to accept traffic. A process supervisor such as Passenger can manage application startup and replacement, but the application still needs to follow the hosting environment's listening contract and report startup failures clearly.

Initialization should separate essential dependencies from optional work. Configuration errors should fail visibly instead of leaving a process that appears alive but cannot serve requests. Slow initialization can delay readiness, while synchronous work in request handlers can block the event loop and increase latency for unrelated connections.

Graceful shutdown begins by stopping new work, then allowing active requests to finish within a bounded deadline. Long-lived WebSocket connections require an explicit policy because they may otherwise keep a process open indefinitely. Signal handling must reflect the supervisor's documented behavior; cleanup is not guaranteed after a forced termination.

Multiple worker processes do not share ordinary JavaScript memory. An in-memory counter, session, or connection registry belongs to one process unless an external coordination mechanism is used. Process replacement also discards that state, so durable data and cross-process coordination need a storage design separate from the Node.js process.

Supervision provides recovery and deployment convenience, not proof that an application is healthy. A running process may still have a blocked event loop or an unavailable dependency. Readiness checks, useful logs, bounded shutdown, and predictable startup make the boundary between the application and its supervisor easier to operate.