From lesson 8-1, the pipeline's last stage is deploy, and concretely it deploys to some machine or platform that will pull the image and run containers from it.
A registry stores images, it does not run them, so something with a CPU must pull the image and docker run it.
Choosing that something, whether a VM, a PaaS, or serverless, is what this lesson is about.
Option 1, a virtual machine
Renting a VM, as introduced in lesson 1-3, from AWS EC2, DigitalOcean, or Hetzner costs a few dollars a month and gives a bare Linux box with an IP address. From there:
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 whole beauty of containers.
| Aspect | Reality on a VM |
|---|---|
| cost for a 24/7 service | the cheapest option |
| control | total |
| OS security updates | yours |
| logs filling the disk | yours |
| TLS certificates | yours |
| scaling | only what you build |
The honest trade is that you are also the operations team. A VM is the best way to learn deployment and a perfectly fine way to run small real apps, and the skills transfer everywhere.
Options 2 and 3, PaaS and serverless
A PaaS, platform as a service, such as Render, Railway, or Fly.io, takes a repo or an image and does the rest. It builds from your Dockerfile, deploys on push with the CD from unit 8 built in, and handles TLS, restarts, logs, and rollbacks through a UI. The trade is money and control, meaning less OS access and pricing that beats a VM at small scale but grows steeply.
Serverless, such as AWS Lambda or Cloud Run, goes further. There is no server at all, code runs per request, and billing is per request. It scales to zero, so it is free while idle, and to huge bursts automatically. The honest costs are cold starts, where the 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.
| Property | VM | PaaS | Serverless |
|---|---|---|---|
| You manage | everything | your app | just code |
| Idle cost | full price | low | zero |
| Ops effort | high | low | lowest |
| Control | total | some | little |
The default advice is short. A side project belongs on a PaaS, learning ops belongs on a VM, and spiky or rarely-used endpoints belong on serverless.
Choosing a platform for a bursty internal tool
An internal report generator used a few times a week in bursts fits serverless best, since it scales to zero, idle time costs nothing, and occasional cold starts do not matter for this workload.
Mostly idle, bursty, and latency-tolerant is the serverless sweet spot, combining zero idle cost with automatic scale for the bursts.
| Platform | Weekly bill shape for this tool |
|---|---|
| VM | pays for roughly 165 idle hours |
| PaaS | a smaller but constant floor |
| serverless | only the minutes actually used |
For an always-hot user-facing API the answer shifts toward PaaS or VM, because cold starts begin to hurt real users. The workload shape decides, not the technology's reputation.
Naming the first-request delay
The delay is a cold start, two words, and the opposite of a warm instance.
Scale-to-zero means nothing is running while idle, so the first request pays the startup cost of a fresh container.
| State | First-request latency |
|---|---|
| warm, recently used | normal |
| cold, idle for a while | plus the container startup cost |
Platforms have shrunk it to tens or hundreds of milliseconds, and it is still the classic honest drawback of scale-to-zero. For latency-critical always-busy services it remains the main argument against serverless.