5. Configuring a Reverse Proxy with Nginx<\/span><\/h2>\nWhy You Need a Reverse Proxy<\/h3>\n
A reverse proxy sits between the internet and your Node.js application. It is not optional in production \u2014 it is essential. Here is what Nginx does for you:<\/p>\n
Enhanced Security: Your Node.js app never directly faces the internet. Nginx acts as the shield, hiding your backend from direct attacks such as DDoS, request flooding, and direct port scanning.<\/p>\n
SSL Termination: Nginx handles HTTPS encryption and decryption so your Node.js app does not have to \u2014 improving performance and simplifying your code.<\/p>\n
Load Balancing: Nginx can distribute traffic across multiple Node.js processes or servers, ensuring no single instance is overwhelmed.<\/p>\n
Gzip Compression: Nginx compresses responses before sending them to the browser, reducing bandwidth usage and improving page load speed significantly.<\/p>\n
Static File Serving: Nginx serves CSS, JS, image files, and other static assets directly \u2014 much faster than routing them through Node.js.<\/p>\n
Access Control: You can set rate limits, IP whitelists, and authentication rules at the Nginx level, before requests even reach your app.<\/p>\n
Installing and Configuring Nginx<\/p>\n
Create a new Nginx configuration file for your application:<\/p>\n
sudo nano \/etc\/nginx\/sites-available\/myapp<\/p>\n
Paste the following complete production-ready configuration:<\/p>\n
server {
listen 80;
server_name yourdomain.com www.yourdomain.com;<\/p>\n
# Security headers
add_header X-Frame-Options “SAMEORIGIN” always;
add_header X-Content-Type-Options “nosniff” always;
add_header X-XSS-Protection “1; mode=block” always;
add_header Referrer-Policy “no-referrer-when-downgrade” always;<\/p>\n
# Gzip compression
gzip on;
gzip_types text\/plain application\/json application\/javascript text\/css;<\/p>\n
location \/ {
proxy_pass http:\/\/localhost:3000;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection ‘upgrade’;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_cache_bypass $http_upgrade;
proxy_read_timeout 86400;
proxy_connect_timeout 60s;
}<\/p>\n
# Serve static files directly via Nginx (much faster)
location \/static\/ {
alias \/var\/www\/myapp\/public\/;
expires 30d;
add_header Cache-Control “public, immutable”;
}
}<\/p>\n
Replace yourdomain.com with your actual domain name.<\/p>\n
Enable the configuration by creating a symbolic link:<\/p>\n
sudo ln -s \/etc\/nginx\/sites-available\/myapp \/etc\/nginx\/sites-enabled\/<\/p>\n
Always test the configuration before reloading \u2014 a single typo will take your site offline:<\/p>\n
sudo nginx -t<\/p>\n
If you see “syntax is ok” and “test is successful”, reload Nginx:<\/p>\n
sudo systemctl reload nginx<\/p>\n
Use “reload” instead of “restart” \u2014 reload applies changes with zero downtime. Restart briefly stops and starts Nginx, causing a momentary outage.<\/p>\n
6. Securing Your Deployment<\/b><\/h2>\nSetting Up a Firewall with UFW<\/h3>\n
UFW (Uncomplicated Firewall) controls which ports are open on your server. Correct setup is critical.<\/p>\n
Set the default policies first \u2014 deny all incoming traffic, allow all outgoing:<\/p>\n
sudo ufw default deny incoming
sudo ufw default allow outgoing<\/p>\n
Allow SSH access (do this before enabling UFW, or you will lock yourself out):<\/p>\n
sudo ufw allow OpenSSH<\/p>\n
Allow HTTP and HTTPS through Nginx:<\/p>\n
sudo ufw allow ‘Nginx Full’<\/p>\n
Block direct access to your Node.js port \u2014 users must only reach your app through Nginx, never directly:<\/p>\n
sudo ufw deny 3000\/tcp<\/p>\n
Enable UFW and check the rules:<\/p>\n
sudo ufw enable
sudo ufw status verbose<\/p>\n
Securing with SSL \u2014 Let’s Encrypt and Certbot<\/h3>\n
Install Certbot using the official snap method (recommended in 2026 \u2014 the apt version is outdated):<\/p>\n
sudo snap install –classic certbot
sudo ln -s \/snap\/bin\/certbot \/usr\/bin\/certbot<\/p>\n
Obtain your SSL certificate for both your domain and www subdomain:<\/p>\n
sudo certbot –nginx -d yourdomain.com -d www.yourdomain.com<\/p>\n
Certbot automatically configures Nginx for HTTPS and sets up a systemd timer for auto-renewal. Verify the renewal timer is active:<\/p>\n
sudo systemctl status snap.certbot.renew.timer<\/p>\n
Test that auto-renewal works correctly:<\/p>\n
sudo certbot renew –dry-run<\/p>\n
After SSL is installed, check your security grade at ssllabs.com\/ssltest \u2014 you should achieve an A or A+ rating.<\/p>\n
Blocking Brute-Force Attacks with Fail2ban<\/h3>\n
Fail2ban monitors your server logs and automatically bans IP addresses that repeatedly fail SSH login attempts. It is essential for any internet-facing server.<\/p>\n
Install Fail2ban:<\/p>\n
sudo apt install fail2ban -y<\/p>\n
Create a local configuration file:<\/p>\n
sudo cp \/etc\/fail2ban\/jail.conf \/etc\/fail2ban\/jail.local
sudo nano \/etc\/fail2ban\/jail.local<\/p>\n
Find the [sshd] section and set these values:<\/p>\n
[sshd]
enabled = true
port = ssh
maxretry = 3
bantime = 3600
findtime = 600<\/p>\n
This bans any IP that fails SSH login 3 times within 10 minutes, for 1 hour.<\/p>\n
Enable and start Fail2ban:<\/strong><\/p>\nsudo systemctl enable fail2ban
sudo systemctl start fail2ban
sudo fail2ban-client status sshd<\/p>\n
Securing Your Node.js Application Code<\/h3>\n
Install Helmet.js \u2014 a security middleware that automatically sets 11 HTTP security headers in your Express.js app:<\/p>\n
npm install helmet
npm install express-rate-limit<\/p>\n
Add these to the top of your server.js or app.js, before any routes:<\/p>\n
const express = require(‘express’);
const helmet = require(‘helmet’);
const rateLimit = require(‘express-rate-limit’);<\/p>\n
const app = express();<\/p>\n
\/\/ Apply security headers
app.use(helmet());<\/p>\n
\/\/ Tell Express to trust the Nginx proxy
app.set(‘trust proxy’, 1);<\/p>\n
\/\/ Rate limiting \u2014 max 100 requests per 15 minutes per IP
const limiter = rateLimit({
windowMs: 15 * 60 * 1000,
max: 100
});
app.use(‘\/api\/’, limiter);<\/p>\n
Security Best Practices Checklist<\/h3>\n
\u2022 Store all secrets and credentials in .env \u2014 never hardcode them
\u2022 Add .env to .gitignore \u2014 never commit it to version control
\u2022 Run your app as a non-root user (PM2 handles this by default)
\u2022 Keep system packages updated: sudo apt update && sudo apt upgrade -y
\u2022 Review PM2 logs regularly for errors and unusual activity<\/p>\n
7. Automating Deployment with CI\/CD<\/span><\/h2>\nIntroduction to CI\/CD Pipelines<\/h3>\n
A CI\/CD pipeline (Continuous Integration \/ Continuous Deployment) automates the process of testing and deploying your code every time you push a change. Instead of manually SSHing into your server, pulling code, and restarting PM2, a pipeline does it all for you in under 60 seconds \u2014 and only deploys if your tests pass.<\/p>\n
How CI\/CD Works<\/h3>\n
Continuous Integration (CI)<\/strong>: Every time a developer pushes code to the repository, the pipeline automatically installs dependencies and runs the test suite. If any test fails, deployment is blocked. Bugs are caught before they reach production.<\/p>\nContinuous Deployment (CD)<\/strong>: If all tests pass, the pipeline SSHs into your production server, pulls the latest code, reinstalls dependencies, and reloads the app \u2014 with zero manual steps and zero downtime.<\/p>\nWhy It Matters<\/h3>\n
Speed: Deployment that took 15 minutes manually now takes under 60 seconds automatically.
Quality: Automated tests catch bugs before production. No more “it worked on my machine.”
Reliability: Every deployment follows the exact same steps \u2014 no human error, no forgotten commands.
Confidence: You can push code 10 times a day without fear.<\/p>\n
Using GitHub Actions<\/p>\n
In your project repository, create the following file:<\/p>\n
Path: .github\/workflows\/deploy.yml<\/p>\n
name: Deploy Node.js to Linux Server<\/p>\n
on:
push:
branches: [main]<\/p>\n
jobs:
test:
runs-on: ubuntu-latest
steps:
– uses: actions\/checkout@v4<\/p>\n
– name: Setup Node.js v22
uses: actions\/setup-node@v4
with:
node-version: ’22’
cache: ‘npm’<\/p>\n
– name: Install dependencies
run: npm ci<\/p>\n
– name: Run tests
run: npm test<\/p>\n
deploy:
runs-on: ubuntu-latest
needs: test
if: github.ref == ‘refs\/heads\/main’
steps:
– name: Deploy via SSH
uses: appleboy\/ssh-action@v1.0.3
with:
host: ${{ secrets.SERVER_HOST }}
username: ${{ secrets.SERVER_USER }}
key: ${{ secrets.SSH_PRIVATE_KEY }}
script: |
cd \/var\/www\/myapp
git pull origin main
npm ci –omit=dev
pm2 reload ecosystem.config.js –env production
pm2 save<\/p>\n
Setting Up GitHub Secrets<\/h3>\n
Your workflow references three secrets. You must add them to GitHub before the pipeline will work.<\/p>\n
Go to your GitHub repository \u2192 Settings \u2192 Secrets and Variables \u2192 Actions \u2192 New Repository Secret<\/p>\n
Add these three secrets:<\/p>\n
Secret name: SERVER_HOST
Value: Your server’s IP address (example: 203.0.113.42)<\/p>\n
Secret name: SERVER_USER
Value: Your Linux username (example: ubuntu or deploy)<\/p>\n
Secret name: SSH_PRIVATE_KEY
Value: The full contents of your private key file. To get it, run on your local machine:
cat ~\/.ssh\/id_ed25519<\/p>\n
Copy the entire output (including the —–BEGIN and —–END lines) and paste it as the secret value.<\/p>\n
Once these secrets are set, every push to your main branch will automatically test and deploy your application.<\/p>\n
8. Monitoring and Maintenance<\/span><\/h2>\nPM2 has built-in monitoring tools that give you real-time insight into your application’s health:<\/p>\n
\n\n\nCommand<\/strong><\/td>\nDescription<\/strong><\/td>\n<\/tr>\n<\/thead>\n\n\npm2 status<\/code><\/span><\/td>\nOverview of all running apps<\/span><\/td>\n<\/tr>\n\npm2 monit<\/code><\/span><\/td>\nReal-time CPU and memory dashboard<\/span><\/td>\n<\/tr>\n\npm2 logs myapp<\/code><\/span><\/td>\nLive log stream<\/span><\/td>\n<\/tr>\n\npm2 logs myapp --lines 200<\/code><\/span><\/td>\nView last 200 lines of logs<\/span><\/td>\n<\/tr>\n\npm2 describe myapp<\/code><\/span><\/td>\nFull process information<\/span><\/td>\n<\/tr>\n\npm2 flush<\/code><\/span><\/td>\nClear all log files<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nSetting Up Log Rotation<\/h3>\nWithout log rotation, PM2 log files will grow indefinitely and eventually fill your server’s disk, causing a crash. Install PM2’s official log rotation module:<\/p>\n pm2 install pm2-logrotate
pm2 set pm2-logrotate:max_size 10M
pm2 set pm2-logrotate:retain 7
pm2 set pm2-logrotate:compress true<\/p>\n This keeps a maximum of 7 rotated log files, each up to 10MB, compressed.<\/p>\n Setting Up Uptime Monitoring and Alerts<\/h3>\nUse these free tools to get alerted if your site goes down:<\/p>\n BetterStack (betterstack.com)<\/strong> \u2014 free tier with 3-minute check intervals, email and SMS alerts, and a status page. This is the most recommended uptime monitor in 2026.<\/p>\nUptimeRobot (uptimerobot.com)<\/strong> \u2014 free with 5-minute check intervals and email alerts. Good for personal projects.<\/p>\nFor application error tracking, use Sentry (sentry.io) \u2014 it captures unhandled exceptions in your Node.js app and sends alerts with a full stack trace and context.<\/p>\n Useful Server Health Commands<\/strong><\/p>\n\n\n\nCommand<\/strong><\/td>\nDescription<\/strong><\/td>\n<\/tr>\n<\/thead>\n\n\nhtop<\/code><\/span><\/td>\nCPU and memory usage<\/span><\/td>\n<\/tr>\n\ndf -h<\/code><\/span><\/td>\nDisk space usage<\/span><\/td>\n<\/tr>\n\nsudo ss -tlnp<\/code><\/span><\/td>\nCheck which ports are open<\/span><\/td>\n<\/tr>\n\nsudo tail -f \/var\/log\/nginx\/error.log<\/code><\/span><\/td>\nCheck Nginx error logs<\/span><\/td>\n<\/tr>\n\njournalctl --since \"1 hour ago\"<\/code><\/span><\/td>\nCheck system logs for the last hour<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nScaling Your Application<\/h3>\nVertical Scaling: Upgrade your server \u2014 add more CPU cores, RAM, or disk space through your cloud provider’s control panel. PM2 cluster mode will automatically use the new cores.<\/p>\n Horizontal Scaling: Run multiple servers behind a load balancer. Use Nginx upstream blocks to distribute traffic across server instances. This approach allows your application to serve millions of requests while maintaining zero downtime during deployments.<\/p>\n Zero-Downtime Reloads with PM2<\/h3>\nWhen deploying new code, always use “reload” instead of “restart”:<\/p>\n pm2 reload ecosystem.config.js –env production<\/p>\n PM2 reload restarts each worker process one at a time, so traffic is never interrupted. PM2 restart stops all processes simultaneously, causing a brief outage.<\/p>\n 9. Troubleshooting Common Issues<\/strong><\/h2>\nEven with a correct setup, you will occasionally encounter issues. Here are the most common problems and their exact fixes.<\/p>\n 502 Bad Gateway from Nginx<\/h3>\nThis means Nginx is running but your Node.js app is not, or is not listening on the expected port.<\/p>\n \n\n\nCommand<\/strong><\/td>\nDescription<\/strong><\/td>\n<\/tr>\n<\/thead>\n\n\npm2 status<\/code><\/span><\/td>\nCheck if the app is running<\/span><\/td>\n<\/tr>\n\npm2 logs myapp<\/code><\/span><\/td>\nLook for startup errors<\/span><\/td>\n<\/tr>\n\npm2 restart myapp<\/code><\/span><\/td>\n| Restart if it shows “stopped” or “errored”<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Also check your Nginx config \u2014 make sure “proxy_pass http:\/\/localhost:3000” matches the PORT in your .env file.<\/p>\n Port 3000 Already in Use<\/h3>\nIf you see “Error: listen EADDRINUSE :::3000”, another process is using your port.<\/p>\n \n\n\nCommand<\/strong><\/td>\nDescription<\/strong><\/td>\n<\/tr>\n<\/thead>\n\n\nsudo lsof -i :3000<\/code><\/span><\/td>\nFind what is using the port<\/span><\/td>\n<\/tr>\n\nkill -9 [PID]<\/code><\/span><\/td>\nKill that process (replace [PID]<\/code> with the number shown)<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nApp Crashes on Reboot<\/h3>\nYour PM2 process list was not saved, or the startup hook was not installed.<\/p>\n \n\n\nScenario \/ Step<\/strong><\/td>\nCommand<\/strong><\/td>\nDescription<\/strong><\/td>\n<\/tr>\n<\/thead>\n\n\n| Startup Setup<\/b><\/span><\/td>\n | pm2 startup systemd<\/code><\/span><\/td>\nGenerates a systemd startup command<\/span><\/td>\n<\/tr>\n\n| Startup Setup<\/b><\/span><\/td>\n | (Copy and run the output command)<\/i><\/span><\/td>\n | Configures PM2 to launch on system boot<\/span><\/td>\n<\/tr>\n\n| Startup Setup<\/b><\/span><\/td>\n | pm2 save<\/code><\/span><\/td>\nSaves the current process list for automatic restoration<\/span><\/td>\n<\/tr>\n\n| Package-Lock Sync Fix<\/b><\/span><\/td>\n | rm -rf node_modules package-lock.json<\/code><\/span><\/td>\nDeletes existing dependencies and the out-of-sync lockfile<\/span><\/td>\n<\/tr>\n\n| Package-Lock Sync Fix<\/b><\/span><\/td>\n | npm install<\/code><\/span><\/td>\nPerforms a clean install and regenerates the lockfile<\/span><\/td>\n<\/tr>\n\n| Package-Lock Sync Fix<\/b><\/span><\/td>\n | git add package-lock.json<\/code><\/span><\/td>\nStages the newly generated lockfile<\/span><\/td>\n<\/tr>\n\n| Package-Lock Sync Fix<\/b><\/span><\/td>\n | git commit -m \"Regenerate package-lock.json\"<\/code><\/span><\/td>\nCommits the changes to your repository<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nPermission Denied on npm Global Install (EACCES)<\/h3>\nThis happens when you use “sudo npm install -g” with NVM.<\/p>\n \n\n\nContext \/ Action<\/strong><\/td>\nCommand<\/strong><\/td>\nDescription<\/strong><\/td>\n<\/tr>\n<\/thead>\n\n\n| Fix Warning<\/b><\/span><\/td>\n | Never use sudo<\/code> with NVM-installed npm.<\/i><\/span><\/td>\n | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |