Fleet 1.13:Teams are now shipping 5x more PRs with autonomous pipelines.See what's new →
FleetFleet
Guide

How to Self-Host an AI Development Team with Fleet

Cloud-based AI agent platforms trade control for convenience. You get a UI, but you also get opaque pricing, data leaving your infrastructure, and limited ability to customize agent behavior. Self-hosting an AI dev team means running agents on your own machine or server, with full visibility into what they do and how much they cost.

Fleet is a single Go binary with no external dependencies beyond tmux and the Claude CLI. It runs on a laptop, a dev server, or a bare-metal box in your office. This guide walks through a complete self-hosted setup from install to running agents.

Before you start

  • A Linux or macOS machine with tmux installed
  • Claude Code (`claude`) installed and authenticated with an Anthropic API key
  • Git and GitHub CLI (`gh`) installed and authenticated
  • A GitHub repository you want agents to work on
1

Install the Fleet binary

Download the Fleet binary for your platform from fleetctl.ai and place it on your PATH. There is no package manager requirement, no Docker, and no Node.js. The binary is statically compiled Go.

# Install the Fleet binary
curl -fsSL https://fleetctl.ai/install | sh

# Verify
fleet --version
2

Initialize Fleet in your repository

Navigate to your repository and run fleet init. This creates .fleet/config.yaml with sensible defaults. Edit the file to reflect your actual team structure.

cd /path/to/your/repo
fleet init
3

Define your team in config.yaml

A minimal self-hosted team has one developer agent, one reviewer, and one release manager. Add them to the agents section of .fleet/config.yaml. Each agent maps to a role that determines which Fleet skills it receives.

repo: your-org/your-repo
owner: your-github-username

agents:
  - name: dev-1
    role: backend-developer
    department: engineering
    reports_to: tech-lead
    model: claude-sonnet-4-5
  - name: tech-lead
    role: tech-lead
    department: engineering
    model: claude-opus-4-5
  - name: release-manager
    role: release-manager
    department: engineering
    model: claude-sonnet-4-5
4

Run fleet doctor to verify prerequisites

Before starting agents, run fleet doctor to check that all prerequisites are in place. It checks for tmux, the GitHub CLI, SQLite access, and the Fabric socket. Fix any issues it reports before proceeding.

fleet doctor
5

Start the watcher and verify

Start the watcher daemon in supervised mode so it restarts after a crash. Then check status to confirm everything is connected.

fleet watcher start --supervised
fleet status
6

Add a ready label to trigger the chain

With the watcher running and agents defined, the system is live. Add the ready label to a GitHub issue to start the autonomous workflow chain.

gh issue edit 1 --add-label ready
# Wait up to 2 minutes for the watcher to detect the label
fleet log --type decision

Common pitfalls

  • If you are running Fleet on a remote server, you need tmux sessions to persist across SSH disconnects. The watcher manages its own daemonization, but you must start it in a shell that survives your SSH session (or use `fleet watcher start --supervised` which daemonizes itself).
  • The Fleet database lives at `~/.fleet/fleet.db` by default. Back this up regularly. It contains all agent definitions, event history, and run-time tracking.
  • GitHub rate limits apply to the polling watcher (2-minute label polls, 10-second Fabric processing). High-volume repositories with many rapid label changes may hit secondary rate limits.
  • Self-hosting means you are responsible for keeping the Claude CLI authenticated. Token expiry or API key rotation that is not reflected in the environment will cause agents to fail silently.

When Fleet is the right tool

Self-hosting with Fleet makes sense when you have ongoing development work, want to keep costs predictable, and prefer not to trust a third-party platform with your source code context. It is the right choice if you already run your own infrastructure and have an engineer who can spend an hour on initial setup. It is less convenient than managed platforms for teams that want zero ops overhead.

Frequently asked questions

Can I run Fleet on a shared server for multiple developers?

Yes. Fleet's database is path-configurable via `FLEET_DB_PATH`. Multiple developers can share one Fleet installation on a central server, each pointing to their own repository. Agent name collisions across projects are scoped by the `repo` field in config.

Does Fleet send my source code to any third party other than Anthropic?

No. Fleet communicates with Anthropic's API (via the Claude CLI) and GitHub's API (via the `gh` CLI). No data goes to any Fleet-operated service. The Fleet binary itself is a local process manager.

Run your first agent fleet

One binary. Five minutes. See every agent, coordinate every handoff, and keep a full audit trail of what your fleet did.