Key concepts
You run two things: the Firetower, once, and a worker on every machine that should run agents.
The Firetower reaches your machines over SSH. The worker is one binary on the machine, started by sshd when the Firetower connects; it never opens a port and holds no credentials of its own. You connect to it from a native client — and because neither it nor the agents live on your laptop, closing that changes nothing.
#Architecture
#The client
A native app: Firetower for macOS, for Windows, and for iOS and Android. It is where you read a session, talk to an agent, open a shell and look at a preview.
It holds a URL and a token per server, so one app can sit in front of several Firetowers at once and read across them. Nothing about a session lives in it.
That is the point of the split. The agents are not running on the machine you are looking at them from — they are running in a worker, in tmux, on a machine that does not sleep. Close the laptop, quit the app, run out of battery: the work carries on, and the app catches up on the way back in.
#The Firetower
What it is for. You describe a piece of work. It decides which machine runs it, gets it running, and keeps it running after you have stopped watching.
Concretely: it picks a host, cuts a branch, makes a worktree, starts tmux and launches the agent on your own subscription — then stays with the session. It notices when a turn ends, when the agent is stuck waiting on an answer, and when it is asking for permission. That is the inbox you come back to.
It is also the only thing that remembers. Your machines, your repositories, your git tokens and agent credentials, every session and everything each one said — all of it lives here. Which is why there is one per team rather than one per person, and why it is the part that has to stay up.
Three containers, brought up by firetower install:
- firetower — all of that, compiled into one binary.
- postgres — the entire state, with every credential sealed.
- caddy — the reverse proxy, and the only service that publishes a port. It terminates TLS for the name every deployment has, on one address and nowhere else.
The control plane publishes no port. Only Caddy is reachable, on the one address you chose — a tailnet address, usually.
#The worker
One binary per machine, firetower-worker, in ~/.firetower/worker/bin of
the account agents run as. Agents run on the machine itself — as that account,
with that machine's tools, its filesystem and its network. The machine is the
unit of isolation: a VM of its own when you want one, the machine itself when
that is the point.
It does nothing on its own — Firetower SSHes to the machine and runs it when it wants to talk, and it exits when the Firetower hangs up. Agents outlive that under tmux. No daemon to keep alive, no port to open, no key on the machine but the one you gave it.
Each worker writes what happened to its own event log before reporting it, so a session survives the Firetower being unreachable.
Note
The machine running the Firetower is also a host. The control plane starts a worker
as a child process, so localhost appears in the fleet, runs sessions, and can
be drained.
#What you actually have to do
- Run the Firetower. One command on any machine that can reach the internet. → Install
- Add a machine for every machine that should run agents: give it Firetower's key, add it under Compute, and Firetower installs the worker itself. → Add a machine
Step 2 is optional. A new install already has one host — itself — and runs sessions there.
#Shapes that work
| Where the Firetower runs | Where workers run | Good for |
|---|---|---|
| One machine | The same machine | Trying it, and small teams. Nothing else to set up. |
| A small VPS | Bigger machines you add over SSH | Keeping the thing you expose small and cheap, and the compute separate. |
| Your laptop | Cloud VMs | Working locally while the agents run somewhere that stays awake. |
The work happens on the workers. Size those; the Firetower only holds state and answers the clients.
This loses work
Back the root key up separately from the database. A database backup on its own cannot be decrypted; stored beside the key, it can.
#Next
Install takes about two minutes and leaves you with a running Firetower on one machine.