DEV Community: Yash

How to Run a Node.js App in Production with PM2 (Complete Guide)

Yash — Fri, 03 Apr 2026 07:37:45 +0000

How to Run a Node.js App in Production with PM2 (Complete Guide)

Most Node.js tutorials end at node server.js. That's fine for development. In production, you need process management: auto-restart, logging, monitoring, and zero-downtime deploys.

PM2 handles all of this.

Install PM2

npm install -g pm2

Basic Usage

# Start your app
pm2 start server.js --name my-app

# Start with specific Node version
pm2 start server.js --name my-app --interpreter /usr/bin/node

# List running processes
pm2 list

# Monitor live
pm2 monit

# View logs
pm2 logs my-app
pm2 logs my-app --lines 100

# Restart / reload (reload = zero downtime)
pm2 restart my-app
pm2 reload my-app

# Stop / delete
pm2 stop my-app
pm2 delete my-app

The ecosystem.config.js (Use This Always)

Running PM2 from the command line works, but an ecosystem config is more powerful and reproducible:

// ecosystem.config.js
module.exports = {
  apps: [{
    name: 'api',
    script: './src/server.js',

    // Process management
    instances: 'max',           // One per CPU core (cluster mode)
    exec_mode: 'cluster',       // Enable load balancing

    // Memory management
    max_memory_restart: '512M', // Restart if memory exceeds 512MB

    // Crash recovery
    min_uptime: '30s',          // Must stay up 30s to be considered healthy
    max_restarts: 10,           // Max restarts before giving up
    restart_delay: 4000,        // Wait 4s between restarts

    // Zero-downtime deploys
    wait_ready: true,           // Wait for process.send('ready')
    listen_timeout: 10000,      // 10s to emit ready signal
    kill_timeout: 5000,         // 5s to gracefully shut down

    // Logging
    log_file: '/var/log/pm2/api.log',
    out_file: '/var/log/pm2/api-out.log',
    error_file: '/var/log/pm2/api-error.log',
    log_date_format: 'YYYY-MM-DD HH:mm:ss',
    merge_logs: true,

    // Environment
    env: {
      NODE_ENV: 'development',
      PORT: 3000
    },
    env_production: {
      NODE_ENV: 'production',
      PORT: 3000
    }
  }]
};

# Start with production env
pm2 start ecosystem.config.js --env production

# Reload zero-downtime
pm2 reload ecosystem.config.js --env production

Survive Server Reboots

# Generate startup script (run as root or with sudo)
pm2 startup

# Follow the output — it gives you a command to run
# Example output:
# [PM2] To setup the Startup Script, copy/paste the following command:
# sudo env PATH=$PATH:/usr/bin /usr/lib/node_modules/pm2/bin/pm2 startup systemd -u ubuntu --hp /home/ubuntu

# Save current process list
pm2 save

# Verify it will restart
sudo systemctl status pm2-ubuntu  # (or your username)

Useful PM2 Commands

# Real-time dashboard
pm2 monit

# Show detailed process info
pm2 describe my-app

# Flush logs
pm2 flush my-app

# Rotate logs (set up log rotation)
pm2 install pm2-logrotate
pm2 set pm2-logrotate:max_size 50M
pm2 set pm2-logrotate:retain 7

# Reset restart count
pm2 reset my-app

# Scale up/down instances
pm2 scale my-app 4   # Set to 4 instances
pm2 scale my-app +2  # Add 2 more instances

Graceful Shutdown in Your App

// server.js
const server = app.listen(PORT, () => {
  if (process.send) process.send('ready'); // Signal PM2 we're ready
});

const shutdown = () => {
  server.close(() => {
    // Close DB connections, etc.
    process.exit(0);
  });
  // Force exit if graceful shutdown takes too long
  setTimeout(() => process.exit(1), 5000);
};

process.on('SIGTERM', shutdown);
process.on('SIGINT', shutdown);

I built ARIA to solve exactly this.
Try it free at step2dev.com — no credit card needed.

How to Set Up Log Aggregation for Multiple Servers (ELK Stack Basics)

Yash — Thu, 02 Apr 2026 17:00:24 +0000

How to Set Up Log Aggregation for Multiple Servers (ELK Stack Basics)

When you have one server, tail -f /var/log/app.log works fine. When you have three servers and something goes wrong, you need to search logs across all of them simultaneously.

That's what log aggregation solves.

The Lightweight Alternative First: Loki + Grafana

Before we go full ELK, consider Loki — it's significantly lighter and integrates with Grafana (which you may already have from monitoring):

# docker-compose.yml for Loki stack
version: '3.8'
services:
  loki:
    image: grafana/loki:2.9.0
    ports:
      - "3100:3100"
    volumes:
      - loki-data:/loki

  promtail:
    image: grafana/promtail:2.9.0
    volumes:
      - /var/log:/var/log:ro
      - ./promtail-config.yml:/etc/promtail/config.yml
    command: -config.file=/etc/promtail/config.yml

  grafana:
    image: grafana/grafana:latest
    ports:
      - "3000:3000"

volumes:
  loki-data:

# promtail-config.yml
server:
  http_listen_port: 9080

