Firetower

Firetower is an open-source, self-hosted control plane for coding agents. It lets you run any coding agent — including Claude Code and Codex — on your own servers and manage them from a desktop or mobile client, from anywhere. You give Firetower a machine you can SSH into and a repository, and it handles the rest: picking a host, cutting a branch, making a worktree, starting tmux, launching the agent, and keeping it running. The product is aimed at developers and teams who want to run coding agents on infrastructure they control rather than on the device they start the work from. Its main purpose is to run coding agents on servers you own, keep them running reliably, and tell you the moment a session stops being useful without you. The problem Firetower addresses is that coding agents traditionally run on the device you started them from. If your laptop closes or the app crashes, the work is interrupted. Firetower changes that by running the agent on a server instead. Because the agent runs on your server, not on the device you started it from, every device can pick up exactly where another left off. Closing your laptop costs nothing, because the agent never ran on the laptop. Firetower also treats failure as something each part can experience on its own: if the Firetower server goes down, the workers keep running; if a worker dies, the worktree is still there, and your branch and every file the agent changed remain on that machine. By making each part independently resilient, the work survives every one of these failures. Firetower brings an entire workflow into one place. The flow runs from issue to shipped: you start from your Issues and Linear tickets, your agent runs your worktrees, you preview and annotate, and then you commit and open a PR. Firetower reads from your trackers as you look, and starting a ticket opens a workspace. A ticket list shows items such as "Add a dark mode toggle," "Fix the invite link on mobile," and "Rate-limit the webhook receiver," each with an ID, team, and how recently it was updated, with a Start action. This workflow ties the tracker, the agent, the diff, and the pull request together so the whole path from a ticket to a shipped branch stays in one surface. Firetower is designed so you can run remotely and close your laptop anytime. The agent runs on your server, not the device you started it from, which means you can pick up your phone and continue. If your laptop closes or the app crashes, nothing happens to the agent, because it never ran on the laptop; open Firetower on any other device and the conversation is exactly where you left it. If the Firetower server goes down, the workers keep running, and when the server comes back it catches up on everything that happened while it was away. If a worker dies, the worktree is still there — your branch and every file the agent changed are on that machine, and Firetower still knows about them, so you can restart the worker and carry on. Firetower runs your favorite agent on your favorite hardware. It reaches each machine over SSH and starts a worker there, and the agents run on that machine — in tmux, on their own worktree. Clients are available for macOS, Windows, iOS, and Android. Firetower is written in Rust and is described as the most efficient ADE on the market, with a small core, no accumulating terminal daemons, and workspace memory ceilings where the host supports them, built for work that keeps running. Its resource profile is presented in comparison charts: Firetower Desktop uses about 50 MB where a competing app and daemon report roughly 1.5 GB idle (30× more efficient); a Firetower worker uses about 5 MB with the agent CLI separate, where a competing agent process reports about 500 MB per agent (100× more efficient); and the Firetower control plane uses about 200 MB where a competing service reports about 1 GB after restart (5× more efficient). Firetower's unique approach rests on the idea that workers are authoritative. Workers write what happened to their own log before reporting it, and when the control plane comes back it asks for everything since the last thing it saw — so a closed laptop costs nothing and a reconnect is a replay, not a guess. The worker never opens a port: it reads frames from stdin and writes them to stdout, so who dials is a transport detail — a child process, a container exec, or SSH. The daemon cannot tell the difference, and neither can a firewall. In the architecture, desktop and mobile apps connect over HTTPS to the Firetower control plane, which is one compose file on a server you already own; the control plane then reaches machines over SSH, including a Mac Studio worker with tmux and git running Claude Code and Codex, and a Hetzner VM worker running Claude Code. Session indicators show a session that has stopped and needs you, one still working with nothing to do, and the SSH path the app uses to reach a machine you own. The benefits follow directly from this architecture. Because agents run on your own servers, closing your laptop costs nothing and you can continue from any device. Because each agent is on its own machine and in its own worktree, failures are isolated, and the work survives each of them. Because Firetower tells you the moment a session stops being useful without you, you can stop watching agents that need nothing and focus only on the ones waiting on you. Because workers are authoritative and reconnect as a replay rather than a guess, the state you see reflects what actually happened. And because Firetower is written in Rust with a small core and a small memory footprint, it is built for work that keeps running without consuming the resources a heavier tool would. Concrete scenarios include starting a task from a Linear or GitHub ticket so the agent begins work in a workspace automatically; running an agent on a Mac Studio or a Hetzner VM over SSH while you continue from your phone; closing your laptop mid-session and reopening the conversation on another device exactly where you left it; reviewing a diff and annotating it before committing and opening a pull request; and restarting a dead worker and carrying on because the worktree still holds the branch and every changed file. The workflow from issue to shipped — start from Issues and Linear tickets, run worktrees, preview and annotate, commit and open a PR — covers the day-to-day path a developer follows with an agent. Firetower is built for developers and teams who want to run coding agents like Claude Code and Codex on infrastructure they control. It integrates with trackers and source control: you start from your Issues and Linear tickets, and GitHub is among the connected sources (you can commit and open a PR). Its tech stack includes Rust as the implementation language, plus tmux, git, and SSH as the mechanisms that run agents each in their own worktree on a machine you own; the control plane is described as one compose file on a server you already own. Firetower is open source and self-hosted with no account required, and it installs in about five minutes on your server with a simple install command. Firetower's primary value proposition is control: it runs any coding agent on your own servers, from anywhere, and keeps the work running even when your laptop, the server, or a worker fails. By combining a self-hosted control plane, an issue-to-PR workflow, authoritative workers, and a small Rust core, it lets developers use the agents they already prefer on the hardware they already own — open source, no account, and built for work that keeps running.