Documentation
Firetower is a control plane for coding agents. Give it a machine you can SSH into and a repository, describe some work, and it cuts a branch, opens a worktree, starts tmux and keeps the agent running — then tells you the moment it stops being useful without you.
Two ways to run it:
- Host it yourself — the app on a machine you control, and a worker on every machine that should run agents.
- Firetower Cloud — the app runs for you. Coming soon.
Quickstart
Getting started→Two ways to run Firetower — host it yourself today, or the cloud when it arrives. What each one asks of you.Key concepts→The three parts of Firetower — the Firetower itself, a worker on every machine that should run agents, and the client you open — and how they fit together.Install the Firetower→Install the Firetower — the control plane — with the CLI: what it asks, what it checks, and what it writes.Add a machine→Run sessions on a machine you already own: give it Firetower's key, add it over SSH, and Firetower installs the worker.Connect GitHub→Register the OAuth application a Firetower authorises against, turn on its device flow, and connect your GitHub account — with the one checkbox everybody forgets.
Core concepts
Users and teams→Adding a person: the form, the password the server makes and shows once, and the one thing they have to do before anything else works. Resetting a password, switching somebody off, and removing them.Permissions→The four layers of permissions: people, teams, directories and resources. How ownership follows a directory, what stays yours whatever happens, and how to share one thing with one person.Organise your resources→What to set up at three sizes: on your own, two to five people, and ten or more with different infrastructure. Why a team says who somebody is and a directory says which pool they reach, and when you need both.Sharing a resource→Two ways to let somebody at one of your things: move it into a directory and hand it over, or name them on it and keep it. Which to pick, and how to do each.Sharing a workspace→A workspace holds a place and the conversations in it. The place is shared like anything else; a conversation belongs to whoever started it, because it spends their subscription and commits in their name.Update→Updating from the Updates screen: check for a release, see what the run would write and what it would end, watch it go, and bring each machine level with the deployment. Who may update what.
#Start here
Getting started is the short version of the choice. If you already know you want to host it yourself, how self-hosting works explains the two things you run, and Install is the two-minute version.