Hi Product Hunt — maintainer of apra-fleet here. First launch.

The shortest way to explain what we built: apra-fleet builds itself. Every sprint, it plans work from our issue tracker, dispatches it across our machines, has a different AI provider review each change, runs the integration suite, files bugs against itself, and fixes them the next cycle. The dashboard recording in the gallery is a real run, not a mockup.

What it is: a control plane for AI agents. It runs them across your real machines — laptops, build servers, VMs — and mixed providers, and keeps long unattended work alive.

It started as a practical annoyance. One agent is easy. We had several machines, several provider subscriptions, and no sane way to use them together. We wanted premium models only where judgment matters (planning, review), cheap or local models for mechanical work, and long runs nobody has to babysit. Nothing we tried did that, so we built it.

The idea I'd defend hardest: explore with agents, operate with programs. You pay tokens while an LLM discovers a workflow; once it's understood, it becomes a deterministic program that runs the mechanical steps for free and calls a model only for actual judgment. Our own e2e setup step went from a few dollars per run to roughly zero. One measured example, not a benchmark — but it's the cost curve the whole design aims at.

Which is why the workflow engine doesn't know what a sprint is. It runs durable programs; software delivery is just the domain we've proven it on hardest. Two of many in production today, neither of them code: tracking cloud spend across a large-scale SaaS deployment, and reconciling construction project financials across structured and unstructured sources.

We've been our own primary users for eight months, which is where most of the past year went: stall detection, crash recovery, resumable state. Unglamorous, and everything depends on it — a fleet you have to watch is worse than no fleet.

Honest status, so you hear it from me and not the comments: single autonomous sprints on a fleet you register are solid — that's our daily driver. The multi-sprint supervisor dashboard is a preview, and some permission setup is still manual. Apache-2.0 and free; you bring your own LLM subscriptions or API keys.

Quick start is genuinely five minutes:

npm install -g @apralabs/apra-fleet
apra-fleet install
~/.apra-fleet/bin/apra-fleet start

Source, issues, and the workflow engine internals: 
https://github.com/Apra-Labs/apr...

I'll be here all day — questions, skepticism, and "why not just use X" comparisons all welcome.

Hi Product Hunt — maintainer of apra-fleet here. First launch. The shortest way to explain what we built: apra-fleet builds itself. Every sprint, it plans work from our issue tracker, dispatches it across our machines, has a different AI provider review each change, runs the integration suite, files bugs against itself, and fixes them the next cycle. The dashboard recording in the gallery is a real run, not a mockup. What it is: a control plane for AI agents. It runs them across your real machines — laptops, build servers, VMs — and mixed providers, and keeps long unattended work alive. It started as a practical annoyance. One agent is easy. We had several machines, several provider subscriptions, and no sane way to use them together. We wanted premium models only where judgment matters (planning, review), cheap or local models for mechanical work, and long runs nobody has to babysit. Nothing we tried did that, so we built it. The idea I'd defend hardest: explore with agents, operate with programs. You pay tokens while an LLM discovers a workflow; once it's understood, it becomes a deterministic program that runs the mechanical steps for free and calls a model only for actual judgment. Our own e2e setup step went from a few dollars per run to roughly zero. One measured example, not a benchmark — but it's the cost curve the whole design aims at. Which is why the workflow engine doesn't know what a sprint is. It runs durable programs; software delivery is just the domain we've proven it on hardest. Two of many in production today, neither of them code: tracking cloud spend across a large-scale SaaS deployment, and reconciling construction project financials across structured and unstructured sources. We've been our own primary users for eight months, which is where most of the past year went: stall detection, crash recovery, resumable state. Unglamorous, and everything depends on it — a fleet you have to watch is worse than no fleet. Honest status, so you hear it from me and not the comments: single autonomous sprints on a fleet you register are solid — that's our daily driver. The multi-sprint supervisor dashboard is a preview, and some permission setup is still manual. Apache-2.0 and free; you bring your own LLM subscriptions or API keys. Quick start is genuinely five minutes: npm install -g @apralabs/apra-fleet apra-fleet install ~/.apra-fleet/bin/apra-fleet start Source, issues, and the workflow engine internals: https://github.com/Apra-Labs/apr... I'll be here all day — questions, skepticism, and "why not just use X" comparisons all welcome.

Wispr Flow: Dictation That Works EverywhereStop typing. Start speaking. 4x faster.

Promoted

apra-fleet

Maker

📌

4d ago

@apralabs @kumaakh I've been using fleet sprint recently and could add a machine tracking feature to an existing video management solution tool that already detects forklifts overnight! It has enabled me to produce quality work at the speed everyone expects AI to work at.

2d ago

@apralabs @kumaakh The whole idea of running the Orchestrator on a single machine while having the ability to deploy remote members across thousands of machines has enabled me to add tools that not only provide observability but also help suggest solutions for the identified issues.

1d ago

apra-fleet

Run a fleet of AI agents across your machines

Run a fleet of AI agents across your machines