For six modules you have taken for granted a machine with Docker installed. In module 6 that machine multiplied into a cluster and the question stopped being comfortable: where do the hosts come from, who installs Docker on them, who updates them, and who answers the phone when one of them stops booting? This lesson starts with the tool that tried it first — Docker Machine, archived today — and ends with how it is actually done in 2026.

1. The real provisioning problem
2. What Docker Machine was and its driver model
3. The characteristic commands
4. Why it is archived and what to do if you run into it
5. What did survive: Docker contexts
6. An aurora-prod context over SSH
7. Deploying against a remote host without switching terminals
8. SSH versus exposing the daemon over TCP
9. The map of today's alternatives
10. Direct installation: the idempotent script
11. cloud-init: let the machine be born with Docker
12. Terraform / OpenTofu: declarative infrastructure
13. Ansible: configuring and maintaining the fleet
14. Packer and managed services
15. The host as an attack surface
16. Your own hosts or managed? Decision criteria

Between "I have an account with a cloud provider" and "docker compose up -d brings up Aurora Libros in production" there is a list that someone has to work through: create the VM (size, region, disk, network, security group), set up SSH access and an unprivileged user, install Engine and the Compose plugin, tune the daemon (data-root, logging, live-restore), harden the host (firewall, automatic patching), deploy the application, repeat it identically on the second host, and keep it running for three years. The last two points are what separate a tool from a tutorial: Docker Machine tackled the first three and left the rest out.

Docker Machine (docker-machine) was an official binary, a contemporary of Docker Toolbox (2015-2018), with one specific purpose: create a VM with Docker Engine already installed — locally or in the cloud — and point your local client at that remote daemon.

That second half was the interesting one. Remember 01-03: client and daemon are separate processes that talk over an API. If the client can reach a remote daemon, docker ps lists the containers of a server in Frankfurt from your laptop. Docker Machine automated the paperwork: creating the VM, installing Engine, generating mutual TLS certificates and exporting the variables that redirected the client.

The extensible piece was the driver: one adapter per platform. The command was the same; only --driver and its options changed.

The generic driver created nothing: it connected over SSH to an existing machine and installed Docker on it. It was a crude remote installer, exactly what a configuration manager covers better today.

You will see them in old documentation and in legacy scripts. Recognize them even if you never run them:

The eval was the magic and also the problem. It exported DOCKER_TLS_VERIFY=1, DOCKER_HOST=tcp://203.0.113.42:2376 and DOCKER_CERT_PATH pointing at the generated certificates.

From that point on, every docker command in that terminal went to the remote server, and opening another tab put you back on the local daemon. More than one famous incident was born from a docker compose down in the wrong terminal.

Docker archived the repository in 2021. There are no security patches, the drivers use APIs that have changed, and the installation downloads Engine versions that no longer exist.

Rule of thumb: if a tutorial uses it, that tutorial is more than five years old and everything else it says needs verifying. If it shows up in a legacy script at your company, do not run it: work out which machines it manages, move that information into contexts or Terraform, and plan its retirement with whoever maintains the infrastructure.

The idea that was worth keeping — one client, several daemons — is a first-class feature today: contexts. A context is a named destination. Unlike the eval, the switch is global and persistent, not per terminal.

The important distinction: docker-machine rm destroyed a machine; docker context rm merely forgets an address. Contexts do not create, do not install and do not maintain anything: they only point. That is why they are still useful and why they are no substitute for provisioning.

Aurora Libros has a host at libros.example.com with a deploy user in the docker group. First, make SSH work with a key and no password, and add an entry in ~/.ssh/config that makes everything else readable:

The context is a one-liner, and checking it does not require activating it:

Four containers, nine days of uptime, without opening a single manual SSH session.

Compose honors contexts, so the full deployment is this:

Three details change the outcome:

From the second row comes a golden rule: in production you do not build, you deploy an already published image. That is what your compose.prod.yaml does, referencing ghcr.io/auroralibros/aurora-api:2.0.0 by digest instead of a build:. The pipeline from 06-02 builds, signs and publishes; the host only does a pull.

Defensive pattern: never use docker context use for production. Leave default active and type --context aurora-prod explicitly, or at most set up an alias dprod='docker --context aurora-prod'. It takes longer to type, and that is exactly the advantage.

Docker Machine used tcp://IP:2376 with mutual TLS. You can still do that today, but you almost never should.

