Requirements¶
Before you install, prepare your workstation, the servers, the network, and a few accounts. The provisioner checks most of these at the start of every run, before it changes anything.
Your workstation¶
You run the provisioner from a control machine, usually your own workstation or a CI runner. It needs:
- ansible-core 2.19 or newer.
- The Python
cryptographylibrary. Some certificate checks run on the control machine rather than on the servers. dig, used to check your load balancer DNS records before the install starts. It's in thednsutilspackage (Debian/Ubuntu) orbind(macOS with Homebrew).gitandmake.- SSH access to every server as
root, by key.
The Ansible roles and collections the provisioner depends on are pinned, and installed into the project directory in a later step. You don't install them globally.
Servers¶
See the Architecture Overview for sizing. Every server must be:
- Ubuntu 26.04 LTS on amd64, freshly installed. Other distributions, releases, and architectures are rejected.
- Reachable over SSH as
rootwith a key. The provisioner doesn't usesudo, and the controller also uses root SSH to the nodes and registry at runtime. -
Named with a single lowercase word, such as
node101, notnode101.example.com. The hostname on the server must match the name you give it in the inventory.
Each server needs a private address for the control plane and a public address. They may be the same.
Ubuntu cloud images block root login
Ubuntu cloud images install your SSH key for root behind a forced command that says "Please login as the user ubuntu". Add disable_root: false to the server's cloud-init user data.
The provisioner installs everything else it needs. It disables password SSH login, and it removes ufw and ntp if they are present, replacing them with its own nftables firewall and chrony.
Container networks¶
Each container node needs a private network range for its containers:
- RFC 1918 private addresses.
- At least a
/28. A/22is typical. - It must not overlap any other network in your environment, including other nodes' container networks.
Network¶
The provisioner configures each server's firewall. Your provider's network, and any firewall in front of your servers, must allow the following.
| Traffic | Ports | To |
|---|---|---|
| Customer web traffic | 80, 443 TCP | Container nodes |
| Customer TCP/UDP services | 10000–50000 TCP and UDP | Container nodes |
| Portal, API, and certificate issuance | 80, 443 TCP | Controller |
| Certificate issuance (HTTP-01) | 80 TCP | Metrics and registry servers |
| Customer container registries | 443 TCP, 10000–50000 TCP | Registry server |
| DNS | 53 TCP and UDP | Nameservers |
| SSH | 22 TCP | Every server, from your control machine and the controller |
| Tailscale (optional) | 41641 UDP | Every server |
Traffic between servers (Docker TLS, the agent, metrics scrapes, PostgreSQL replication, and so on) is opened by the provisioner's own firewall rules, limited to the servers that need it. If a region reaches the other servers over the public internet rather than a private network or Tailscale, your provider's firewall must also allow:
| Traffic | Ports | From | To |
|---|---|---|---|
| Docker TLS and the agent | 2376, 8500 TCP | Controller | Container nodes |
| Metrics scrapes | 9100, 8080, 81 TCP | Metrics server | Container nodes |
| Node metrics scrapes | 9100 TCP | Metrics server | Every server |
| Certificate service | 3000 TCP | Container nodes | Controller |
| Log shipping | 3102 TCP | Container nodes | Metrics server |
| Backups (borg over SSH) | 22 TCP | Container nodes | Backup server |
Every server also needs outbound HTTPS to download packages and images, including from download.docker.com, apt.postgresql.org, repo.computestacks.com, ghcr.io, Docker Hub, and GitHub.
Remote regions and cleartext traffic
Without a private network or Tailscale, the controller's requests to each node's agent and Prometheus's scrapes of each node cross the public internet unencrypted. That is a supported choice, but make it deliberately. See Tailscale.
If port 80 can't be opened to the internet on the controller, metrics, or registry servers, use a DNS-01 challenge for their certificates instead. See TLS certificates.
Accounts¶
Required:
- An email address for your ACME certificate authority account. The default CA is ZeroSSL; Let's Encrypt, Google Trust Services, Buypass, and SSL.com are also supported.
- Control of a public DNS domain for the portal, metrics, registry, and customer container hostnames. See Prepare DNS.
Optional:
- A Tailscale auth key, to encrypt control-plane traffic between sites.
- An Ubuntu Pro token, for Livepatch.
- API credentials for your DNS provider, if you use DNS-01 certificate challenges.
- A Sentry DSN, for error reporting from the controller.
- S3-compatible storage keys, for exports.
The ComputeStacks controller image is published publicly at ghcr.io/computestacks/controller, so no registry credentials are needed to install it.
Next steps¶
Continue to Prepare DNS.