FAQ
Common questions about Autopilot.
What AI models does Autopilot support?
The current runtime adapter uses Claude Code (Anthropic). The system is designed for multiple runtime adapters, but Claude Code is the only real, tested adapter today.
Is there a dashboard / web app?
Not yet. The current operating surfaces are the CLI, notifications, and conversation bindings. A Worker App (web interface) is planned but is not the center of the current product. The system is fully operable without it.
Is Autopilot self-hostable?
Yes. Autopilot is designed to be self-hosted. The orchestrator runs on your infrastructure. Workers run on machines you control. Secrets never leave your environment.
How is this different from using Claude Code / Cursor / Copilot directly?
Those are single-session tools. Autopilot adds:
- Workflow progression — multi-step execution with explicit routing
- Durable state — tasks, runs, and artifacts persist across sessions
- Human approval loops — gate risky steps before they execute
- Multiple workers — route work to the machine with the right access
- Previews — orchestrator-backed outputs you can review from any device
- Notifications — get alerted when attention is needed
- External actions — act on real systems through provider/handler extensions
What is a workflow?
A YAML file under .autopilot/workflows/ that defines how a task progresses. It specifies steps, their order, approval gates, and how outputs route between steps. The workflow engine handles progression automatically.
What is a worker?
A long-running process on a machine that claims and executes runs. It has direct access to the repo, toolchain, and local credentials. Workers are where AI actually executes — on a real machine, not in a hosted sandbox.
What is the orchestrator?
The control plane. It stores all operational state (tasks, runs, workers, events, artifacts), manages workflow progression, serves durable previews, and routes notifications. It does not execute AI sessions.
Can multiple workers connect to one orchestrator?
Yes. Each worker independently claims available runs. This is useful when different workers have access to different repos, environments, or credentials.
Where do secrets live?
Provider secrets (API tokens, webhook secrets) are resolved by the orchestrator at handler invocation time — declared as references in provider YAML, not embedded values. Machine credentials (SSH keys, git tokens) and runtime auth (AI provider API keys) stay on the worker machine.
Shared company secrets managed centrally by the orchestrator are planned but not yet implemented. Today, secrets are configured per-host via environment variables, files, or exec commands.
What is a pack?
A distribution unit that installs providers, handlers, workflows, skills, or other material into your .autopilot/ directory. Packs are declared in company.yaml, resolved from git registries, and materialized by autopilot sync. See Packs and Distribution.
What is a surface?
A human-facing channel pattern — like Telegram, Slack, or email — built over providers, handlers, and conversation bindings. Surfaces are not a separate config object; they are the user-visible result of combining provider capabilities with the orchestrator's binding and notification model. The Telegram surface pack is the first real example.
How do I add a Telegram bot?
Install the Telegram surface pack: add questpie/telegram-surface to your company.yaml packs, run autopilot sync, configure your bot token and webhook, and create a conversation binding. Full guide: Telegram Surface.
Is this open source?
Yes. Autopilot is open source and self-hostable.
What's the .autopilot/ directory?
The repo-native config directory. It contains authored YAML for agents, workflows, environments, providers, and handlers. It is the single source of truth for policy. Reviewable, versioned, branchable — same as your code.
What happens if a worker goes down?
The orchestrator still has all state. Previews and artifacts are stored by the orchestrator, not the worker. When a worker comes back (or a different worker picks up), runs can be reclaimed. Raw session transcripts on the worker are lost, but operational state is durable.
Is local development different from cloud deployment?
No. Local and cloud are the same architecture with a different URL. autopilot start runs the orchestrator and worker on localhost. For cloud, run the orchestrator on a VPS and point workers at it with ORCHESTRATOR_URL. Same config, same primitives, same behavior. See Cloud and Deployment.
What is autopilot sync?
The command that installs and applies packs. It resolves pack refs from your company.yaml, fetches them from configured registries, materializes files into .autopilot/, and writes a lockfile. See Packs and Distribution.