Install Fleet and run your first workflow
Fleet separates authoring from execution: build the workflow in the dashboard, then let your self-hosted worker run it in your repository.
Prerequisites
You need tmux for agent sessions, git for repository work, and Claude Code authenticated on the worker host. The GitHub CLI is required for coding workflows that create and review pull requests.
tmux -V
git --version
gh auth status
claude --versionAfter installation, run fleet doctor for the complete local check.
First run
These steps follow the current dashboard-authored workflow model.
Install the Fleet binary
Fleet is a single Go binary. The installer selects the correct build for your platform.
curl -fsSL https://fleetctl.ai/install | shRun one-command onboarding
From the repository Fleet will work in, check prerequisites, scaffold local config, and start the worker services.
cd my-repo
fleet upOpen the Workflow Builder
Sign in to the dashboard, open Workflows, and choose New workflow. The dashboard is the source of truth for workflow definitions.
https://app.fleetctl.ai/workflowsChoose a starting point
Use Weekly brief for document work or Ship a feature for the complete coding flow. The template creates the steps and dependency edges for you.
Bind the repo and trigger
Choose the repository the workflow works in. Start manually, on a cron schedule, or when a backlog ticket receives a label.
Save and run
Press Run for a manual workflow, then open History to watch each step, artifact, approval, retry, and terminal result.
What Fleet created locally
.fleet/config.yaml # repo, agents, types, corpus, connectors
~/.fleet/fleet.db # local operational state
~/.fleet/logs/ # worker and agent logsWorkflow graphs are saved in the dashboard and pulled with each run. You do not need to recreate the graph as a pipelines: or subscription block in .fleet/config.yaml.
Core concepts
Workflow definition
A stable saved graph of typed steps, dependency edges, triggers, outcome routes, and governance settings.
Self-hosted worker
The local Fleet process that pulls queued definitions and executes their agent steps against your repository.
Typed step
One unit of work with a specific contract: create an artifact, open a PR, review an output, wait for approval, publish, merge, or notify.
Run
One execution of a saved definition. Runs keep status, step history, artifacts, decisions, retries, and provenance.
Outcome route
A configured edge for outcomes such as review flag, approval rejection, or execution error, with a bounded retry policy.
Approval gate
A suspension point where a person reviews the current evidence and approves or rejects before the run continues.
How the coding template runs
Ticket label or Run button
↓
Refine ticket
↓
Develop → coding agent opens a PR
↓
Review ── flag ──→ Develop (bounded fix loop)
↓ pass
Human approval
↓
Merge → AnnounceThe code step parks the run while the agent works. The PR resumes it. The approval step parks again until a person decides. No subscription processor sits between those steps—the saved workflow owns the sequence.