Deployment & Hosting Strategies — จาก Code สู่ Production 🚀Deployment & Hosting Strategies — From Code to Production 🚀

# 1. Install CLI
npm i -g vercel

# 2. Deploy (ครั้งแรก)
cd my-next-app
vercel
# → ตอบคำถาม → ได้ preview URL ทันที

# 3. Deploy production
vercel --prod
# → ได้ URL: my-next-app.vercel.app

# หรือ... แค่ push to GitHub
# Vercel auto-deploy ทุก push ให้เลย 🎉

{
  "framework": "nextjs",
  "buildCommand": "npm run build",
  "outputDirectory": ".next",
  "regions": ["sin1"],
  "headers": [
    {
      "source": "/api/(.*)",
      "headers": [
        { "key": "Cache-Control", "value": "no-store" }
      ]
    },
    {
      "source": "/(.*)",
      "headers": [
        { "key": "X-Frame-Options", "value": "DENY" },
        { "key": "X-Content-Type-Options", "value": "nosniff" }
      ]
    }
  ],
  "rewrites": [
    { "source": "/api/:path*", "destination": "/api/:path*" }
  ],
  "redirects": [
    { "source": "/old-page", "destination": "/new-page", "permanent": true }
  ]
}

# Install CLI
npm i -g @railway/cli

# Login
railway login

# Init project
railway init

# Add Postgres
railway add --database postgres

# Deploy
railway up

# ได้ URL: my-app.up.railway.app 🎉

# Install
curl -L https://fly.io/install.sh | sh

# Login
fly auth login

# Launch (สร้าง fly.toml อัตโนมัติ)
fly launch

# Deploy
fly deploy

# Scale ไปหลาย region
fly regions add sin nrt
fly scale count 2

# ดู status
fly status

# fly.toml
app = "my-api"
primary_region = "sin"

[build]
  dockerfile = "Dockerfile"

[env]
  NODE_ENV = "production"
  PORT = "3000"

[http_service]
  internal_port = 3000
  force_https = true
  auto_stop_machines = true
  auto_start_machines = true
  min_machines_running = 1

[[vm]]
  cpu_kind = "shared"
  cpus = 1
  memory_mb = 256

# === Step 1: เข้า server ===
ssh root@your-server-ip

# === Step 2: Security basics ===
# สร้าง user ใหม่ (อย่าใช้ root!)
adduser deploy
usermod -aG sudo deploy

# Setup SSH key
mkdir -p /home/deploy/.ssh
cp ~/.ssh/authorized_keys /home/deploy/.ssh/
chown -R deploy:deploy /home/deploy/.ssh

# ปิด password login + root login
sudo nano /etc/ssh/sshd_config
# PermitRootLogin no
# PasswordAuthentication no
sudo systemctl restart sshd

# === Step 3: Firewall ===
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status

# === Step 4: Install Docker ===
curl -fsSL https://get.docker.com | sh
sudo usermod -aG docker deploy

# === Step 5: Deploy with Docker Compose ===

# docker-compose.yml
version: "3.8"

services:
  app:
    image: my-app:latest
    build: .
    restart: unless-stopped
    environment:
      - NODE_ENV=production
      - DATABASE_URL=postgresql://user:pass@db:5432/mydb
    ports:
      - "3000:3000"
    depends_on:
      - db
      - redis

  db:
    image: postgres:16-alpine
    restart: unless-stopped
    volumes:
      - pgdata:/var/lib/postgresql/data
    environment:
      - POSTGRES_USER=user
      - POSTGRES_PASSWORD=securepassword
      - POSTGRES_DB=mydb

  redis:
    image: redis:7-alpine
    restart: unless-stopped

volumes:
  pgdata:

# Deploy!
docker compose up -d

# Update (zero-downtime)
docker compose pull
docker compose up -d --no-deps --build app

# /etc/nginx/sites-available/myapp

# Redirect HTTP → HTTPS
server {
    listen 80;
    server_name myapp.com www.myapp.com;
    return 301 https://$server_name$request_uri;
}

