NGINX and PM2 for Node.js

From mental model to working change

Good work on NGINX and PM2 for Node.js leaves evidence: a visible behavior, a stable contract or a repeatable operational check. This lesson controls how a working change survives machines, environments, traffic and failure after it leaves a developer laptop.

Here, that decision supports a specific checkpoint: Package CourseFlow for a second CI platform, deploy it behind a reverse proxy, and write the evidence needed to operate or roll it back. A reviewable result should include a command transcript, CI result, deployment check and rollback note rather than a claim that the feature simply works.

A practical model for nginx and pm2 for node.js

Run a Node.js process behind a reverse proxy with explicit forwarding, timeouts, health checks and graceful shutdown. The useful unit of understanding is the boundary: who owns the decision, which input crosses it, what result is visible and how a failure is reported.

• Reverse Proxy: Locate this responsibility in CourseFlow and defend the boundary you chose.
• Process Supervision: Implement one behavior that another learner can reproduce without reading your mind.
• Forwarded Headers: Compare the simplest correct approach with one credible alternative.
• Graceful Shutdown: State the assumption this concept relies on and show how the system behaves when it is false.

Engineering decisions for NGINX and PM2 for Node.js

These are the details that separate a working demonstration from a maintainable production decision.

• Restrict direct access to the application port and configure the framework's trusted-proxy boundary precisely.
• Process supervision restarts crashes; it does not replace error monitoring, capacity limits or a safe deployment plan.
• Terminate requests and close database connections gracefully before the supervisor's kill timeout.

Follow the data through the example

The sample is intentionally narrow. Its job is to expose reverse proxy without hiding the decision behind unrelated setup.

server {
  listen 443 ssl;
  server_name api.example.test;

  location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_read_timeout 30s;
  }
}

Ship a reviewable increment

1. 1
   Reverse Proxy

   Name the caller and the owner of this behavior before changing the implementation.

2. 2
   Process Supervision

   Compare expected and actual output before editing; the difference tells you where to investigate.

3. 3
   Forwarded Headers

   Keep names tied to the product rule so a reviewer can follow the change without decoding abbreviations.

4. 4
   Graceful Shutdown

   Add a regression check close to the boundary where this behavior can fail.

Check your reasoning

What to carry into the next lesson

• Run a Node.js process behind a reverse proxy with explicit forwarding, timeouts, health checks and graceful shutdown.
• Keep reverse proxy visible at the boundary where it can be tested.
• Use evidence from process supervision before widening the implementation.

References and related reading

• NGINX documentation
• PM2 documentation