Chapter 7 — Cloud Deployment

The why

The cloud is not a place — it's a set of tradeoffs. Between control and convenience. Between monthly bills and midnight pages. Between "it works on my machine" and "it works for 100,000 users." Picking the right deployment strategy is the most expensive decision you'll make this year.

Core concepts

The cloud landscape: from raw metal to fully managed

Self-Managed ←————————————————————————————————————————→ Fully Managed
 
Bare Metal     IaaS          Container        PaaS          Serverless      BaaS
   |             |            Platform          |               |             |
Colocation    EC2/Droplet   ECS/K8s/Nomad    Render/Railway  Lambda/Cloud   Supabase/
(OVH, Hetzner) (AWS, DO,    (AWS, GCP,        (Fly.io,       Run (AWS,      Firebase
               GCP, Azure)   Self-hosted)      Railway)       GCP, Azure)    (DB, Auth)
 
More control ←————————————————————————————————————————————————————————→ Less control
Less abstraction ←—————————————————————————————————————————————————————→ More abstraction
More responsibility ←———————————————————————————————————————————————————→ Less responsibility
Cheaper per unit ←—————————————————————————————————————————————————————→ Costlier per unit
 
Ideal for:       Ideal for:      Ideal for:      Ideal for:      Ideal for:     Ideal for:
Predictable,    Variable        Microservices    Early-stage     Bursty          MVPs, hack-
steady-state    workloads       at medium        startups,       workloads,      athons,
workloads                        scale            small teams     event-driven    prototypes

The major players: a practical comparison

VPS setup checklist: from empty box to production-ready

Every VPS you provision needs the same baseline hardening. Here's the checklist you'll run on every server, forever:

# === VPS PROVISIONING CHECKLIST ===
# Run these in order on every new server
 
# 1. UPDATE EVERYTHING
sudo apt update && sudo apt upgrade -y
sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure --priority=low unattended-upgrades  # Enable automatic security updates
 
# 2. CREATE A NON-ROOT USER
sudo adduser deploy

The PaaS sweet spot: Railway and Fly.io

For most indie developers and early-stage startups, a PaaS is the right call. You get production-grade infrastructure without the operations burden:

Railway (railway.app):

