Many successful SaaS products started on one or two virtual servers. A VPS gives a startup predictable costs, full control, and no lock-in to proprietary cloud services, which is important when every dollar of runway counts. This guide outlines a practical path from MVP to a setup that handles real customers.
Stage 1: the MVP (one VPS)
A single VPS with 2–4 vCPU and 4–8 GB RAM can run:
- the web app (Node.js, Python/Django, Ruby on Rails, PHP/Laravel, Go…) in Docker or under systemd;
- PostgreSQL (or MySQL) and Redis on the same machine;
- Nginx or Caddy as a reverse proxy, with Let’s Encrypt;
- background workers (queues, scheduled jobs).
Deploy with Docker Compose, or a lightweight PaaS layer such as Coolify or Dokploy, if you want Git-push deploys. See Docker Compose tutorial, Coolify, and Dokploy.
Must-haves from day one:
- automated, off-site database backups, with a tested restore. See database backup automation;
- HTTPS, SSH keys only, a firewall. See Linux server hardening checklist;
- error tracking and uptime monitoring. See Uptime Kuma;
- CI/CD: tests and deploys on push. See GitHub Actions deploy to VPS.
Stage 2: first paying customers (2–3 servers)
- Separate staging server (small VPS) that mirrors production.
- Move the database to its own VPS when it competes with the app for RAM and CPU. Connect over a private network, or a WireGuard tunnel. See WireGuard.
- Object storage for user uploads (S3-compatible), instead of the app server’s disk. See MinIO.
- Transactional email through a provider (signup, password reset, invoices). See transactional email services.
- Centralised logs and metrics (Prometheus + Grafana, or a hosted service). See Prometheus node exporter.
Stage 3: growth (scale out)
- Two or more app servers behind a load balancer (Nginx or HAProxy). Keep app servers stateless: sessions in Redis, files in object storage. See Nginx load balancing.
- Database replication for read scaling and fast failover. See database replication explained.
- Queue workers on their own servers for heavy jobs (exports, emails, AI calls).
- CDN for static assets. See CDN for websites.
- Consider Kubernetes only when you have several services and the team to run it. Many SaaS products never need it. See Kubernetes vs Docker Compose.
Multi-tenancy basics
| Model | Isolation | Complexity | Typical use |
|---|---|---|---|
Shared database, tenant_id column |
Logical | Low | Most B2B/B2C SaaS |
| Schema per tenant (PostgreSQL) | Stronger | Medium | Moderate number of larger tenants |
| Database or server per tenant | Strongest | High | Enterprise or regulated customers |
Whatever you choose, enforce tenant scoping in one place (middleware or row-level security), and test it.
Security and compliance
- Secrets in environment files or a secrets manager, never in Git. See secrets management.
- Principle of least privilege for database users and SSH.
- Audit logs for admin actions, and encrypted backups.
- Choose server locations that match where your customers’ data should live (for example the USA for US customers, Hong Kong or Tokyo for Asia). See choosing a VPS location.
Cost control
- Steady workloads are cheaper on fixed-price VPS plans than on usage-billed cloud VMs. See VPS vs cloud hosting.
- Right-size servers based on monitoring, not guesses.
- Use managed third-party services only where they save significant engineering time (email, payments, error tracking).
Quick reference
| Stage | Setup |
|---|---|
| MVP | 1 VPS: app + Postgres + Redis + Nginx, Docker Compose, off-site backups |
| First customers | + staging, separate DB server, object storage, email provider |
| Growth | Load-balanced app servers, DB replicas, workers, CDN |
| Always | CI/CD, monitoring, tested restores, security basics |
Related: VPS for developers and Docker VPS hosting.