Where apps actually run

Option 1: a virtual machine

Rent a VM (lesson 1-3) from AWS EC2, DigitalOcean, or Hetzner for a few dollars a month. You get a bare Linux box with an IP address. Then:

ssh you@your-server
sudo apt install docker.io docker-compose-v2
git clone your-repo && cd your-repo
docker compose up -d

Everything from units 2 through 5 works unchanged, which is the beauty of containers.

Honest tradeoffs. You control everything and it is the cheapest way to run something 24/7. But you are also the operations team: OS security updates, disk filling up with logs, restarting after reboots, TLS certificates. Nothing scales unless you build it. A VM is the best way to learn deployment and a fine way to run small real apps, and its skills transfer everywhere.

Option 2: PaaS. Option 3: serverless

A PaaS (platform as a service: Render, Railway, Fly.io) says "give us your repo or image, we do the rest". It builds from your Dockerfile, deploys on push (CD from unit 8, built in), and handles TLS, restarts, logs, and rollbacks with a UI. You trade money and control for that: less OS access, and pricing that beats a VM at small scale but grows steeply.

Serverless (AWS Lambda, Cloud Run) goes further: no server at all, your code runs per request and you pay per request. Scales to zero (free while idle) and to huge bursts automatically. The honest costs: cold starts (first request after idle waits for a container to spin up), execution time limits, and no long-lived processes or websockets in the classic model.

Default advice: side project, PaaS. Learning ops, VM. Spiky or rarely-used endpoints, serverless.