A server
Agents are containers, and containers need a machine that stays on. The cheapest row on any provider's list is enough, and every one of those providers asks you the same five questions under different names.
Something has to be awake when you are not
An agent that wakes at nine on a weekday, or the moment a build fails, is an agent on a computer that did not go to sleep with the lid. That is the whole argument for a server, and it is why the requirement is so small: this is a machine that idles nearly all the time and thinks in bursts, and the thinking happens at whichever model provider you gave a key to rather than here.
So the bottom of every list runs it. One vCPU, a gigabyte of memory, ten gigabytes of disk, any Linux with SSH on it. The installer brings Docker if the machine has none. An old laptop under the desk does just as well, and so does a machine at work you can reach — nothing below is specific to renting.
Four that are cheap, and the difference between them is not squad
| Hetzner | the most machine for the money — around €4.50 buys two cores and 4 GB, in Europe and the US |
| Linode | $5 for one core and 1 GB, in eleven regions, and the plainest create screen of the four |
| Vultr | from about $5, and in more places than the other three put together |
| DigitalOcean | a few dollars more, and the most written about — worth it if this is your first server |
Prices move, so read those as the shape rather than the quote. What does not move is the shape of the bill: the machine is a flat monthly number, and the only other cost is what the agents think with — metered by the model provider, and capped by limitUsd at five dollars a day per agent until you say otherwise. There is nothing to pay for squad itself.
Five questions, wearing four sets of names
Every provider's form is the same form. Hetzner calls the machine a Cloud Server, Linode calls it a Linode, DigitalOcean calls it a Droplet and Vultr calls it an Instance, and underneath the words they ask you this:
| region | Where the machine physically is. Latency does not matter here — nobody is typing at this thing, and an agent that wakes at three in the morning does not care about forty milliseconds. Pick the country whose law you would rather your data sat under, or the one nearest you, and move on. |
| image | The operating system. Ubuntu LTS or Debian stable, and this page assumes one of those. Anything with SSH and a package manager works; the installer brings Docker itself, so a picture that already says Docker on it buys you nothing. |
| size | The bottom of the list. One vCPU, a gigabyte of memory and ten gigabytes of disk runs a few agents — that is the cheapest row on every provider's page, and the one to click. |
| authentication | An SSH key, or a root password. This is the only row on the form worth stopping at, and the next section is the whole of it. |
| the rest | Backups, monitoring, private networking, a floating IP, a firewall. All off. None of them is needed to start and each is a line on the bill. |
A minute after you click create there is an IP address on the screen. That address, and a way in, is everything squad needs from this provider — nothing here has to be configured for it, and no port has to be opened.
A key and a password are both ways in, and one is not worse
A key is a file on your computer that the server recognises. A password is a string the provider mails you or shows you once. Both get you in, both are what squad rides, and the real difference is that a password has to be typed again and a key does not.
If the form offers to take a key, give it one. Yours is probably already there, and this prints it:
$ cat ~/.ssh/id_ed25519.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI… you@your-laptop
No such file or directory means this computer has never spoken SSH, which is not unusual and is one command to fix:
$ ssh-keygen -t ed25519
Press return through its questions. It writes two files — id_ed25519, which is the secret and never leaves this computer, and id_ed25519.pub, which is the line you paste into the provider's box. An older machine may have id_rsa.pub instead; that works too.
If it does not, or you would rather not, take the root password. A server bought this morning with a password in an email is a perfectly good starting point, and squad expects exactly that case — the next section is what it does about it.
One address, and it finds out the rest by trying
Where should your agents live? 1 On this computer a container here, and Docker is what runs it 2 On a server a machine you have SSH to. A $5 VPS is enough 1 or 2 2 Which machine? Anything ssh can reach. The prompt already reads root@, so a bare host finishes it. An empty line says you have not got one yet. root@203.0.113.9
The prompt already reads root@, so the IP address the provider just gave you finishes it. A name works as well as an address, and so does a host out of your ~/.ssh/config — anything ssh can reach. An empty line is the answer for somebody who has not bought one yet, and prints the list above rather than an error.
What happens next is one connection that tries the key and nothing else. If the machine takes it, that connection is the one the install and the console then ride, and you were never asked anything. If it turns the key down, there are exactly two things to do about it and you are asked which:
203.0.113.9 does not take this computer's key. 1 Put one up appends it to authorized_keys, and nothing asks again 2 Keep the password asked once per connection, and one lasts ten idle minutes 1 or 2
Put one up spends the password once. Your public key goes up on the same connection the password opens, appended to authorized_keys and nothing else touched, and nothing after that asks — not the install, not the console, not a port forwarded out of a sandbox later. Run it a second time and a key already in the file is left where it is.
Keep the password is a real answer and not the consolation. It is asked once per connection, and a connection lasts ten idle minutes, so it is typed about as often as you walk away from the machine — and never in the middle of anything, because the connection is always opened first, on a bare terminal, before the console is drawn.
The question is asked as a preference, because it is one. A key does not appear on your server because the program preferred it, and a password is not treated as the weaker way in. Where the connection dies of something else — a name that does not resolve, a host key that changed — you get what ssh said rather than a password prompt on top of it.
One script, and nothing of the console stays behind
The console pipes a single shell script down that connection. It installs Docker if there is none, puts the repository in /opt/squad, writes a config with one agent and a ceiling of five dollars a day, starts the plane and leaves squad on that machine's PATH. Then it drops you on the console, here, on your own computer.
That script stands alone, and running it at the server's own terminal is the same install with the questions it can only ask when somebody is there to answer:
$ curl -fsSL https://squad.mormon.garden/install.sh | sh
Running it again is the update — it pulls, rebuilds and swaps the plane in, and never touches config.yaml or .env. squad update does that from your own keyboard, on whichever machine the plane is on.
There is no port, so there is no firewall to write
The control surface is a unix socket in the state directory and it never leaves the machine. Nothing is published, nothing listens for you, and there is no account to make or token to issue: SSH already decides who may touch that host, and touching that host is the whole of what holding the socket means. So the provider's firewall can stay exactly as their default left it.
The one exception is deliberate and you opt into it. Webhooks publish port 8787, which takes signed requests only — and you only need it if something on the internet has to be able to wake an agent. Telegram and mail need nothing published at all, because they reach out rather than being reached.
Why there is no web UI to log into. The control plane holds the Docker socket, so it is root-equivalent on the machine — the trust boundary is the sandbox around the agent, not the process managing it. Publishing that control surface would be putting root on the internet behind a password somebody chose. Trust has the rest of what that does and does not claim.
The answer is remembered, and one command moves it
Where the agents live is asked once and kept in ~/.squad/plane.json. squad connect asks again — so a plane that started on your laptop moves to a server you bought later, and a server you are done with is replaced by another, without reinstalling the console.
Everything after that question is the same program. A plane answers the same protocol whether its socket is in a directory on this computer or at the far end of an SSH connection, which is why the console, a forwarded port and the log feed all behave identically either way.