Apra-fleet
About
Run a fleet of AI agents across your devices, your providers, your workflows.
Details
- Author
- apra-labs
- Categories
- Developer Tools
Jump to
Setup
Install Apra-fleet in your MCP client (Claude Desktop, Cursor, Windsurf, and others).
Repository: https://github.com/apra-labs/apra-fleet
Follow the installation instructions in the repository README, then restart your MCP client.
Run a fleet of AI agents across your devices, your providers, your workflows.
What Kubernetes did for containers, apra-fleet does for AI agents: scheduling, credentials, isolation, and observability for an agentic workforce -- on any machine, anywhere, using every LLM provider at once.
Quick Start-Live Demo-How It Works-fleet-sprint Getting Started Guide-Website
This repository is built by the product you are looking at.An autonomous apra-fleet workflow plans, codes, reviews, tests, and ships this codebase in multi-hour sprints -- filing bugs against itself and fixing them. The recording above is a real run, not a mockup.
Running one AI agent is a demo. Running fifty -- across a MacBook in the office, a GPU box in the lab, three cloud VMs, and your CI -- is an operations problem nobody else has solved:
- Which machine runs which agent?Real devices, not throwaway sandboxes: registered, credentialed, health-checked members you already own.
- Which model does which job?Claude for review, a cheap tier for mechanical edits, a local vLLM model for private data -- all in one fleet, routed by cost tier, switchable per task.
- Who watches the agents?Durable workflows with supervisors, watchdogs, reservations, and live dashboards. Agents that die get detected. Work that stalls gets resumed. Nothing runs silently.
- Who holds the keys?Secrets entered out-of-band, never visible to any model. Per-provider permission composition. Network egress policy per credential.
One control plane. Any device. Any model. Any workflow. Any domain.
Our flagship workflow,fleet-sprint, develops software autonomously: plan -> develop -> review -> deploy -> integration-test -> harvest, in cycles, until the goal is met or the evidence says stop.
It is not a toy. It builds apra-fleet itself:
- Multi-cycle sprints running for hours, unattended
- 2,300+ unit tests and an 81-file integration suite against real backends
- Files bugs against itself, decomposes them, fixes them, and blocks its own release until quality gates pass
- Every dispatch, verdict, and dollar visible live on the dashboard
- Every sprint's raw child stdout/stderr is captured to a per-sprint log and linked from the dashboard, so a run's output is traceable even if it crashes before reporting anything back
pm-1 Opus (premium) orchestrator doer-1 Sonnet (standard) feature work doer-2 Antigravity large-context tasks reviewer Opus (premium) final review
The engine does not know what a "sprint" is; it knows how to run your workflow reliably across your fleet (seeAny domainabove).
1. Install-- one command via npm (Node.js 22+), or grab the standalone installer binary for your platform fromReleasesand double-click it (installation is the default action):
npm install -g @apralabs/apra-fleet apra-fleet # installs for Claude Code (default) apra-fleet --llm agy # or OpenCode/Codex/Copilot cd ~/.apra-fleet/bin && apra-fleet start # start the apra-fleet
2. Connect your agent.Load the fleet server in Claude Code with/mcp(or restart your provider CLI). Your agent now has a fleet.
3. Register members -- in plain language.apra-fleet is driven conversationally through any MCP-capable agent:
"Register a local member calleddoer. Register another calledreviewer. Pair them."
"Register 192.168.1.10 asbuild-server. Username akhil, work folder/home/akhil/projects/myapp."
Remote passwords are collected out-of-band -- typed into a separate terminal, never the chat -- used once to set up SSH keys, then forgotten.
apra-fleet workflow fleet-sprint \ --issue my-project-epic --members doer \ --branch fleet-sprint/first-run --base main
Open the dashboard, watch your fleet PLAN->BUILD->REVIEW->TEST->SHIP in a loop till closure
New to fleet-sprint?Read thefleet-sprint Getting Started Guide(Markdownif you're reading this on GitHub --PDF) -- a plain-English walkthrough of what it does, what you need to prepare (beads backlog,deploy.md, test playbooks, member registration), how to launch and monitor a sprint, and what's automated versus what's still your call.
Running fleet-sprint after npm install:theapra-fleet workflow fleet-sprint ...command above is the same one command for everyone -- whether you installed vianpm install -g @apralabs/apra-fleet, the standalone binary, or a git-clone dev checkout. There is no separatefleet-sprintcommand to install or remember. Seethe full flag referencefor every option.
Component Docs:fleet-sprint|auto-sprint.js|apra-fleet-client|apra-pm|apra-fleet-mcp|Agent Roles
flowchart LR CP["Control Plane<br/>(Server, Engine, Supervisor)"] -->|Dispatch & Sync| M1["MacBook<br/>(Claude)"] & M2["Linux GPU<br/>(vLLM)"] & M3["Cloud VM<br/>(AGY)"] & M4["Windows<br/>(OpenCode)"]
- Fleet server: the control plane. Registers members, dispatches commands and prompts, moves files, brokers credentials. Speaks MCP, so any MCP-capable agent can drive a fleet.
- Members: real machines running provider CLIs. Composes provider-native permissions before every dispatch; unattended modes are scoped, never blanket.
- Workflow engine: runs workflow programs with phases, retries, turn budgets, resumable sessions, per-activity persistent state, and a cooperative pause/resume gate any workflow can hook into.
- Supervisor: always-on layer -- launch, pause/resume, & stop sprints over HTTP, member reservation ledger, crash watchdog (including a live "paused" state and base-branch-drift indicator), run history.
Every agent session starts by callingkb_session_prime. The KB checks which files have changed since last read and returns exactly those. Unchanged files are served from cached summaries -- no re-read, no wasted tokens.
Cold session: kb_session_prime returns stale_files=[a.ts, b.ts, c.ts] Agent reads all three, calls kb_capture for each. Warm session: kb_session_prime returns stale_files=[], session_warm=true Agent works from KB summaries. Zero file reads.
Every KB tool call is scoped to the repo it is about -- a fleet server handling many members across many repos never lets one repo's learnings land in another repo's KB. Scope is normally derived from the caller's repo path; tools also accept an explicitrepo_remote_urlso a remote member (whose work folder is a path on another host, unreachable from the fleet server's filesystem) resolves to the same project KB as a local clone of that repo instead of a shared fallback database. The automatic post-prompt harvest and thecode_contextKB enrichment path both forward this URL too, and an unreachable work-folder path is never silently swapped for the fleet server's own working directory -- see[Per-repo KB isolationfor the full anchor and cache-keying rules.
…
Sign in to leave a review
Use Google, GitHub, or an email account so ratings stay tied to real people.
No reviews posted yet.
