DevOps on a VPS for Startups: Self-Hosted CI/CD, Docker and Monitoring

services:
  app:
    image: ghcr.io/your-org/startup-app:latest
    restart: unless-stopped
    env_file:
      - .env
    depends_on:
      - postgres
    ports:
      - "3000:3000"

  worker:
    image: ghcr.io/your-org/startup-worker:latest
    restart: unless-stopped
    env_file:
      - .env

  postgres:
    image: postgres:16
    restart: unless-stopped
    volumes:
      - postgres-data:/var/lib/postgresql/data

volumes:
  postgres-data:

sudo apt update && sudo apt upgrade -y
sudo apt install -y ufw fail2ban docker.io docker-compose-v2 curl git
sudo adduser deploy
sudo usermod -aG sudo deploy
sudo usermod -aG docker deploy
sudo ufw allow OpenSSH
sudo ufw allow 80
sudo ufw allow 443
sudo ufw enable

name: Deploy to VPS
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: docker bobservability setup answers four questions fast:

        

          
Is the site reachable?
          
Are containers healthy?
          
Is the host running out of resources?
          
Can the team restore data after failure?
        
        
Startups should invest in these four areas:
        

          
Uptime checks: test the public domain from outside the server (e.g., Pingdom, Uptime Robot, or Better Stack).
          
Host metrics: watch CPU, RAM, disk, and restart behavior (use Prometheus or cloud-provider dashboards).
          
Structured logs: make logs searchable and consistent (JSON logging, centralized log aggregation via Logstash or similar).
          
Off-server backups: never keep the only backup on the same VPS. Use S3, Backblaze, or a managed backup serviceare containers healthy, is the host running out of resources, and can the team restore data after failure?

        

          
Uptime checks: test the public domain from outside the server.
          
Host metrics: watch CPU, RAM, disk, and restart behavior.
          
Structured logs: make logs searchable and consistent.
          
Off-server backups: never keep the only backup on the same VPS.
        
        

          
Bash
          
#!/usr/bin/env bash
set -euo pipefail
BACKUP_DIR="/var/backups/postgres"
DATE="$(date +%F-%H%M)"
FILE="$BACKUP_DIR/startup-$DATE.sql.gz"
mkdir -p "$BACKUP_DIR"
docker exec startup-postgres-1 pg_dump -U startup startup | gzip > "$FILE"
        

        

          Important: a backup is not real until you test a restore. Schedule at least one restore drill before calling the stack production-ready.
        

        
Security Checklist for a Startup VPS
        

          
SSH keys only: disable password login and rotate access when the team changes.
          
Minimal ports: keep the public attack surface small.
          
Tagged images: avoid accidental deploys from floating container tags.
          
Patch routine: update the OS, Docker engine, and dependencies regularly.
          
Least privilege: keep credentials scoped and avoid unnecessary root access.
        

        
WhenVPS (Virtual Private Server)
            
A Virtual Private Serve:

        

          
Resource pressure is constant: you're regularly hitting CPU/RAM limits and vertical scaling (upgrading the VPS size) becomes expensive.
          
Downtime is costly: a single-point failure causes significant business impact; you need multi-region or multi-VPS redundancy.
          
Services need independent scaling: your worker queue outgrows your web tier, or certain services have very different traffic patterns.
          
Compliance requires isolation: regulatory requirements (PCI-DSS, HIPAA, SOC 2) mandate separate environments or stronger security boundaries.
          
Team expertise expands: your team now has dedicated DevOps engineers who can manage Kubernetes or multi-machine deployments.
        
        
Let evidence drive that move, not hype. Many mature startups stay on well-managed VPS setups for years (Ubuntu, CentOS, Debian).
            
Reverse Proxy
            
A front-facing service such as Nginx or Caddy that receives public traffic and forwards it to internal services. Handles SSL termination, load balancing, and routing.
            
CI/CD (Continuous Integration / Continuous Deployment)
            
Automation that tests, builds, and deploys code through a repeatable pipeline. Popular choices: GitHub Actions, GitLab CI, Jenkins. Reduces manual deploy errors and shortens time-to-market.
            
Container
            
A lightweight, isolated runtime package (typically built with Docker) that includes application code, dependencies, and OS libraries. Ensures consistency across development, testing, and production.
            
Rollback
            
The ability to return to the last known-good version after a failed deploy. With Docker and tagged images, rollback is as simple as restarting the previous container version.
            
Orchestration
            
Automated management of containers across multiple machines (e.g., Kubernetes, Docker Compose). Docker Compose handles single-VPS use cases; Kubernetes is needed at larger scale
            
A Virtual Private Server with isolated compute resources that you manage at the operating system level.
            
Reverse Proxy
            
A front-facing service such as Nginx or Caddy that receives public traffic and forwards it to internal services.
            
CI/CD
            
Automation that tests, builds, and deploys code through a repeatable pipeline.
            
Rollback
            
The ability to return to the last known-good version after a failed deploy.