# Main HTTPS server
server {
    listen 443 ssl http2;
    server_name myapp.com www.myapp.com;

    # SSL (managed by certbot)
    ssl_certificate /etc/letsencrypt/live/myapp.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/myapp.com/privkey.pem;

    # 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 Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

    # Gzip compression
    gzip on;
    gzip_vary on;
    gzip_min_length 1024;
    gzip_types text/plain text/css application/json application/javascript
               text/xml application/xml text/javascript image/svg+xml;

    # Static files (serve directly, bypass app)
    location /static/ {
        alias /var/www/myapp/static/;
        expires 30d;
        add_header Cache-Control "public, immutable";
    }

    # API / App (proxy to Node.js)
    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;

        # Timeouts
        proxy_connect_timeout 60s;
        proxy_send_timeout 60s;
        proxy_read_timeout 60s;
    }

    # Rate limiting for API
    location /api/ {
        limit_req zone=api burst=20 nodelay;
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    # Health check
    location /health {
        access_log off;
        proxy_pass http://localhost:3000/health;
    }
}

# Rate limit zone (ใส่ใน http block)
# limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

# Caddyfile — แค่นี้จริงๆ!

myapp.com {
    # HTTPS จัดการให้อัตโนมัติ — ไม่ต้องทำอะไร!

    # Proxy to app
    reverse_proxy localhost:3000

    # Static files
    handle_path /static/* {
        root * /var/www/myapp/static
        file_server {
            precompressed gzip br
        }
    }

    # Compression
    encode gzip zstd

    # Security headers
    header {
        X-Frame-Options "SAMEORIGIN"
        X-Content-Type-Options "nosniff"
        Strict-Transport-Security "max-age=31536000; includeSubDomains"
    }

    # Rate limiting
    rate_limit {
        zone api {
            key {remote_host}
            events 10
            window 1s
        }
    }

    # Logs
    log {
        output file /var/log/caddy/myapp.log
        format json
    }
}

# Multiple sites? แค่เพิ่ม block!
api.myapp.com {
    reverse_proxy localhost:4000
}

staging.myapp.com {
    reverse_proxy localhost:5000
}

# Nginx: ต้องทำ 5 ขั้นตอน
sudo apt install nginx certbot python3-certbot-nginx
sudo certbot --nginx -d myapp.com -d www.myapp.com
sudo nginx -t
sudo systemctl reload nginx
# + ตั้ง cron renew certificate

# Caddy: ขั้นตอนเดียว
sudo apt install caddy
sudo nano /etc/caddy/Caddyfile  # ใส่ config ข้างบน
sudo systemctl reload caddy
# HTTPS จัดการให้อัตโนมัติ ✅

# Install certbot
sudo apt install certbot python3-certbot-nginx

# Get certificate (ถ้าใช้ Nginx)
sudo certbot --nginx -d myapp.com -d www.myapp.com
# → ตอบคำถาม → ได้ cert อัตโนมัติ!

# Auto-renew (certbot ตั้งให้แล้ว)
sudo certbot renew --dry-run

# Check cert status
sudo certbot certificates

# Manual renew
sudo certbot renew
sudo systemctl reload nginx

# Nginx — Cache Control headers

# Static assets (images, CSS, JS) — cache นาน
location ~* \.(jpg|jpeg|png|gif|ico|css|js|woff2)$ {
    expires 365d;
    add_header Cache-Control "public, immutable";
}

# HTML — ไม่ cache (ให้ได้ content ใหม่เสมอ)
location ~* \.html$ {
    add_header Cache-Control "no-cache, must-revalidate";
}

# API — ไม่ cache เด็ดขาด
location /api/ {
    add_header Cache-Control "no-store, no-cache";
}

เหมือนเปลี่ยนยางรถ... ทีละล้อ

เริ่มต้น: [v1] [v1] [v1] [v1]  ← 4 instances, all v1

Step 1:  [v2] [v1] [v1] [v1]  ← update 1st instance
         ↑ ตรวจ health check → ✅ ผ่าน → ไปต่อ

Step 2:  [v2] [v2] [v1] [v1]  ← update 2nd instance
         ↑ ตรวจ health check → ✅ ผ่าน → ไปต่อ

Step 3:  [v2] [v2] [v2] [v1]  ← update 3rd instance

Step 4:  [v2] [v2] [v2] [v2]  ← done! 🎉

❌ ถ้า Step 2 fail?
Step 2:  [v2] [v2] [v1] [v1]  ← v2 #2 health check ❌
         → Stop! Rollback v2 #1 and #2 → [v1] [v1] [v1] [v1]

✅ Pros: ง่าย, ใช้ resource เท่าเดิม
❌ Cons: ระหว่าง deploy มี 2 versions วิ่งพร้อมกัน

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1          # สร้าง pod ใหม่เพิ่มได้ 1 ตัว
      maxUnavailable: 0     # ห้ามมี pod ลดลง (zero-downtime)
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: myapp
          image: myapp:v2
          ports:
            - containerPort: 3000

          # Health checks — สำคัญมาก!
          readinessProbe:
            httpGet:
              path: /health
              port: 3000
            initialDelaySeconds: 5
            periodSeconds: 5

          livenessProbe:
            httpGet:
              path: /health
              port: 3000
            initialDelaySeconds: 15
            periodSeconds: 10

          resources:
            requests:
              memory: "128Mi"
              cpu: "100m"
            limits:
              memory: "256Mi"
              cpu: "500m"

# Deploy
kubectl apply -f deployment.yaml

# ดู rollout status
kubectl rollout status deployment/myapp

# Rollback ถ้ามีปัญหา
kubectl rollout undo deployment/myapp

# ดู history
kubectl rollout history deployment/myapp

# .github/workflows/deploy.yml
name: Deploy to Production

on:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20

      - name: Install & Test
        run: |
          npm ci
          npm run lint
          npm test

  deploy:
    needs: test
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'

    steps:
      - uses: actions/checkout@v4

      - name: Deploy to VPS
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: deploy
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: |
            cd /home/deploy/myapp
            git pull origin main
            docker compose pull
            docker compose up -d --build --no-deps app
            docker image prune -f

      - name: Health Check
        run: |
          sleep 10
          curl -f https://myapp.com/health || exit 1

      - name: Notify on Failure
        if: failure()
        run: |
          curl -X POST "${{ secrets.SLACK_WEBHOOK }}" \
            -H 'Content-type: application/json' \
            -d '{"text":"❌ Deploy failed! Check GitHub Actions."}'

#!/bin/bash
# backup.sh — run daily via cron

set -euo pipefail

BACKUP_DIR="/home/deploy/backups"
DATE=$(date +%Y-%m-%d_%H%M)
RETENTION_DAYS=7

# Backup PostgreSQL
docker exec postgres pg_dump -U user mydb | gzip > "$BACKUP_DIR/db_${DATE}.sql.gz"

# Backup app data
tar czf "$BACKUP_DIR/data_${DATE}.tar.gz" /home/deploy/myapp/data/

# Upload to Backblaze B2 (cheap!)
rclone copy "$BACKUP_DIR/db_${DATE}.sql.gz" b2:my-backups/db/
rclone copy "$BACKUP_DIR/data_${DATE}.tar.gz" b2:my-backups/data/

# Cleanup old backups
find "$BACKUP_DIR" -name "*.gz" -mtime +$RETENTION_DAYS -delete

echo "✅ Backup completed: $DATE"

# Cron job (daily at 3 AM)
crontab -e
0 3 * * * /home/deploy/backup.sh >> /var/log/backup.log 2>&1

# Uptime Kuma — self-hosted uptime monitor
# (ฟรี, สวย, alert ได้)

docker run -d \
  --name uptime-kuma \
  --restart unless-stopped \
  -p 3001:3001 \
  -v uptime-kuma:/app/data \
  louislam/uptime-kuma:1

# → เข้า http://your-server:3001
# → เพิ่ม monitors:
#   - HTTPS: myapp.com (check every 60s)
#   - TCP: db server port 5432
#   - Docker container health
# → ตั้ง alert: Telegram, Slack, Discord, Email

// Express.js health check
app.get('/health', async (req, res) => {
  const health = {
    status: 'ok',
    timestamp: new Date().toISOString(),
    uptime: process.uptime(),
    checks: {}
  };

  // Check database
  try {
    await db.query('SELECT 1');
    health.checks.database = 'ok';
  } catch (err) {
    health.status = 'degraded';
    health.checks.database = 'error';
  }

  // Check Redis
  try {
    await redis.ping();
    health.checks.redis = 'ok';
  } catch (err) {
    health.status = 'degraded';
    health.checks.redis = 'error';
  }

  // Check disk space
  const diskFree = getDiskFreePercent();
  health.checks.disk = diskFree > 10 ? 'ok' : 'warning';

  const statusCode = health.status === 'ok' ? 200 : 503;
  res.status(statusCode).json(health);
});

🐕 The Code Is Finished... So Where Does It Go?

Sample code:

---

📊 Hosting Options — Every Kind Compared

Sample code:

---

1️⃣ Static Hosting — Vercel / Netlify / Cloudflare Pages

Why Is It Free?

Sample code:

Vercel vs Netlify vs Cloudflare Pages

This table makes it very quick to see that each platform is strong in a different direction: Vercel suits Next.js, Netlify is the easy one for small teams, and Cloudflare Pages leads on edge presence and bandwidth cost.

Run these commands to deploy:

Deploying on Vercel — Just Three Steps

Run these commands to deploy:

# 1. Install CLI
npm i -g vercel

# 2. Deploy (first time)
cd my-next-app
vercel
# → answer the prompts → a preview URL straight away

# 3. Deploy production
vercel --prod
# → you get the URL: my-next-app.vercel.app

# Or... just push to GitHub
# Vercel auto-deploys on every push for you 🎉

Vercel Project Config (vercel.json)

Sample code:

{
  "framework": "nextjs",
  "buildCommand": "npm run build",
  "outputDirectory": ".next",
  "regions": ["sin1"],
  "headers": [
    {
      "source": "/api/(.*)",
      "headers": [
        { "key": "Cache-Control", "value": "no-store" }
      ]
    },
    {
      "source": "/(.*)",
      "headers": [
        { "key": "X-Frame-Options", "value": "DENY" },
        { "key": "X-Content-Type-Options", "value": "nosniff" }
      ]
    }
  ],
  "rewrites": [
    { "source": "/api/:path*", "destination": "/api/:path*" }
  ],
  "redirects": [
    { "source": "/old-page", "destination": "/new-page", "permanent": true }
  ]
}

---

2️⃣ PaaS — Railway / Render / Fly.io

When You Need a Backend + Database

Run these commands to deploy:

The Popular PaaS Platforms Compared

If you are starting an MVP, this table is the main decision point: look at the free tier, the regions, and how convenient DB and cron are before you choose, so you do not have to change platforms too soon.

Sample code:

Deploying with Railway

Run these commands to deploy:

# Install CLI
npm i -g @railway/cli

# Login
railway login

# Init project
railway init

# Add Postgres
railway add --database postgres

# Deploy
railway up

# You get the URL: my-app.up.railway.app 🎉

Fly.io — Deploy as Close to the User as Possible

Run these commands to deploy:

# Install
curl -L https://fly.io/install.sh | sh

# Login
fly auth login

# Launch (creates fly.toml automatically)
fly launch

# Deploy
fly deploy

# Scale out to several regions
fly regions add sin nrt
fly scale count 2

# Check status
fly status

Sample code:

# fly.toml
app = "my-api"
primary_region = "sin"

[build]
  dockerfile = "Dockerfile"

[env]
  NODE_ENV = "production"
  PORT = "3000"

[http_service]
  internal_port = 3000
  force_https = true
  auto_stop_machines = true
  auto_start_machines = true
  min_machines_running = 1

[[vm]]
  cpu_kind = "shared"
  cpus = 1
  memory_mb = 256

---

3️⃣ VPS — Virtual Private Server

Why Do People Still Use a VPS?

Sample code:

VPS Providers Compared on Price (2025)

This section is for anyone who wants to run the system themselves and optimize cost over the long run — especially once traffic has settled and predictable performance matters.

Sample code:

VPS Setup — From Zero to Production

The configuration file looks like this:

# === Step 1: get into the server ===
ssh root@your-server-ip

# === Step 2: Security basics ===
# Create a new user (do not use root!)
adduser deploy
usermod -aG sudo deploy

# Setup SSH key
mkdir -p /home/deploy/.ssh
cp ~/.ssh/authorized_keys /home/deploy/.ssh/
chown -R deploy:deploy /home/deploy/.ssh

# Turn off password login + root login
sudo nano /etc/ssh/sshd_config
# PermitRootLogin no
# PasswordAuthentication no
sudo systemctl restart sshd

# === Step 3: Firewall ===
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status

# === Step 4: Install Docker ===
curl -fsSL https://get.docker.com | sh
sudo usermod -aG docker deploy

# === Step 5: Deploy with Docker Compose ===

Sample code:

# docker-compose.yml
version: "3.8"

services:
  app:
    image: my-app:latest
    build: .
    restart: unless-stopped
    environment:
      - NODE_ENV=production
      - DATABASE_URL=postgresql://user:pass@db:5432/mydb
    ports:
      - "3000:3000"
    depends_on:
      - db
      - redis

  db:
    image: postgres:16-alpine
    restart: unless-stopped
    volumes:
      - pgdata:/var/lib/postgresql/data
    environment:
      - POSTGRES_USER=user
      - POSTGRES_PASSWORD=securepassword
      - POSTGRES_DB=mydb

  redis:
    image: redis:7-alpine
    restart: unless-stopped

volumes:
  pgdata:

Run these commands to deploy:

# Deploy!
docker compose up -d

# Update (zero-downtime)
docker compose pull
docker compose up -d --no-deps --build app

---

4️⃣ Reverse Proxy — Nginx vs Caddy

Why Do You Need a Reverse Proxy?

Sample code:

Nginx vs Caddy

Both are excellent, but they focus differently: Nginx is highly flexible for large production estates, while Caddy wins on simplicity and auto-HTTPS for teams that need to ship quickly.

The configuration file looks like this:

Nginx Config — Full Production Setup

Sample code:

# /etc/nginx/sites-available/myapp

# Redirect HTTP → HTTPS
server {
    listen 80;
    server_name myapp.com www.myapp.com;
    return 301 https://$server_name$request_uri;
}

# Main HTTPS server
server {
    listen 443 ssl http2;
    server_name myapp.com www.myapp.com;

    # SSL (managed by certbot)
    ssl_certificate /etc/letsencrypt/live/myapp.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/myapp.com/privkey.pem;

    # 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 Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

    # Gzip compression
    gzip on;
    gzip_vary on;
    gzip_min_length 1024;
    gzip_types text/plain text/css application/json application/javascript
               text/xml application/xml text/javascript image/svg+xml;

    # Static files (serve directly, bypass app)
    location /static/ {
        alias /var/www/myapp/static/;
        expires 30d;
        add_header Cache-Control "public, immutable";
    }

    # API / App (proxy to Node.js)
    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;

        # Timeouts
        proxy_connect_timeout 60s;
        proxy_send_timeout 60s;
        proxy_read_timeout 60s;
    }

    # Rate limiting for API
    location /api/ {
        limit_req zone=api burst=20 nodelay;
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    # Health check
    location /health {
        access_log off;
        proxy_pass http://localhost:3000/health;
    }
}

# Rate limit zone (put this inside the http block)
# limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

Caddy Config — So Much Simpler!

Sample code:

# Caddyfile — this really is all of it!

myapp.com {
    # HTTPS is handled automatically — nothing to do!

    # Proxy to app
    reverse_proxy localhost:3000

    # Static files
    handle_path /static/* {
        root * /var/www/myapp/static
        file_server {
            precompressed gzip br
        }
    }

    # Compression
    encode gzip zstd

    # Security headers
    header {
        X-Frame-Options "SAMEORIGIN"
        X-Content-Type-Options "nosniff"
        Strict-Transport-Security "max-age=31536000; includeSubDomains"
    }

    # Rate limiting
    rate_limit {
        zone api {
            key {remote_host}
            events 10
            window 1s
        }
    }

    # Logs
    log {
        output file /var/log/caddy/myapp.log
        format json
    }
}

# Multiple sites? Just add a block!
api.myapp.com {
    reverse_proxy localhost:4000
}

staging.myapp.com {
    reverse_proxy localhost:5000
}

The configuration file looks like this:

# Nginx: five steps to do
sudo apt install nginx certbot python3-certbot-nginx
sudo certbot --nginx -d myapp.com -d www.myapp.com
sudo nginx -t
sudo systemctl reload nginx
# + set up a cron job to renew the certificate

# Caddy: one step
sudo apt install caddy
sudo nano /etc/caddy/Caddyfile  # paste the config above
sudo systemctl reload caddy
# HTTPS is handled automatically ✅

---

5️⃣ SSL/TLS — The HTTPS Every Site Must Have

What Are SSL and TLS?

Sample code:

Ways to Get an SSL Certificate

The heart of it is making HTTPS the default from day one, because it bears directly on security, on SEO, and on how trustworthy the system looks.

Run these commands to deploy:

Let's Encrypt + Certbot

Run these commands to deploy:

# Install certbot
sudo apt install certbot python3-certbot-nginx

# Get certificate (if you are on Nginx)
sudo certbot --nginx -d myapp.com -d www.myapp.com
# → answer the prompts → the cert arrives automatically!

# Auto-renew (certbot has already set this up)
sudo certbot renew --dry-run

# Check cert status
sudo certbot certificates

# Manual renew
sudo certbot renew
sudo systemctl reload nginx

---

6️⃣ Domain Management — DNS

How Does DNS Work?

Sample code:

DNS Record Types

Bookmark this DNS table for real work, because a great many production problems begin with a single wrong A, CNAME or TXT record.

Sample code:

A Sample DNS Setup — Cloudflare

Sample code:

Where Should You Buy a Domain?

Choosing a registrar is not only about the first-year price of the domain: look at the renewal cost, at the UX of managing DNS, and at how transparent the fees are over the long run.

Sample code:

---

7️⃣ CDN — Content Delivery Network

How Does a CDN Work?

Sample code:

CDN Providers

For an ordinary site the Cloudflare free plan is usually enough, but if you live deep inside the AWS ecosystem, CloudFront is easier to manage alongside what you already have.

Sample code:

Cloudflare Setup (5 Minutes)

Sample code:

Cache Headers — Controlling What Gets Cached

Sample code:

# Nginx — Cache Control headers

# Static assets (images, CSS, JS) — cache for a long time
location ~* \.(jpg|jpeg|png|gif|ico|css|js|woff2)$ {
    expires 365d;
    add_header Cache-Control "public, immutable";
}

# HTML — do not cache (always serve fresh content)
location ~* \.html$ {
    add_header Cache-Control "no-cache, must-revalidate";
}

# API — never cache, no exceptions
location /api/ {
    add_header Cache-Control "no-store, no-cache";
}

Sample code:

---

8️⃣ Deployment Strategies — Shipping Without Breaking Things

Overview

Run these commands to deploy:

Rolling Deployment

Run these commands to deploy:

Like changing a car's tyres... one wheel at a time

Start:   [v1] [v1] [v1] [v1]  ← 4 instances, all v1

Step 1:  [v2] [v1] [v1] [v1]  ← update 1st instance
         ↑ run the health check → ✅ pass → carry on

Step 2:  [v2] [v2] [v1] [v1]  ← update 2nd instance
         ↑ run the health check → ✅ pass → carry on

Step 3:  [v2] [v2] [v2] [v1]  ← update 3rd instance

Step 4:  [v2] [v2] [v2] [v2]  ← done! 🎉

❌ What if Step 2 fails?
Step 2:  [v2] [v2] [v1] [v1]  ← v2 #2 health check ❌
         → Stop! Rollback v2 #1 and #2 → [v1] [v1] [v1] [v1]

✅ Pros: simple, uses the same resources as before
❌ Cons: during the deploy two versions run side by side

Blue-Green Deployment

Run these commands to deploy:

Canary Deployment

Sample code:

Deployment Strategies Compared

This table helps you make the risk call: if you need to ship fast, use Rolling; if the system is highly critical, move up to Blue-Green or Canary.

Run these commands to deploy:

Kubernetes Rolling Update Config

The configuration file looks like this:

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1          # may add 1 new pod above the count
      maxUnavailable: 0     # never let the pod count drop (zero-downtime)
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: myapp
          image: myapp:v2
          ports:
            - containerPort: 3000

          # Health checks — this matters enormously!
          readinessProbe:
            httpGet:
              path: /health
              port: 3000
            initialDelaySeconds: 5
            periodSeconds: 5

          livenessProbe:
            httpGet:
              path: /health
              port: 3000
            initialDelaySeconds: 15
            periodSeconds: 10

          resources:
            requests:
              memory: "128Mi"
              cpu: "100m"
            limits:
              memory: "256Mi"
              cpu: "500m"

The configuration file looks like this:

# Deploy
kubectl apply -f deployment.yaml

# Watch the rollout status
kubectl rollout status deployment/myapp

# Roll back if something goes wrong
kubectl rollout undo deployment/myapp

# See the history
kubectl rollout history deployment/myapp

---

9️⃣ Full Production Setup — From Zero to Production

Architecture Overview

Run these commands to deploy:

GitHub Actions — Auto Deploy on Push

Run these commands to deploy:

# .github/workflows/deploy.yml
name: Deploy to Production

on:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20

      - name: Install & Test
        run: |
          npm ci
          npm run lint
          npm test

  deploy:
    needs: test
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'

    steps:
      - uses: actions/checkout@v4

      - name: Deploy to VPS
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: deploy
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: |
            cd /home/deploy/myapp
            git pull origin main
            docker compose pull
            docker compose up -d --build --no-deps app
            docker image prune -f

      - name: Health Check
        run: |
          sleep 10
          curl -f https://myapp.com/health || exit 1

      - name: Notify on Failure
        if: failure()
        run: |
          curl -X POST "${{ secrets.SLACK_WEBHOOK }}" \
            -H 'Content-type: application/json' \
            -d '{"text":"❌ Deploy failed! Check GitHub Actions."}'

Automated Backups

Run these commands to deploy:

#!/bin/bash
# backup.sh — run daily via cron

set -euo pipefail

BACKUP_DIR="/home/deploy/backups"
DATE=$(date +%Y-%m-%d_%H%M)
RETENTION_DAYS=7

# Backup PostgreSQL
docker exec postgres pg_dump -U user mydb | gzip > "$BACKUP_DIR/db_${DATE}.sql.gz"

# Backup app data
tar czf "$BACKUP_DIR/data_${DATE}.tar.gz" /home/deploy/myapp/data/

# Upload to Backblaze B2 (cheap!)
rclone copy "$BACKUP_DIR/db_${DATE}.sql.gz" b2:my-backups/db/
rclone copy "$BACKUP_DIR/data_${DATE}.tar.gz" b2:my-backups/data/

# Cleanup old backups
find "$BACKUP_DIR" -name "*.gz" -mtime +$RETENTION_DAYS -delete

echo "✅ Backup completed: $DATE"

Run these commands to deploy:

# Cron job (daily at 3 AM)
crontab -e
0 3 * * * /home/deploy/backup.sh >> /var/log/backup.log 2>&1

---

🔟 Monitoring — Know Before It Breaks

Uptime Monitoring

Sample code:

# Uptime Kuma — self-hosted uptime monitor
# (free, good-looking, and it can alert you)

docker run -d \
  --name uptime-kuma \
  --restart unless-stopped \
  -p 3001:3001 \
  -v uptime-kuma:/app/data \
  louislam/uptime-kuma:1

# → open http://your-server:3001
# → add monitors:
#   - HTTPS: myapp.com (check every 60s)
#   - TCP: db server port 5432
#   - Docker container health
# → set up alerts: Telegram, Slack, Discord, Email

Simple Health Check Endpoint

The configuration file looks like this:

// Express.js health check
app.get('/health', async (req, res) => {
  const health = {
    status: 'ok',
    timestamp: new Date().toISOString(),
    uptime: process.uptime(),
    checks: {}
  };

  // Check database
  try {
    await db.query('SELECT 1');
    health.checks.database = 'ok';
  } catch (err) {
    health.status = 'degraded';
    health.checks.database = 'error';
  }

  // Check Redis
  try {
    await redis.ping();
    health.checks.redis = 'ok';
  } catch (err) {
    health.status = 'degraded';
    health.checks.redis = 'error';
  }

  // Check disk space
  const diskFree = getDiskFreePercent();
  health.checks.disk = diskFree > 10 ? 'ok' : 'warning';

  const statusCode = health.status === 'ok' ? 200 : 503;
  res.status(statusCode).json(health);
});

---

🛡️ Security Checklist — Before You Go Live

The configuration file looks like this:

---

🗺️ Decision Flowchart — How Do You Pick a Host?

Sample code:

---

🔑 Key Takeaways

The central idea of this post is to “match the choice to the project's stage” rather than reaching for the biggest thing on day one, then upgrading the architecture as the real workload demands.

1. Start simple, then work up — Vercel/Netlify → PaaS → VPS → Cloud
2. HTTPS is free everywhere — Let's Encrypt, Caddy auto-SSL, Cloudflare
3. Cloudflare = must-have — CDN + DNS + DDoS, free
4. Caddy is simpler than Nginx — for projects that need little fine-tuning
5. Zero-downtime deploy is the standard — a rolling update is the default
6. Canary deploy for critical systems — it shrinks the blast radius
7. Blue-Green for instant rollback — but it costs 2x the resources
8. VPS + Docker Compose + Caddy = sweet spot — $5-15/mo buys production-grade
9. Automate everything — CI/CD, backups, monitoring, SSL renewal
10. Monitor before you deploy — no monitoring = you never learn it broke

---

📌 This is #21 in our DevOps & Full-Stack series

📚 The full series:

1. Git Branching — Branching That Stays Organized
2. CI/CD Pipeline — From Commit to Production
3. Docker vs VMs — What a Container Is and Why You Need One
4. API Lifecycle — How a Request Travels
5. Kubernetes — Managing Containers at Production Scale
6. Networking — DNS, TCP, Load Balancer, Firewall
7. Infrastructure as Code — Terraform & Ansible
8. Monitoring & Observability — Logs, Metrics, Traces
9. Linux & Shell Essentials — The Basics Every DevOps Engineer Needs
10. DevSecOps & Security — Shift Left, OWASP, Secrets
11. Testing Strategies — Pyramid, TDD, Load, Chaos
12. GitOps & ArgoCD — Git-driven Deployments
13. Cloud Architecture — AWS, GCP, Azure Fundamentals
14. SRE — Site Reliability Engineering
15. GitHub Actions Workflow — Advanced CI/CD
16. Automated Testing — Unit, Integration, E2E
17. Database Design & SQL — Normalization, Indexing, Query Optimization
18. Authentication & Authorization — JWT, OAuth, RBAC
19. Web Architecture & Design Patterns — Monolith vs Microservices
20. Frontend Performance & Modern Frameworks
21. Deployment & Hosting Strategies — Vercel to Bare Metal ← 📍 you are here