positions:
  filename: /tmp/positions.yaml

clients:
  - url: http://loki:3100/loki/api/v1/push

scrape_configs:
  - job_name: system
    static_configs:
      - targets:
          - localhost
        labels:
          job: varlogs
          host: server-1
          __path__: /var/log/*.log

  - job_name: app
    static_configs:
      - targets:
          - localhost
        labels:
          job: app
          host: server-1
          __path__: /var/log/myapp/*.log

ELK Stack Setup (More Powerful)

ELK = Elasticsearch + Logstash + Kibana

Install with Docker Compose

version: '3.8'
services:
  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:8.12.0
    environment:
      - discovery.type=single-node
      - xpack.security.enabled=false
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
    ports:
      - "9200:9200"
    volumes:
      - esdata:/usr/share/elasticsearch/data

  logstash:
    image: docker.elastic.co/logstash/logstash:8.12.0
    volumes:
      - ./logstash.conf:/usr/share/logstash/pipeline/logstash.conf
    ports:
      - "5044:5044"
    depends_on:
      - elasticsearch

  kibana:
    image: docker.elastic.co/kibana/kibana:8.12.0
    ports:
      - "5601:5601"
    environment:
      - ELASTICSEARCH_HOSTS=http://elasticsearch:9200
    depends_on:
      - elasticsearch

volumes:
  esdata:

Logstash Pipeline Config

# logstash.conf
input {
  beats {
    port => 5044
  }
}

filter {
  if [fields][app] == "nodejs" {
    json {
      source => "message"
    }
    date {
      match => ["timestamp", "ISO8601"]
    }
  }

  grok {
    match => { "message" => "%{COMBINEDAPACHELOG}" }
  }
}

output {
  elasticsearch {
    hosts => ["elasticsearch:9200"]
    index => "logs-%{+YYYY.MM.dd}"
  }
}

Install Filebeat on Each Server

# Install on each server you want to collect logs from
curl -L -O https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-8.12.0-amd64.deb
sudo dpkg -i filebeat-8.12.0-amd64.deb

sudo nano /etc/filebeat/filebeat.yml

filebeat.inputs:
  - type: log
    enabled: true
    paths:
      - /var/log/myapp/*.log
    fields:
      app: nodejs
      server: production-1

output.logstash:
  hosts: ["your-elk-server:5044"]

sudo systemctl enable filebeat
sudo systemctl start filebeat

What to Search for in Kibana

Once data is flowing, useful queries:

# All errors in last hour
level:error

# Errors from specific server
level:error AND server:production-1

# 5xx responses
response:>499

# Slow requests (>1000ms)
duration:>1000

I built ARIA to solve exactly this.
Try it free at step2dev.com — no credit card needed.

How to Set Up a Reverse Proxy with nginx for Multiple Apps on One Server

Yash — Thu, 02 Apr 2026 08:22:24 +0000

How to Set Up a Reverse Proxy with nginx for Multiple Apps on One Server

Running multiple apps on a single $5/month VPS? nginx can route traffic to each one based on the domain name.

Here's the complete setup.

The Architecture

Internet
    ↓
nginx (port 80/443)
    ├── app1.yourdomain.com  → localhost:3001
    ├── app2.yourdomain.com  → localhost:3002
    └── api.yourdomain.com   → localhost:8080

Each app runs on a different local port. nginx routes incoming requests to the right one.

Step 1: Install nginx

sudo apt update && sudo apt install nginx -y
sudo systemctl enable nginx
sudo systemctl start nginx

Step 2: Create Server Blocks

# Create config for each app
sudo nano /etc/nginx/sites-available/app1.yourdomain.com

server {
    listen 80;
    server_name app1.yourdomain.com;

    location / {
        proxy_pass http://127.0.0.1:3001;
        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;
    }
}

# Enable the site
sudo ln -s /etc/nginx/sites-available/app1.yourdomain.com /etc/nginx/sites-enabled/

# Repeat for app2
sudo nano /etc/nginx/sites-available/app2.yourdomain.com
sudo ln -s /etc/nginx/sites-available/app2.yourdomain.com /etc/nginx/sites-enabled/

# Test config
sudo nginx -t

# Reload
sudo systemctl reload nginx

Step 3: Add SSL with Certbot

sudo apt install certbot python3-certbot-nginx -y

# Get certs for all your domains at once
sudo certbot --nginx -d app1.yourdomain.com -d app2.yourdomain.com -d api.yourdomain.com

# Auto-renewal
sudo systemctl enable certbot.timer

Certbot automatically updates your nginx configs to handle HTTPS and redirect HTTP → HTTPS.

Step 4: Optimize the Shared nginx Config

sudo nano /etc/nginx/nginx.conf

Add inside the http {} block:

# Gzip compression (applies to all sites)
gzip on;
gzip_vary on;
gzip_min_length 1024;
gzip_types text/plain text/css text/xml application/json application/javascript application/xml+rss;

# Rate limiting zone (use in server blocks)
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

# Security headers (apply to all)
add_header X-Frame-Options DENY always;
add_header X-Content-Type-Options nosniff always;

# Logging
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log warn;

Step 5: Handle WebSockets (if needed)

location /socket.io/ {
    proxy_pass http://127.0.0.1:3001;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_read_timeout 86400;  # Keep connection alive for 24h
}

Useful nginx Commands

sudo nginx -t                    # Test config
sudo systemctl reload nginx      # Reload without downtime
sudo systemctl restart nginx     # Full restart
sudo nginx -T                    # Print full parsed config
sudo tail -f /var/log/nginx/error.log  # Watch errors live

I built ARIA to solve exactly this.
Try it free at step2dev.com — no credit card needed.

Terraform Basics: Manage Your Infrastructure as Code in 30 Minutes

Yash — Wed, 01 Apr 2026 17:55:19 +0000

Terraform Basics: Manage Your Infrastructure as Code in 30 Minutes

If you're still managing servers by clicking through cloud consoles — this is for you.

Terraform lets you define your entire infrastructure in code. Reproducible, version-controlled, reviewable.

Why Infrastructure as Code

Without IaC:

"I'm not sure what settings I used on the production server"
Can't recreate your setup if the server dies
No audit trail for infrastructure changes

With Terraform:

Your entire infra is a git repo
Recreate production in 10 minutes
Review infrastructure changes like code reviews

Install Terraform

# Mac
brew tap hashicorp/tap && brew install hashicorp/tap/terraform

# Ubuntu/Debian
wget -O- https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt update && sudo apt install terraform

terraform --version

Your First Terraform Config (DigitalOcean Droplet)

# main.tf
terraform {
  required_providers {
    digitalocean = {
      source  = "digitalocean/digitalocean"
      version = "~> 2.0"
    }
  }
}

provider "digitalocean" {
  token = var.do_token
}

variable "do_token" {
  description = "DigitalOcean API token"
  sensitive   = true
}

resource "digitalocean_droplet" "web" {
  name   = "web-server-1"
  region = "nyc3"
  size   = "s-1vcpu-1gb"
  image  = "ubuntu-22-04-x64"

  ssh_keys = [digitalocean_ssh_key.default.fingerprint]

  tags = ["web", "production"]
}

resource "digitalocean_ssh_key" "default" {
  name       = "my-key"
  public_key = file("~/.ssh/id_ed25519.pub")
}

output "droplet_ip" {
  value = digitalocean_droplet.web.ipv4_address
}

# Initialize (downloads provider plugins)
terraform init

# Preview what will be created
terraform plan

# Apply (creates the resources)
terraform apply

# Destroy when done
terraform destroy

State Management

Terraform tracks what it's created in a state file. For teams, store state remotely:

terraform {
  backend "s3" {
    bucket = "my-terraform-state"
    key    = "production/terraform.tfstate"
    region = "us-east-1"

    # Enable state locking
    dynamodb_table = "terraform-locks"
    encrypt        = true
  }
}

Practical Example: Full Stack (Droplet + Firewall + Domain)

resource "digitalocean_droplet" "app" {
  name   = "app-server"
  region = "nyc3"
  size   = "s-2vcpu-2gb"
  image  = "ubuntu-22-04-x64"
  ssh_keys = [digitalocean_ssh_key.default.fingerprint]
}

resource "digitalocean_firewall" "app" {
  name = "app-firewall"
  droplet_ids = [digitalocean_droplet.app.id]

  inbound_rule {
    protocol         = "tcp"
    port_range       = "22"
    source_addresses = ["YOUR_IP/32"]  # SSH only from your IP
  }

  inbound_rule {
    protocol         = "tcp"
    port_range       = "80"
    source_addresses = ["0.0.0.0/0", "::/0"]
  }

  inbound_rule {
    protocol         = "tcp"
    port_range       = "443"
    source_addresses = ["0.0.0.0/0", "::/0"]
  }

  outbound_rule {
    protocol              = "tcp"
    port_range            = "all"
    destination_addresses = ["0.0.0.0/0", "::/0"]
  }
}

resource "digitalocean_domain" "app" {
  name       = "yourdomain.com"
  ip_address = digitalocean_droplet.app.ipv4_address
}

Essential Terraform Commands

terraform init          # Initialize project
terraform plan          # Preview changes
terraform apply         # Apply changes
terraform destroy       # Destroy all resources
terraform show          # Show current state
terraform output        # Show outputs
terraform fmt           # Format .tf files
terraform validate      # Validate config syntax

I built ARIA to solve exactly this.
Try it free at step2dev.com — no credit card needed.

How to Debug Memory Leaks in Node.js Production Apps

Yash — Wed, 01 Apr 2026 07:50:07 +0000

How to Debug Memory Leaks in Node.js Production Apps

Your Node.js app works fine for hours, then slows to a crawl. Memory climbs steadily. A restart fixes it temporarily — then it happens again.

That's a memory leak. Here's how to find and fix it.

Confirm It's a Leak

# Watch RSS memory of your Node process over time
watch -n 30 'ps -o pid,rss,vsz,comm -p $(pgrep -f "node server")'

# Or log it from inside the app
setInterval(() => {
  const m = process.memoryUsage();
  console.log(JSON.stringify({
    rss: Math.round(m.rss / 1024 / 1024) + 'MB',
    heap: Math.round(m.heapUsed / 1024 / 1024) + 'MB',
    time: new Date().toISOString()
  }));
}, 60000);

If RSS grows steadily and never drops, you have a leak.

Step 1: Generate a Heap Snapshot

# Start Node with inspector
node --inspect server.js

# Or send signal to running process
kill -USR1 <PID>  # Opens inspector on port 9229

Then in Chrome: chrome://inspect → Open dedicated DevTools → Memory → Take heap snapshot.

Take a snapshot, do some actions, take another. Compare — look for objects accumulating.

Step 2: Use clinic.js (Easiest Method)

npm install -g clinic

# Profile your app under load
clinic heapprofile -- node server.js

# In another terminal, run load
npx autocannon -c 10 -d 60 http://localhost:3000/api/endpoint

# Ctrl+C clinic — it generates a flamegraph

The flamegraph shows where memory is being allocated. Tall bars = lots of allocation from that function.

Step 3: Common Leak Patterns

Pattern 1: Event Listener Accumulation

// Leak: adding listener every request without removing
app.get('/stream', (req, res) => {
  emitter.on('data', (chunk) => res.write(chunk)); // Never removed!
});

// Fix: remove listener on connection close
app.get('/stream', (req, res) => {
  const handler = (chunk) => res.write(chunk);
  emitter.on('data', handler);
  req.on('close', () => emitter.off('data', handler)); // Cleanup
});

Pattern 2: Global Cache Without Expiry

// Leak: cache grows forever
const cache = {};
app.get('/user/:id', async (req, res) => {
  if (!cache[req.params.id]) {
    cache[req.params.id] = await db.getUser(req.params.id);
  }
  res.json(cache[req.params.id]);
});

// Fix: use a proper cache with TTL
const NodeCache = require('node-cache');
const cache = new NodeCache({ stdTTL: 300, maxKeys: 1000 });

Pattern 3: Closures Holding References

// Leak: closure keeps large object alive
function processData(largeArray) {
  const summary = computeSummary(largeArray);
  return function getSummary() {
    return summary; // largeArray stays in memory via closure
  };
}

// Fix: only keep what you need
function processData(largeArray) {
  const summary = computeSummary(largeArray);
  largeArray = null; // Help GC
  return function getSummary() { return summary; };
}

Pattern 4: Uncleared Timers

// Leak: interval never cleared
function startMonitoring() {
  setInterval(() => {
    checkHealth();
  }, 5000); // No reference kept, can't clear it
}

// Fix: keep reference and clear on shutdown
let monitorInterval;
function startMonitoring() {
  monitorInterval = setInterval(() => checkHealth(), 5000);
}
process.on('SIGTERM', () => clearInterval(monitorInterval));

Step 4: Detect with Automated Testing

// Add to your test suite
const v8 = require('v8');

test('endpoint does not leak memory', async () => {
  global.gc(); // Force GC (run with --expose-gc)
  const before = v8.getHeapStatistics().used_heap_size;

  // Run the operation 100 times
  for (let i = 0; i < 100; i++) {
    await request(app).get('/api/users');
  }

  global.gc();
  const after = v8.getHeapStatistics().used_heap_size;

  const growthMB = (after - before) / 1024 / 1024;
  expect(growthMB).toBeLessThan(5); // Allow <5MB growth
});

I built ARIA to solve exactly this.
Try it free at step2dev.com — no credit card needed.

Docker Multi-Stage Builds: Cut Your Image Size by 80%

Yash — Tue, 31 Mar 2026 17:47:04 +0000

Docker Multi-Stage Builds: Cut Your Image Size by 80%

A Node.js app with a standard Dockerfile can easily produce an 800MB+ image. The same app with a multi-stage build: 80-120MB.

Here's how it works and how to implement it.

Why Images Get So Big

A typical Node.js Dockerfile:

FROM node:20
WORKDIR /app
COPY package*.json ./
RUN npm install    # Installs devDependencies too
COPY . .
RUN npm run build
CMD ["node", "dist/server.js"]

Problems:

node:20 base image is ~900MB
npm install includes all devDependencies (TypeScript, webpack, etc.)
Source files, test files, build tools all end up in the final image

The Multi-Stage Solution

# Stage 1: Build
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci                    # Install everything including devDeps
COPY . .
RUN npm run build             # Compile TypeScript, etc.

# Stage 2: Production
FROM node:20-alpine AS production
WORKDIR /app
ENV NODE_ENV=production

# Only copy what's needed for production
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/package*.json ./
RUN npm ci --only=production  # Only production deps
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser

EXPOSE 3000
CMD ["node", "dist/server.js"]

Result: 800MB → ~95MB

Python Multi-Stage Example

# Build stage
FROM python:3.12 AS builder
WORKDIR /app
COPY requirements.txt .
RUN pip install --user -r requirements.txt

# Production stage
FROM python:3.12-slim AS production
WORKDIR /app
COPY --from=builder /root/.local /root/.local
COPY . .
ENV PATH=/root/.local/bin:$PATH
CMD ["python", "main.py"]

python:3.12-slim is 45MB vs python:3.12 at 900MB+.

Go Multi-Stage Example

Go is the best case for multi-stage builds — you can produce a static binary with zero runtime dependencies:

# Build stage
FROM golang:1.22-alpine AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -o server .

# Final stage — scratch image (ZERO MB base)
FROM scratch
COPY --from=builder /app/server /server
EXPOSE 8080
CMD ["/server"]

A Go app in a scratch image can be as small as 5-10MB total.

How to Verify Size Reduction

# Build and compare
docker build -t myapp:single-stage -f Dockerfile.old .
docker build -t myapp:multi-stage -f Dockerfile.new .

docker images | grep myapp
# myapp   single-stage   ...   847MB
# myapp   multi-stage    ...    94MB

Layer Caching Best Practices

# Order by change frequency (least-changed first)
COPY package*.json ./          # Changes rarely
RUN npm ci                     # Cached until package.json changes
COPY src/ ./src/               # Changes often — at the end
RUN npm run build

# Inspect what's in your image
docker history myapp:multi-stage
docker run --rm myapp:multi-stage du -sh /app

I built ARIA to solve exactly this.
Try it free at step2dev.com — no credit card needed.

Building a Developer Tool in Public: 60 Days of Real Metrics

Yash — Tue, 31 Mar 2026 06:01:05 +0000

Building a Developer Tool in Public: 60 Days of Real Metrics

60 days since I launched ARIA publicly. Here's every metric I track and what it's telling me.

The Full 60-Day Dashboard

Metric	Day 1	Day 30	Day 60
MRR	$0	$84	$163
Signups	0	89	187
DAU	0	22	41
Paying customers	0	8	15
Organic SEO sessions	0	4,200	18,000
Articles published	0	21	42
Errors diagnosed	0	1,847	5,210
Avg session length	—	4.2 min	7.1 min
48h retention	—	31%	52%

What the Trends Are Telling Me

SEO is the channel that scales. Content compounding is real. Month 1 I wrote 21 articles. Month 2 I wrote 21 more. But month 2 SEO traffic was 4x month 1 — because month 1 articles were now ranking.

Session length increasing is a good sign. Average session went from 4.2 to 7.1 minutes. Users are staying longer, using more features, having deeper interactions with ARIA.

48h retention jump came from onboarding. The change I made in week 6 (get users to their first error diagnosis immediately) directly caused the retention jump from 31% to 52%.

What I'd Tell Someone Starting Today

Build the simplest thing that demonstrates core value. I spent too long on the repo scanner before the error diagnosis flow was good enough to retain users.
Content before launch, not after. Build an audience of the exact developers you're targeting while you build. When you launch, there are already people who care.
SEO is slow but compounding. First 2 weeks: nothing. Week 4: first trickle. Week 8: real traffic. Patience required.
Onboarding is more important than features. A user who can't find the value in 60 seconds is gone. No feature adds value if users don't see it.
Talk to every churned user. I've emailed every person who cancelled. 3 out of 3 gave me specific, actionable feedback. That's gold.

Month 3 Goals

MRR: $300
Product Hunt launch
Annual pricing live
Referral program live

Will report back on day 90.

I built ARIA to solve exactly this.
Try it free at step2dev.com — no credit card needed.

How to Set Up Automated Database Backups on Linux (PostgreSQL and MySQL)

Yash — Mon, 30 Mar 2026 19:08:19 +0000

How to Set Up Automated Database Backups on Linux (PostgreSQL and MySQL)

If your production database isn't being backed up automatically, you're one bad deploy away from losing everything.

This is how to set up automated backups that actually work.

PostgreSQL Automated Backup

The Backup Script

sudo nano /usr/local/bin/pg-backup.sh

#!/bin/bash
set -e

BACKUP_DIR="/var/backups/postgresql"
DATE=$(date +%Y%m%d_%H%M%S)
KEEP_DAYS=7
DB_NAME="${1:-all}"  # Pass db name or backs up all

mkdir -p "$BACKUP_DIR"

if [ "$DB_NAME" = "all" ]; then
    # Backup all databases
    pg_dumpall -U postgres | gzip > "$BACKUP_DIR/all_${DATE}.sql.gz"
else
    # Backup specific database
    pg_dump -U postgres -Fc "$DB_NAME" > "$BACKUP_DIR/${DB_NAME}_${DATE}.dump"
fi

# Remove backups older than KEEP_DAYS
find "$BACKUP_DIR" -type f -mtime +$KEEP_DAYS -delete

# Verify backup file exists and is not empty
LATEST=$(ls -t "$BACKUP_DIR" | head -1)
if [ ! -s "$BACKUP_DIR/$LATEST" ]; then
    echo "ERROR: Backup file is empty!" | mail -s "DB Backup FAILED" you@email.com
    exit 1
fi

echo "Backup successful: $BACKUP_DIR/$LATEST ($(du -h "$BACKUP_DIR/$LATEST" | cut -f1))"

chmod +x /usr/local/bin/pg-backup.sh

Set Up pg_hba.conf for Passwordless Local Backup

sudo nano /etc/postgresql/*/main/pg_hba.conf

