20. CI/CD & Production Servers

Why Local Development Servers Can't Be Used in Production

The node server.js or python app.py commands you use locally are fine for development, but catastrophically unsuitable for production:

• No auto-restart: If your code throws an unhandled error and crashes, the server dies. Users get connection refused errors until someone manually restarts it.
• Single core: Node.js runs on a single CPU core. A modern server has 8, 16, or 32 cores, all sitting idle.
• No logging: Console.log output disappears. When something breaks at 3am, you have zero visibility.
• Security exposure: Development servers often skip HTTPS, CORS, and other security configurations.

PM2 — Production Process Manager

PM2 is the standard process manager for Node.js in production. It solves all the problems above: it keeps your process alive, restarts on crash, utilizes all CPU cores, manages logs, and provides a monitoring dashboard.

GitHub Actions — Automated CI/CD

Every time you push code to GitHub, GitHub Actions can automatically run your tests, build your Docker image, and deploy to your server — all without manual steps. This is CI/CD. Here is a complete workflow file:

Cloud Deployment Platforms

Deployment platforms handle the infrastructure, letting you focus on your code:

Environment Variables in Production

Never commit sensitive values to your repository. Every cloud platform provides a way to set environment variables through their dashboard or CLI — these are injected into your container at runtime, completely separate from your code.

Nginx as a Reverse Proxy

If you deploy on a raw Linux server (like a DigitalOcean Droplet), you typically run your Node.js app on port 3000 and put Nginx in front of it on port 80/443. Nginx handles HTTPS termination, static file serving, load balancing, and request buffering — all much more efficiently than Node.js can on its own.