The risk row is the one to internalize. You already saw it in 05-03: whoever talks to the daemon can run docker run -v /:/host --privileged and is root on the machine. A 2375 open to the Internet is a machine given away; there are bots continuously scanning that port, and the usual pattern is mining cryptocurrency on your server for weeks.

If some tool insists on the API over TCP, the right answer is a local SSH tunnel, not opening the port:

They do not compete: they stack. A healthy 2026 setup is Terraform creates + cloud-init boots + Ansible maintains + contexts operate.

The honest version of the generic driver. The key point is that you can run it ten times with the same result.

Upside: zero dependencies and anyone can understand it. Limits: it does not control drift between hosts, it does not know which version is on each one, and it grows until it becomes unreadable. From the third host onwards, use Ansible. And one note: get.docker.com is convenient, but it is a curl | sh against the Internet; in production you use the official APT repository with its GPG key pinned, which is what the script does under the hood.

cloud-init is the de facto standard in cloud images: it reads a user-data payload on first boot and configures the machine before anyone logs in. It is the most direct replacement for docker-machine create.

You pass it as --user-data when creating the instance, and you validate it without spending money with cloud-init schema --config-file cloud-config.yaml; once on the host, cloud-init status --wait waits for it to finish and /var/log/cloud-init-output.log tells you what happened. Its limitation is structural: it runs only once. It is no use for changing something on fifty machines that are already running.

Terraform describes the infrastructure you want and works out the plan to get there. OpenTofu is its open source fork under the Linux Foundation, born after the 2023 license change; for everything you will see here they are interchangeable (tofu instead of terraform).

terraform plan is the reason this replaces scripts: it tells you what is going to happen before it happens. And since it lives in Git, provisioning gets reviewed in a pull request like any other code. The state file (terraform.tfstate) contains secrets in the clear: it belongs in a remote backend with locking, never in the repository.

Terraform creates; Ansible maintains. It connects over SSH, needs no agent, and its modules are idempotent: you describe the final state and it only acts when it has to.

The ghcr_token goes in encrypted with ansible-vault encrypt_string, never in the clear. And on the second run you will see changed=0: that is idempotency genuinely working.

Instead of installing Docker on every boot, Packer builds a machine image (AMI, snapshot) once with everything already in it, and instances boot in seconds. It is the reasoning behind container images, one level further down.

The cost is one more pipeline: every patch forces you to rebuild and redistribute the image. With autoscaling, it pays for itself. But the best way to maintain a host is still not to have one:

For an image like ghcr.io/auroralibros/aurora-api:2.0.0 — stateless, twelve-factor, with probes and graceful shutdown, exactly what you prepared in 06-01 — a Cloud Run-style service is a serious candidate: you hand it an image, a port and some variables. The fact that you can even consider it is a direct consequence of module 6, not a coincidence.

In 05-03 you hardened the container. All of that is useless if the host has gone fourteen months without patches.

And a warning that is not technical: agree in writing who maintains those machines. The question "who applies the kernel patches on the production host?" must have a person's name as its answer before the first customer arrives. If there is an infrastructure team or a systems administrator, host ownership, the maintenance window and the access procedure are agreed with them; if there is not, you are the one responsible, and it is worth writing down so nobody discovers it in the middle of an incident.

For Aurora Libros in 2026 the reasonable answer is a mix: a managed database — nobody wants to be the person responsible for PostgreSQL point-in-time recovery at three in the morning — and the application on your own hosts or on managed Kubernetes depending on the size. Which is exactly the decision the next lesson analyzes.

• Following a tutorial that uses docker-machine in 2026. Archived since 2021; if the tutorial uses it, everything else in it has expired too.
• Exposing 2375 "just for a moment, to test something". There are bots permanently scanning that port. An open daemon is root handed over for free, and the mining starts within minutes.
• Confusing the active context with your working machine. Running docker context use aurora-prod and forgetting about it is the recipe for a compose down in production. Always use an explicit --context.
• Building images on the production host. The build context travels over SSH, the cache is not reused and the server burns CPU on something that belongs to the pipeline. Publish and pull.
• Non-idempotent scripts. If running it twice breaks something, that is not provisioning: it is a postponed accident.
• Keeping terraform.tfstate in Git or secrets in the user-data. Both are readable: the first by anyone with access to the repository, the second from the metadata service. Remote backend with locking, and a secrets manager.
• Tip: one context per environment with a clear description, and default always active. The friction of typing --context is deliberate.
• Tip: start with cloud-init even if you only have one host; the day you need a second one, it is already solved. And document in the README who maintains each host, with which patching window and who gets notified: that page is worth more than any script.