Add (for local connections):

local   all             postgres                                trust

Or use a .pgpass file:

# ~/.pgpass
# hostname:port:database:username:password
localhost:5432:*:postgres:your_password
chmod 600 ~/.pgpass

Schedule with Cron

sudo crontab -e

# Daily backup at 2 AM
0 2 * * * /usr/local/bin/pg-backup.sh mydb >> /var/log/pg-backup.log 2>&1

# Weekly full backup on Sunday
0 1 * * 0 /usr/local/bin/pg-backup.sh all >> /var/log/pg-backup.log 2>&1

MySQL Automated Backup

sudo nano /usr/local/bin/mysql-backup.sh

#!/bin/bash
set -e

BACKUP_DIR="/var/backups/mysql"
DATE=$(date +%Y%m%d_%H%M%S)
KEEP_DAYS=7
MYSQL_USER="backup_user"
MYSQL_PASS="${MYSQL_BACKUP_PASSWORD}"  # Set as env var in cron

mkdir -p "$BACKUP_DIR"

# Get all databases
DATABASES=$(mysql -u "$MYSQL_USER" -p"$MYSQL_PASS" -e "SHOW DATABASES;" | grep -Ev "(Database|information_schema|performance_schema|sys)")

for DB in $DATABASES; do
    mysqldump -u "$MYSQL_USER" -p"$MYSQL_PASS"         --single-transaction         --routines         --triggers         "$DB" | gzip > "$BACKUP_DIR/${DB}_${DATE}.sql.gz"
    echo "Backed up: $DB"