# Deploy from any GitHub repo in under 2 minutes
# railway.json at project root:
{
  "build": {
    "builder": "NIXPACKS",
    "buildCommand": "npm run build"
  },
  "deploy": {
    "startCommand": "npm start",
    "healthcheckPath":

Fly.io:

# fly.toml at project root:
app = "my-api"
primary_region = "iad"  # Virginia
 
[build]
  builder = "dockerfile"
 
[http_service]
  internal_port = 3000
  force_https = true
  auto_stop_machines = true
  auto_start_machines = true

Database hosting: where to put your data

Your database is the hardest thing to move, so choose carefully:

# NEVER do this in production:
# Running Postgres in a Docker container without persistent volume
# docker run -d postgres:16  # Data disappears on container restart!
 
# Always use a managed service or properly configured persistent volume:
docker run -d \
  --name postgres \
  -e POSTGRES_PASSWORD=supersecret \
  -v pgdata:/var/lib/postgresql/data \  # Persistent volume
  -p 5432:5432 \
  postgres:16
 

Object storage (S3): files that aren't on your server

Storing user uploads on your application server is a ticking time bomb. Use object storage:

// Uploading files to S3-compatible storage (AWS S3, Cloudflare R2, DigitalOcean Spaces)
import { S3Client, PutObjectCommand } from '@aws-sdk/client-s3';
 
// Works with AWS S3, Cloudflare R2, Backblaze B2, MinIO, DigitalOcean Spaces
const s3 = new S3Client({
  region: 'auto',
  endpoint: `https://${process

CDN: content at the speed of light

A CDN (Content Delivery Network) caches your static assets at edge locations worldwide:

# Without CDN (users fetch from your server in Virginia):
# Tokyo user: ~150ms latency per asset
# London user: ~70ms latency per asset
 
# With CDN (users fetch from nearest edge node):
# Tokyo user: ~5ms latency per asset (Tokyo edge)
# London user: ~3ms latency per asset (London edge)
 
# CloudFront (AWS) or Cloudflare CDN:
# 1. Point your DNS at the CDN (CNAME to cdn.yourapp.com.cdn.cloudflare.net)
# 2. Set cache headers on your origin (Cache-Control: public, max-age=31536000)
# 3. CDN caches at edge — subsequent requests never touch your server
 
# Cache-Control strategy by file type:
# .js, .css, .png, .svg → max-age=31536000, immutable (content-hashed filenames)
# .html → max-age=0, must-revalidate (always check for updates)
# /api/* → no-store (never cache dynamic data)

Cost estimation: what you'll actually pay

=== SMALL SAAS (1,000 DAU) — Monthly Estimate ===
 
Option A: PaaS Route (simplest)
  Railway: App ($5 base + ~$10 usage)      = $15
  Supabase: Database (Pro plan)             = $25
  Cloudflare R2: 50GB storage + 100GB egress = ~$2
  Resend: Transactional emails (5K emails)   = $0 (free tier)
  ─────────────────────────────────────────
  Total: ~$42/mo
 
Option B: VPS Route (cheaper, more work)
  Hetzner CX22: 2 vCPU, 4GB RAM, 40GB SSD  = €3.99 (~$4.50)
  DigitalOcean Droplet: 1 vCPU, 1GB RAM    = $6
  Cloudflare R2: Same                       = ~$2
  Resend: Same                               = $0
  ─────────────────────────────────────────
  Total: ~$12.50/mo
 
Option C: AWS Route (enterprise-grade)
  EC2 t3.medium (reserved, 1yr):            = ~$25
  RDS db.t3.micro (Multi-AZ):               = ~$35
  S3 + CloudFront:                           = ~$10
  ALB (Load Balancer):                       = ~$22
  Route53:                                   = ~$2
  CloudWatch:                                = ~$5
  ─────────────────────────────────────────
  Total: ~$99/mo
 
Option D: Scale to 100K DAU
  AWS/GCP: $1,500-5,000/mo (compute, DB, bandwidth, support)
  Self-hosted on colocation: $500-1,500/mo (servers + bandwidth + ops time)
 
Key insight: At small scale, PaaS premium is ~$30/mo — worth every penny.
At medium scale (10K DAU), the premium grows to $500/mo — consider VPS migration.
At large scale, you need a dedicated ops team regardless of provider.

Real-world example: How Notion migrated from a monolith on a single box to sharded Postgres

Notion started as a single Node.js app on a single DigitalOcean Droplet with a single Postgres instance. That architecture got them to thousands of users before cracks appeared:

The breaking point: At ~50K DAU, their single Postgres instance hit CPU saturation during peak hours. Pages loaded in 3-5 seconds. Their "quick fix" was vertical scaling — they kept upgrading to larger and larger instances until they hit the largest Droplet available and were still struggling.

The migration (18 months): They sharded their Postgres database across 32 instances, each holding a subset of workspaces. The sharding key was workspace ID. The application layer handled routing queries to the correct shard. They built a custom proxy layer (written in Go) that sat between the Node app and Postgres, transparently routing queries and aggregating cross-shard results.

The lesson for your deployment: Start simple (single VPS, single DB). But design your data model with sharding in mind from day one — workspace-level or tenant-level isolation is easier to implement before you have millions of rows. And never underestimate how far a single VPS can take you — Notion got to thousands of users on a $40/mo Droplet.

Common mistakes

Production notes

• Immutable infrastructure: never SSH into a server to fix something. If you need to change a config, update the Dockerfile or IaC template and redeploy. Servers should be cattle, not pets. If a server has a name (prod-db-east-1, not thor-database), you're on the right track. Immutable infrastructure means you can destroy and recreate any server without fear.
• Use infrastructure as code (IaC) from day one. Terraform (cloud-agnostic), Pulumi (real programming languages), or CloudFormation/CDK (AWS-native). A terraform apply should recreate your entire infrastructure: VPC, subnets, security groups, EC2 instances, RDS, load balancer, DNS records. Manual click-ops in the AWS console is unreproducible and unscalable.
• Separate environments with separate accounts/projects, not just different servers. Your staging environment should be in a different AWS account or GCP project from production. This prevents: accidental production resource deletion, staging load tests affecting production databases, and credential leakage from staging compromising production.
• Implement a "break glass" emergency access procedure. If your SSO/IdP is down, how do you access the AWS console? Store emergency console credentials (with MFA) in a physical safe or a separate, highly secured password manager. Test this procedure quarterly.
• Tag everything. Every resource (EC2, RDS, S3 bucket, load balancer) should have tags: Environment=production, Service=user-api, Team=backend, CostCenter=engineering. Tags enable cost allocation ("how much does the user API cost?"), security audits ("which resources aren't tagged?"), and automation ("delete all resources tagged Environment=staging every Friday night").

Performance notes

• Choose your region based on user latency, not server cost. A $5/mo server in Virginia serving users in Mumbai adds 200ms of latency to every request. A $7/mo server in Mumbai adds 5ms. The $2 difference is worth more than any code optimization you'll ever write.
• Use connection pooling for database connections. Serverless and PaaS apps create new connections per request. A single Postgres connection costs ~2MB of RAM on the server. 100 concurrent serverless functions = 200MB of RAM consumed by idle connections. Use PgBouncer (built into Supabase and DigitalOcean Managed DBs) or your framework's pooling (Prisma's connection_limit).
• Enable HTTP/2 and Brotli compression at your CDN or load balancer. This is a configuration toggle that costs nothing and reduces bandwidth by 30-50% compared to gzip alone. Cloudflare, CloudFront, and Fastly all support Brotli with a single checkbox.
• Cache database query results when appropriate. A Redis cache in front of your database can reduce DB load by 90% for read-heavy workloads. The tradeoff: cache invalidation complexity. Cache user profiles, configuration data, and computed results. Don't cache real-time data or data with strict consistency requirements.

Security notes

• Never store secrets in environment variables exposed to the application runtime without encryption at rest. Platform-native secret managers (AWS Secrets Manager, GCP Secret Manager, Railway variables) encrypt secrets at rest and inject them at runtime. Docker environment variables are visible via docker inspect and in process listings (/proc/<pid>/environ).
• Use IAM roles, not long-lived access keys. On AWS, attach an IAM role to your EC2 instance or ECS task instead of embedding AWS_ACCESS_KEY_ID in your application. Roles automatically rotate credentials. Long-lived keys, when leaked (and they will leak), grant permanent access until manually revoked.
• Enable encryption at rest for all data stores. RDS encryption, S3 default encryption, EBS volume encryption. The performance overhead is negligible on modern CPUs (AES-NI hardware acceleration), and the protection against physical disk theft or improper decommissioning is significant.
• Implement network segmentation. Your database should be in a private subnet with no internet gateway. Your application servers should be in a public subnet (or behind a load balancer). The only path to the database is through the application. Security groups enforce this at the network level, regardless of application bugs.
• Enable and monitor CloudTrail (AWS) or Audit Logs (GCP). Every API call to your cloud provider is logged. If someone deletes your production database, the audit log tells you who, when, and from which IP. Without audit logging, you're investigating security incidents in the dark.

Exercises

Beginner

1. Deploy to Railway: Take any Node.js or Python API (even a simple "Hello World" Express app). Deploy it to Railway. Configure environment variables for a database connection. Access the deployed app via the Railway-generated URL. Stream logs using railway logs. Add a /health endpoint that returns {"status":"ok"} and verify Railway's health checker detects it.

2. Provision and harden a VPS: Create a $4-6/mo VPS on DigitalOcean or Hetzner. Run through the full VPS provisioning checklist: create deploy user, harden SSH, configure UFW, install fail2ban, set up automatic security updates. Verify: can you SSH as root? (should fail). Can you SSH as deploy with your key? (should succeed). Is port 22 the only open port before you install your app?

Intermediate

1. Deploy with Docker to a VPS: Dockerize a Node.js + Postgres application. Push the Docker image to Docker Hub or GitHub Container Registry. On your VPS, pull the image and run it with Docker Compose. Configure Nginx as a reverse proxy with Let's Encrypt SSL. Set up a systemd service to auto-restart Docker Compose on reboot. Document the entire process in a DEPLOYMENT.md file.

2. Set up a CI/CD pipeline: Using GitHub Actions, create a workflow that: runs tests on push to main, builds a Docker image, pushes it to a container registry, SSHs into your VPS, pulls the new image, and restarts the container. Include a rollback step that redeploys the previous image if the health check fails after deployment.

Advanced

1. Design a multi-region deployment: Your application has users in North America, Europe, and Asia. Design an architecture that deploys your API to three regions behind geo-routed DNS. The database must be writable from all regions (consider: multi-master vs single-writer with read replicas vs distributed SQL like CockroachDB). Document the tradeoffs: latency vs consistency, cost vs availability, operational complexity vs user experience. Include a disaster recovery plan for a full region outage.

2. Infrastructure as Code challenge: Using Terraform (or Pulumi), define: a VPC with public and private subnets, an EC2 instance or ECS Fargate service in the public subnet, an RDS instance in the private subnet, security groups allowing only necessary traffic, an Application Load Balancer with HTTPS, and Route53 DNS records. The entire infrastructure should be creatable with terraform apply and destroyable with terraform destroy. Test by creating, verifying the app works, and destroying.

Interview questions

Beginner

1. Q: What's the difference between IaaS, PaaS, and SaaS? A: IaaS (Infrastructure as a Service — EC2, Droplets) gives you raw virtual machines. You manage the OS, runtime, scaling, and security. PaaS (Platform as a Service — Railway, Render, Heroku) gives you a managed runtime — you provide code, the platform handles OS, scaling, SSL, and basics. SaaS (Software as a Service — Gmail, Slack) gives you a complete application — you just use it. The tradeoff descends: IaaS = maximum control, maximum responsibility. PaaS = less control, less responsibility. SaaS = zero control, zero responsibility.

2. Q: Why would you use a CDN for a backend API? A: A CDN primarily accelerates static assets (images, CSS, JS), but it also benefits APIs through: edge caching of cacheable responses (reducing origin load), DDoS absorption at the edge (requests never reach your servers), TLS termination close to users (faster handshake), and anycast networking (users routed to nearest edge automatically). Cloudflare's "API Shield" and AWS CloudFront with API Gateway are purpose-built for this. The CDN becomes your API's front door.

3. Q: What are security groups and why are they important? A: Security groups are virtual firewalls that control inbound and outbound traffic to cloud resources. They're stateful — if you allow outbound traffic to a database on port 5432, the response traffic is automatically allowed back. They're the first line of defense: a misconfigured security group (0.0.0.0/0 on port 5432) means your database is publicly accessible regardless of application-level authentication. They operate at the network level, so even if your application is completely compromised, properly configured security groups limit the blast radius.

Senior

1. Q: You're moving from a PaaS to your own VPS infrastructure. What are the hidden costs? A: The obvious costs are the VPS bill (lower than PaaS). The hidden costs: (1) Ops time: Patching OS, updating packages, monitoring disk space, investigating CPU spikes — this is 5-10 hours/month minimum even for a simple setup. At your hourly rate, this dwarfs the PaaS premium. (2) Security: Managing SSH keys, configuring firewalls, responding to CVEs. One security breach costs more than years of PaaS bills. (3) Reliability: No automatic failover, no managed database backups, no built-in horizontal scaling. You're now the on-call engineer. (4) Knowledge bus factor: If you're the only one who knows the infrastructure, you can never take a real vacation. (5) Tool sprawl: You'll need monitoring (Prometheus+Grafana or Datadog), log aggregation (Loki or Papertrail), alerting (PagerDuty or self-hosted), backup automation, and CI/CD pipeline maintenance. Calculate the fully loaded cost including your time at market rate. If that number is less than the PaaS premium, migrate. If not, the PaaS is cheaper.

2. Q: How do you handle database migrations in a zero-downtime deployment? A: Zero-downtime migrations require a multi-phase approach. (1) Expand: Add new columns/tables without removing old ones. The application reads from old columns, writes to both. Deploy this schema. (2) Migrate data: Backfill new columns from old data (async, batched, throttle to avoid DB load). (3) Contract: Deploy new application code that reads from new columns, still writes to both. (4) Cleanup: After verifying no application reads old columns, deploy schema that drops old columns. Each phase is a separate deploy. The key principle: the database schema must support both the old and new application versions simultaneously during the transition. Feature flags control which code path is active. Never rename a column — add a new one, dual-write, migrate, switch reads, drop old. This is methodical and slow, but it's the only way to avoid downtime.

3. Q: Your production database is running out of disk space. Walk through your response from alert to resolution. A: (1) Triage (immediate): Check if the disk is actually full (df -h). Identify what's consuming space — is it data growth (expected), WAL files piling up (replication slot issue), or logs (/var/log)? (2) Buy time: If it's logs, compress and rotate. If it's WAL, check replication slots — a disconnected replica causes WAL accumulation. If it's actual data growth, enable auto-vacuum (if off), check for bloat. (3) Increase storage (RDS: modify instance, ~5 min downtime if no Multi-AZ; self-hosted: attach and extend volume via LVM or cloud provider's resize feature). (4) Data growth: is there a table growing unexpectedly (audit logs, event sourcing without TTL)? Fix the application. WAL growth: fix replication. (5) Set up disk monitoring with predictive alerts (alert at 70%, page at 85%). Implement data retention policies (TTL on events/audit logs). Set up auto-scaling storage if your provider supports it. (6) Document timeline, actions taken, root cause, and prevention measures. Share with the team.

Summary

The cloud is a spectrum from bare metal (total control, total responsibility) to fully managed (zero control, zero responsibility). PaaS platforms (Railway, Render, Fly.io) are the right answer for most projects under 10K DAU — the premium is cheaper than your ops time. VPS setups (DigitalOcean, Hetzner) offer the best price-to-performance ratio for those willing to manage servers. The hyperscalers (AWS, GCP, Azure) are for enterprises with dedicated ops teams and complex architectures. Deployment fundamentals are universal: harden your VPS (SSH keys, firewall, fail2ban), never run as root, use managed databases with automatic backups, store files in S3-compatible storage, put a CDN in front of everything, and implement health checks. Infrastructure as Code and immutable infrastructure transform deployment from a source of anxiety into a repeatable, testable process. The best deployment strategy is the one that lets you sleep through the night — and that's usually simpler than you think.

Quick recall

• IaaS = VMs you manage. PaaS = platform you deploy code to. Serverless = functions, no servers to manage.
• Railway/Render/Fly.io are PaaS winners for indie devs. DigitalOcean/Hetzner are IaaS winners for cost-sensitive projects.
• VPS hardening checklist: non-root user, SSH keys only, UFW, fail2ban, unattended-upgrades, swap file.
• Never deploy database and app on the same VPS in production. Use managed DB or dedicated VPS with backups.
• S3-compatible storage for user uploads. Cloudflare R2 has zero egress fees (killer feature).
• CDN: cache static assets at the edge. Cache-Control: immutable for content-hashed files, must-revalidate for HTML.
• PaaS premium (~$30-50/mo) is cheaper than your ops time for projects under 10K DAU.
• Immutable infrastructure: never SSH to fix. Update config, rebuild, redeploy. Servers are cattle, not pets.
• Infrastructure as Code: Terraform/Pulumi from day one. Manual click-ops is unreproducible.
• Cost estimation: include your time at market rate. A $6/mo VPS that needs 10 hours/month of ops costs more than a $50/mo PaaS.

Quiz

1. Which cloud model gives you the most control but also the most responsibility? A) IaaS (Infrastructure as a Service) B) PaaS (Platform as a Service) C) SaaS (Software as a Service) D) Serverless

2. Why should you never run your application as root on a VPS? A) It's slower B) A vulnerability in your app gives an attacker complete control of the server C) Cloud providers charge more for root access D) Root can't bind to port 443

3. What's the primary advantage of Cloudflare R2 over AWS S3? A) Higher durability B) Faster uploads C) Zero egress (bandwidth) fees D) Better API compatibility

4. At approximately what scale does the PaaS premium typically become more expensive than hiring ops time? A) 100 DAU B) ~10K DAU, where the premium grows to ~$500/mo and ops time becomes proportionally cheaper C) 1M DAU D) PaaS is always cheaper

5. What is immutable infrastructure? A) Servers that never reboot B) Servers that are replaced rather than modified — changes are made by deploying new instances from updated images C) Infrastructure that can't be deleted D) Servers without operating systems

6. Why should staging and production be in separate AWS accounts? A) It's required by AWS ToS B) To prevent accidental production resource deletion, staging load tests affecting production, and credential leakage C) It's cheaper D) AWS only allows one RDS instance per account

7. What's the first command you should run when a production database is running out of disk space? A) df -h to check actual disk usage and identify what's consuming space B) DROP TABLE to free space C) reboot to clear temp files D) Call AWS support