Exercise 1 — A context and a remote audit. Create an aurora-lab context pointing at a host over SSH (a local VM or another laptop will do). Without ever activating it as the default context, check the remote daemon's version, list its containers, verify that ports 2375 and 2376 are not listening, and show how much disk Docker is using. Write it as audit-host.sh, which must return exit code 1 if it detects the daemon exposed and 2 if it cannot reach the host.

Exercise 2 — cloud-init for an Aurora Libros node. Write a cloud-config.yaml that prepares a node with: a deploy user with your public key and in the docker group, Docker Engine from the official repository, log rotation at 10 MB and 3 files, a firewall that only allows 22 and 443, SSH without passwords, unattended upgrades, and /opt/aurora ready for the compose.yaml. Validate the syntax without booting a single machine.

Exercise 3 — A reasoned decision. Aurora Libros is opening up the Mexican market and needs a replica of the platform. The facts: four developers with nobody on systems, no night-time on-call, around 40 requests per second with ×8 peaks during campaigns, 30 days of database backups, and management insists on being able to switch providers "if prices go up". Write a recommendation with the chosen option, two alternatives you rejected with the reason, and the three questions you would ask the infrastructure lead before executing anything.

Solution 1.

Key points: an explicit --context on every command (never use); docker context inspect --format derives the host without duplicating configuration; and the exit codes distinguish "I cannot reach it" (2) from "I reach it and it is misconfigured" (1), which is what lets you put the script in a cron job or a pipeline.

Solution 2.

Starting from the file in §11, you need to add three blocks and one line:

Three details make the difference: the usermod -aG docker deploy goes in runcmd and after installing Engine, because before that the group does not exist; ufw denies inbound by default and only opens 22 and 443, never 2375/2376; and there is not a single secret in the file, because the user-data is readable from the metadata service by anyone who gets onto the machine.

Solution 3. Chosen option: the application on managed Kubernetes (or Cloud Run) + managed PostgreSQL in the Mexican region.

Rejected: (a) your own hosts with Compose, which would cope with 40 req/s but would force manual scaling at the worst time of the year and would leave the operating system without an owner; (b) Fargate or App Service, which solve the operational side but collide with the portability requirement, whereas Kubernetes keeps the module 6 manifests almost as they are.

Questions to ask first: who is the declared owner of the Mexican platform and what is their maintenance window?; is there a legal data residency requirement that prevents replicating to Europe?; what is the maximum monthly budget, and would they rather pay more than hire a systems person? The third one usually decides in practice, and it is not a technical question.

You have closed the gap that was left underneath the platform: the machines. You know what Docker Machine was, what it solved with its drivers and its eval $(docker-machine env), and why it has been archived since 2021; if you see it in a tutorial or in a legacy script, you know how to read it and you know how to retire it.

What survived is in your hands: contexts. You created aurora-prod over SSH, checked the remote daemon without opening a session, deployed with docker --context aurora-prod compose up -d and understood the three traps — volumes that resolve on the server, build contexts that travel over the network, and ports that get published where you are not looking — along with the rule that follows from them: in production you do not build, you pull a signed image. And you are clear about why ssh:// beats tcp://, and why an open 2375 is not an oversight but a machine given away.

On the modern side you have the division of roles down: cloud-init so the host is born configured, Terraform or OpenTofu to create it declaratively and reviewably in a pull request, Ansible to keep the fleet free of drift and deploy the stack with idempotent modules, Packer when boot time has to be measured in seconds, and managed services for when the best way to look after a host is not to have one. With the criteria table you can defend your choice with arguments instead of taste. And you take away something that is not a command: the host is an attack surface — it gets patched, firewalled and audited — and somebody with a first and last name has to be responsible for it before the first customer arrives.

In the next lesson we put the two ways of deploying that you already know how to use head to head: Docker Compose and Kubernetes. Not as a duel, but as a decision with criteria, with exact equivalences between both formats and an honest answer to the question almost nobody asks out loud: what does it really cost to maintain a cluster.