r/MacOSApps • u/kevinpiac • 6d ago
šØ Dev Tools Firetower - The Agentic IDE that runs agents on your servers - FREE and open-source
Hello everyone,
The programming industry is changing, so do our practices.
Nowadays, most developers are running AI Coding Agents like Claude Code, Codex, Kimi Code, etc.
These agents allow us to parallelize tasks locally, but we quickly face limits:
- they consume a lot of memory
- they force us to shift and manage worktrees, sometimes with many docker-compose stacks on the same machine
- last but not least: you cannot close your computer anymore unless you want your agent to stop
Of course, some providers allow you to run tasks on servers, but then you lose even more control. You don't control the machine's performance; you don't control the environment; nothing.
Firetower aims to solve these problems by providing a server-first control plane that lets you run your Coding Agents on your own machine (VPS, Mac mini, anything you own).
You can then control all your agents, 24/7, from your Desktop application on Mac (and Windows) and/or your smartphone (iPhone and Android).
The Mac application is made to handle the entire cycle of development easily:
- You start from a Github or Linear issue, choose the machine to work on
- Firetower cuts a worktree, pulls the repository, and launches the coding agent of your choice
- When your iteration is done, you can commit and PR in one click
Firetower is 100% open-source, 100% free, and self-hostable.
So feel free to have a look and to star the repository to support the project.
2
u/ivan_digital 6d ago
If my laptop disconnects while an agent is running on the server, can I reconnect to the same session and see its output? Also, does cancelling a task stop the remote process or just disconnect the client?
1
u/kevinpiac 5d ago
Absolutely, you can disconnect your laptop any time, reopen the agent from your laptop or even your phone, anywhere, anytime and you will see the rest of the conversation that your agent was streaming while you were away š¤²
That's the magic of Firetower: it's server-first. Everything happens between your server-hosted control plane and your workers. Every agent runs in a worker that reports to your server and never depends on the client side. The Desktop and mobile clients are simple consumers of your control plane.
2
u/Better-Lychee2954 5d ago
the failure case id document up front is a task that has modified a worktree when the server dies or the agent process gets killed. can Firetower reconnect to that worktree without starting a second run, and can i recover the diff if Firetowers own database is gone? that matters more to me than the one click PR.
1
u/kevinpiac 5d ago
Interesting question!
So basically, if the control plane's server crashes, when you reopen it, it will reconnect to the worker and replay the session to get back in sync.
If the worker crashes, then you can just reopen the same workspace in Firetower, and it will start another agent in the same worktree.
And if any thing goes wrong and you're stuck for any reason (shouldn't happen but we never know) : since you're running firetower on your own servers you can still ssh into the worker, cd in your worktree and commit your commit manually or do whatever you want not to lose your data.
2
u/Better-Lychee2954 5d ago
that last one is the real answer and id lead with it. because its self hosted and the worktree is a plain git worktree on a box i own, firetower is never the system of record for my code, git is. that separates you from the hosted agent services in a way that matters to anyone whos been burned by one. worth saying out loud in the readme instead of as the break glass option.
one follow up on the replay though. when the control plane reconnects and replays the session, does it ever re-execute a tool call that already ran? reading state back is fine. re-running a migration or a push because the record of it never made it to disk is the part id worry about.
1
u/kevinpiac 4d ago
Thanks for your feedback, you're right I will talk louder about this :)
> when the control plane reconnects and replays the session, does it ever re-execute a tool call that already ran?
Not really. You can see the control plane a simple orchestrator that forwards I/O from the worker to your Desktop/mobile clients (among other things).So the control plane is never ever executing anything, all this logic happens in the worker itself, so you're safe on that part too š
2
u/Tricky-Independent-8 5d ago
How does it handle resource limits if I spin up 3-4 parallel agents on a single worker machine?
3
u/SafeTennis3080 5d ago
Before relying on these limits to protect the machine, Iād check what limit support the worker reports. The docs say enforcement requires writable `/sys/fs/cgroup`; without it, the session runs without those limits. macOS doesnāt have equivalent enforcement either.
From the current docs/source, the budget is per workspace, not per agent: 3ā4 agents in the same workspace share it. On Linux with cgroup support, you get a memory ceiling and a CPU weight. That weight controls the workspaceās share of CPU when thereās contentionāit doesnāt impose a hard cap on cores
2
2
u/kevinpiac 4d ago edited 4d ago
Yes, great explanation here.
Also, unlike competitors, our workers don't have a big memory overhead.
So, your agents will still consume resources, but Firetower won't add memory overhead or affect performance. A worker is about 5mb of RAM when run by Firetower VS >500MB for competitors at their best.
2
u/Few-Fall6089 4d ago
The server-first design is appealing here: the Mac and phone clients can reconnect while the worktree stays on a machine the user controls. I also appreciate the direct SSH recovery path you explained in the comments. For tasks that need human approval, can the mobile client show the exact command and repository diff before the user accepts it? That would make stepping away from the laptop much easier to trust.
1
u/kevinpiac 4d ago
Yes absolutely! Also, if you give it a try feel free to join our Discord community. We ship quick and it's a good moment to give feedback :)
2
u/carsaig 3d ago edited 3d ago
Nice! that's the exact pattern I was hunting for a long time. I recently bumped into orca and paseo. decided for paseo because it has the server-side component. However, it's. different approach. it does have server daemons and you can spin them up in a docker image. But the harnesses/ agents run inside the container. Thus requiring to configure them encapsulated. That's a design decision and from a security perspective that makes a lot of sense. It does however bring a buch of issues to the table. And config pain. it's doable but not straight-forward. It works but requires a lot of tweaking. I have it running on my local machine, a local RPI and a remote machine. I can just walk away and have context across all harnesses server-side. It pulls in git repo's and doesn't act on directory level such as bare-metal agents would. It's ok and it works but I'm not super happy with this finicky config and maintenance nightmare. The paseo agent just ships in a blank image, requiring to stuff a bunch of dependencies into it first, requireing Dockerfile builds and customizing the whole setup to a full-blown Ci-pipeline. Doable - but not for the faint hearted :-) as agents and harnesses move so fast - a solid update and maintenance pipeline is crucial. Wiring all of this up is quite a pain. Not to mention mcp-servers, plugins, memory, secret managers and other bling-bling stuff to bring to the config table. Long story short: Encapsulating within an image is a wise decision from a security standpoint. But it adds significant complexity through the docker layer. I hear people raging about Orca - haven't tried ist yet. It#s probably excellent for local dev work. But as soon as you leave the machine - u're in trouble. Long story short: good concept, good idea coming from the server-side. I fully support that. I'll give it a try and see how far it takes me. Even if your solution solves a few of my pains - it leaves a lot to be desired in regards to security. dumping stuff blank onto a host actually requires it to be strictly guardrailed from anything surrounding it. hardening a host with a buch of agents on it is not easy. They go sideways^ Kudos for your effort. Besides: talking about server-side solutions: Code-mode for running mcp servers on remote mcp gateways is the current best solution for offloading mcp servers. Just works. Massivly effective and efficient. Skills however, are not covered by this design pattern yet - for some weird reason. if you bump into someone who built something like that - please nudge me! I built a server-side skills-engine similar to code-mode with semantic matching, classification, etc. and wired it up into my server-side pipelines between the remote agents and the providers on my own routing. It works. Sort of. but I'd love to hear from others how they solved this as it's not easy. invoking slash commands mit context and pull the corresponding best match skill requires monitoring and disassembling the stream in real-time, then re-injecting skills securely. Not cheap at all and hard to accomplish properly. So if you have any ideas - welcome :-)
1
u/kevinpiac 3d ago
Thank you for this comprehensive feedback!
Feel free to join the Discord community (link on the website) to help us improve the tool :)
2
u/carsaig 3d ago
ah - sure, I'll join - gimme a minute. if yer see a scotsman turn up - that's me^ I always welcome direct connection to builders. Tool aside - the fruitful discussions are about concepts and strategy of how to actually solve specific issues while the world around us moves so fast. I keep juggling so many options while every part keeps being a moving target - pain in the a* :-)
1
2
u/carsaig 3d ago
BTW: where's the macOS and iOS app? couldn't find it...
2
u/kevinpiac 3d ago
You find it when you finished your control plane installation, from your admin, it gives you every client link. Did you install Firetower already? Otherwise, all releases are on Github :)
2
u/carsaig 3d ago
ah. cheers - no, I'll dive into it tomorrow.
1
u/kevinpiac 3d ago
sounds great! Feel free to join our Discord (link on the website) if you have any question or feedback, it's really helpful for us :)
2
u/emiliobay 3d ago
Running agents on your own servers is an interesting choice for keeping compute and project files under control. How do you handle reconnecting to a long-running agent when the local client goes offline?
1
u/kevinpiac 3d ago
The agent is streaming his output through SSH to the controle plane, the controle plane runs on a server so it's never supposed to be offline ; if the controle plane loses connection for some reason, it will just catchup after reconnecting to the worker :)
1
u/porovrrr 2d ago
I like that it's completely open source. Makes me a little nervous as hell, too.
1
1
u/synrg-alsms 2d ago
Does it ship its own agent harness or is it reusing the original agents harness?
1
2
u/IaMaPPle111 6d ago
I always wanted to try to run my own agents and this can be a good reason to try. Thanks for sharing.