done

find "$BACKUP_DIR" -type f -mtime +$KEEP_DAYS -delete
echo "Backup complete. Files in $BACKUP_DIR"

Create a dedicated backup user:

CREATE USER 'backup_user'@'localhost' IDENTIFIED BY 'strong_password';
GRANT SELECT, SHOW VIEW, TRIGGER, LOCK TABLES ON *.* TO 'backup_user'@'localhost';
FLUSH PRIVILEGES;

Off-Site Backup (Critical)

Local backups protect against mistakes. Off-site protects against server failure.

Sync to S3

# Install AWS CLI
sudo apt install awscli -y
aws configure  # Add your AWS credentials

# Add to backup script
aws s3 cp "$BACKUP_DIR/$LATEST" s3://your-backup-bucket/postgresql/

# Or sync entire directory
aws s3 sync "$BACKUP_DIR" s3://your-backup-bucket/postgresql/

Test Your Backups Monthly

# PostgreSQL restore test
pg_restore -U postgres -d test_restore_db /var/backups/postgresql/latest.dump

# MySQL restore test
gunzip -c /var/backups/mysql/mydb_latest.sql.gz | mysql -u root -p test_restore_db

A backup you've never tested is not a backup.

I built ARIA to solve exactly this.
Try it free at step2dev.com — no credit card needed.

SSH Hardening: How to Secure Your Server Against Brute Force Attacks

Yash — Mon, 30 Mar 2026 06:49:08 +0000

SSH Hardening: How to Secure Your Server Against Brute Force Attacks

If your server is publicly accessible, it's being attacked right now. SSH brute force is constant and automated.

Here's how to lock it down.

Check If You're Being Attacked

# See failed SSH login attempts
sudo journalctl -u sshd | grep "Failed password" | tail -20

# Or
sudo grep "Failed password" /var/log/auth.log | tail -20

# Count failed attempts by IP
sudo grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head -10

You'll probably see hundreds or thousands of failed attempts from random IPs. This is normal. Let's stop them from succeeding.

Step 1: Disable Password Authentication

sudo nano /etc/ssh/sshd_config

Set these:

PasswordAuthentication no
PermitRootLogin no
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
MaxAuthTries 3
LoginGraceTime 30

sudo systemctl restart sshd

Before doing this, make sure your SSH key is added to ~/.ssh/authorized_keys on the server.

Step 2: Install and Configure Fail2ban

sudo apt install fail2ban -y
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local

[DEFAULT]
bantime = 86400    # Ban for 24 hours
findtime = 3600    # In 1 hour window
maxretry = 3       # After 3 failures

[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 604800   # Ban SSH attackers for 7 days

sudo systemctl enable fail2ban
sudo systemctl start fail2ban

# Check banned IPs
sudo fail2ban-client status sshd

Step 3: Change the Default SSH Port (Optional but Effective)

This doesn't stop determined attackers but eliminates 95% of automated scans:

sudo nano /etc/ssh/sshd_config

Port 2222  # Or any port above 1024

# Update firewall before restarting SSH
sudo ufw allow 2222/tcp
sudo ufw delete allow ssh  # Remove default port
sudo systemctl restart sshd

Connect with: ssh -p 2222 user@your-server

Step 4: Use SSH Config File for Easy Access

# On your LOCAL machine
nano ~/.ssh/config

Host myserver
    HostName your-server-ip
    User deploy
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
    ServerAliveInterval 60

Now connect with just: ssh myserver

Step 5: Set Up an SSH Bastion Host (Advanced)

For production infrastructure with multiple servers, use a bastion host — a single hardened entry point:

Internet → Bastion host (public IP) → Internal servers (private IPs only)

# SSH through bastion to internal server
ssh -J user@bastion-ip user@internal-server-ip

# Or in ~/.ssh/config
Host internal-server
    HostName 10.0.0.5
    User deploy
    ProxyJump bastion-host

Quick Hardening Checklist

# 1. Verify key-based auth works (test before disabling password auth!)
ssh -i ~/.ssh/your_key user@server

# 2. Disable password auth
sudo sed -i 's/PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config

# 3. Disable root login
sudo sed -i 's/PermitRootLogin yes/PermitRootLogin no/' /etc/ssh/sshd_config

# 4. Restart SSH
sudo systemctl restart sshd

# 5. Install fail2ban
sudo apt install fail2ban -y && sudo systemctl enable fail2ban

# 6. Verify fail2ban is working
sudo fail2ban-client status

I built ARIA to solve exactly this.
Try it free at step2dev.com — no credit card needed.

How to Diagnose and Fix High RAM Usage on Linux Servers

Yash — Sun, 29 Mar 2026 17:53:06 +0000

How to Diagnose and Fix High RAM Usage on Linux Servers

Your server is slow and you think it's RAM. Or you got an alert saying memory is at 92%. Or your app is randomly crashing and you suspect a memory leak.

Here's the systematic approach.

Step 1: Check Overall Memory Usage

free -h

              total        used        free      shared  buff/cache   available
Mem:           3.8Gi       3.1Gi       142Mi       45Mi       612Mi       542Mi
Swap:          2.0Gi       1.4Gi       614Mi

Key numbers:

available: what's actually usable for new processes (not "free")
Swap used: if swap > 0, you're RAM-constrained. Swapping is ~100x slower than RAM.

If available < 10% of total and swap is active, you have a RAM problem.

Step 2: Find Which Process Is Using RAM

# Sort by memory usage
ps aux --sort=-%mem | head -20

# Or with more readable output
ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%mem | head -20

If you want live monitoring:

# top — press M to sort by memory
top

# htop (more readable, install if needed)
htop

Step 3: Investigate the Top Process

# Detailed memory breakdown for a specific PID
cat /proc/<PID>/status | grep -i mem

# Virtual vs resident memory
pmap -x <PID> | tail -1

For Node.js processes:

# Get V8 heap statistics
kill -USR2 <PID>  # Generates heap dump if --inspect is set

# Or add this to your app
setInterval(() => {
  const mem = process.memoryUsage();
  console.log(`RSS: ${Math.round(mem.rss/1024/1024)}MB, Heap: ${Math.round(mem.heapUsed/1024/1024)}MB`);
}, 60000);

Step 4: Check for Memory Leaks

Is RSS growing over time?

# Watch a process's memory over 10 minutes
for i in $(seq 1 10); do
  ps -o pid,rss,vsz -p <PID>
  sleep 60
done

If RSS grows consistently without dropping, you have a leak.

Node.js specific:

# Install clinic for leak detection
npm install -g clinic
clinic heapprofile -- node server.js

# Run load against your app for a few minutes, then Ctrl+C
# Clinic generates a flamegraph showing memory allocation

Step 5: Immediate Relief Options

# Drop page cache (safe — kernel re-reads from disk as needed)
sync && echo 1 | sudo tee /proc/sys/vm/drop_caches

# If a specific process is leaking, restart it
pm2 restart your-app
sudo systemctl restart your-service

# Add swap if you're out of options temporarily
sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Prevention: Set Memory Limits

# For systemd services
sudo systemctl edit your-service

[Service]
MemoryMax=512M
MemorySwapMax=0  # Prevent swap

# For Docker
docker run --memory=512m --memory-swap=512m your-image

# For PM2
pm2 start server.js --max-memory-restart 400M

I built ARIA to solve exactly this.
Try it free at step2dev.com — no credit card needed.

How to Monitor Docker Container Health and Auto-Restart on Failure

Yash — Sun, 29 Mar 2026 06:26:37 +0000

How to Monitor Docker Container Health and Auto-Restart on Failure

Your container is running but not actually working. It's accepting connections but returning 500s. Or it started but hasn't finished initializing.

Docker's built-in health checks handle all of this.

The Basic Health Check

FROM node:20-alpine

WORKDIR /app
COPY . .
RUN npm ci

# Health check: runs every 30s, fails after 3 attempts
HEALTHCHECK --interval=30s --timeout=10s --start-period=30s --retries=3   CMD curl -f http://localhost:3000/health || exit 1

CMD ["node", "server.js"]

Or in docker-compose.yml:

services:
  app:
    image: your-app
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3000/health"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 30s  # Grace period on startup

Check Container Health Status

# See health status
docker ps

# Detailed health info
docker inspect --format='{{json .State.Health}}' <container> | python3 -m json.tool

# Watch health checks in real time
watch -n 5 'docker inspect --format="{{.State.Health.Status}}" <container>'

Possible statuses: starting, healthy, unhealthy

The /health Endpoint (Node.js)

// Simple health endpoint
app.get('/health', (req, res) => {
  res.status(200).json({
    status: 'ok',
    uptime: process.uptime(),
    timestamp: new Date().toISOString()
  });
});

// With dependency checks
app.get('/health', async (req, res) => {
  const checks = {};

  try {
    await db.query('SELECT 1');
    checks.database = 'ok';
  } catch {
    checks.database = 'failed';
  }

  try {
    await redis.ping();
    checks.redis = 'ok';
  } catch {
    checks.redis = 'failed';
  }

  const allOk = Object.values(checks).every(v => v === 'ok');
  res.status(allOk ? 200 : 503).json({ status: allOk ? 'ok' : 'degraded', checks });
});

Auto-Restart on Unhealthy

services:
  app:
    image: your-app
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3000/health"]
      interval: 30s
      timeout: 10s
      retries: 3

With restart: unless-stopped, Docker automatically restarts an unhealthy container.

Alert on Unhealthy Containers

#!/bin/bash
# health-monitor.sh — run via cron every minute

for container in $(docker ps --format '{{.Names}}'); do
  STATUS=$(docker inspect --format='{{.State.Health.Status}}' "$container" 2>/dev/null)
  if [ "$STATUS" = "unhealthy" ]; then
    echo "UNHEALTHY: $container at $(date)" | mail -s "Container Unhealthy: $container" you@email.com
    # Optionally restart it
    # docker restart "$container"
  fi
done

chmod +x /usr/local/bin/health-monitor.sh
# Add to cron
* * * * * /usr/local/bin/health-monitor.sh

I built ARIA to solve exactly this.
Try it free at step2dev.com — no credit card needed.

5 DevOps Errors That Cost Developers the Most Time (And How to Fix Each)

Yash — Sat, 28 Mar 2026 15:23:00 +0000

5 DevOps Errors That Cost Developers the Most Time (And How to Fix Each)

After diagnosing 1,800+ errors through ARIA, I've noticed patterns. The same five categories of errors cost developers the most debugging time — not because they're complex, but because developers look in the wrong place.

Here's each one and the fastest path to a fix.

1. Disk Full (Silent App Killer)

Time lost on average: 45-90 minutes

Why it's hard: Apps crash without disk-related errors. You see a generic crash, a failed write, or a database refusing connections — not "disk full."

The fix:

df -h                              # Check disk usage
du -sh /var/log/* | sort -rh | head -10  # Find what's using space
sudo journalctl --vacuum-time=14d  # Clear old system logs
docker system prune -f             # Clear unused Docker data
find /tmp -mtime +7 -delete        # Clear old temp files

Prevention: Add a daily cron that alerts you when disk > 80%.

2. Environment Variable Missing in Production

Time lost on average: 30-60 minutes

Why it's hard: The error is usually not "env var missing." It's a downstream failure — database connection refused, API call failing with auth error, app crashing on startup.

The fix:

# Compare what your app expects vs what's in production
cat .env.example | grep -v '^#' | grep '=' | cut -d= -f1 | sort > /tmp/expected.txt
printenv | cut -d= -f1 | sort > /tmp/actual.txt
diff /tmp/expected.txt /tmp/actual.txt

Prevention: Use .env.example as your source of truth. Run the diff above before every production deploy.

3. Database Connection Refused After Config Change

Time lost on average: 60-120 minutes

Why it's hard: A server update, a package upgrade, or a misconfigured connection pool can break database connectivity without changing your app code.

The fix:

# Is the DB service running?
sudo systemctl status postgresql
ss -tlnp | grep 5432

# Can you connect directly?
psql -h localhost -U youruser -d yourdb

# Check pg_hba.conf for auth issues
sudo tail -20 /etc/postgresql/*/main/pg_hba.conf
sudo tail -50 /var/log/postgresql/*.log

4. Memory Leak Causing Gradual Slowdown

Time lost on average: 2-4 hours

Why it's hard: It's not a crash. It's a slow degradation over hours or days. By the time you investigate, the process has been running for hours and the memory usage graph requires context to interpret.

The fix:

# Track memory usage over time
while true; do
  ps -o pid,vsz,rss,comm -p $(pgrep node) >> /tmp/memory_log.txt
  sleep 60
done

# For Node.js — generate a heap snapshot
kill -USR2 <PID>  # Generates heapdump if using --inspect

# Or use clinic.js
npx clinic doctor -- node server.js

5. CI/CD Passes But Production Fails

Time lost on average: 45-90 minutes

Why it's hard: Your tests pass. Your staging looks fine. Production breaks. The cause is almost always an environment difference.

The fix:

# Compare env vars between staging and production
# On staging:
printenv | sort > /tmp/staging_env.txt

# On production:
printenv | sort > /tmp/prod_env.txt

# Compare
diff /tmp/staging_env.txt /tmp/prod_env.txt

# Check if production has different Node/Python version
node --version
python3 --version

Common causes: different Node versions, missing production secrets, different database connection limits, missing system packages.

The pattern across all five: the error message points to a symptom, not the cause. The fix requires knowing where to look.

I built ARIA to solve exactly this.
Try it free at step2dev.com — no credit card needed.