> For the complete documentation index, see [llms.txt](https://fleet.hackmap.win/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://fleet.hackmap.win/readme.md). # Introduction Fleet is a framework for running pools of distributed automation workers and pushing their output around between them. It grew out of a CAPTCHA-solving farm: one master process, many workers, browsers churning out tokens, consumers pulling from a shared queue. The framework is what's left after you strip the CAPTCHA-specific code out. If your problem looks like "I need N machines each doing M parallel things, controlled from one place, with their output going somewhere", Fleet is probably useful. If you only need a single script on a single host, it isn't. ## What you get A master process. It exposes a REST and WebSocket API, persists state in Redis, and serves a small dashboard. You write a Python class that subclasses `ContinuousAutomation` or `BatchAutomation` and ship it as a pip package with a single entry-point line. Install that package on the master and on each worker host, and the master discovers it automatically. Workers dial out to the master over WebSocket. They receive a typed config and run as many parallel "slots" as the config says. When a slot produces something, it gets pushed onto a Redis-backed output stream that's bounded by length and TTL. Other automations, or any HTTP client with a bearer token, can pop from that stream. The reconcile loop on each worker compares observed state to desired state and applies the smallest change that converges them: spawn, scale up, scale down, restart, recycle, stop. The same loop also heals. If a slot crashes or fails to start, it tries again next tick. ## What you don't get A job scheduler. Fleet doesn't decide when to run things; you do, by changing the config or pushing tasks onto a queue. There's no cron, no DAG, no retry policy beyond "the slot tried, it failed, the next tick will try again". A service mesh. Workers talk to the master, full stop. They don't discover each other, they don't route to peers. Cross-automation communication goes through the master's Redis-backed streams. A sandbox. Plugin code runs inside the worker process with whatever permissions the worker has. There's no isolation. Treat each plugin you install with the same trust you'd give any other dependency. ## Who this is for People building automation fleets and tired of writing the same master/worker glue every time. People running CAPTCHA solvers, scrapers, account-creation pipelines, retry workers, anything where the unit of work is small and you want to fan it out. People who would rather extend a framework than maintain a bespoke control plane. If you've never run Redis or FastAPI, the [quickstart](/getting-started/quickstart.md) walks you through it. If you have, [first automation](/getting-started/first-automation.md) is faster. ## Status Released as **1.0.0**. The public API in `fleet.core`, `fleet_browser`, and the REST + WebSocket protocol are stable from here. Breaking changes will follow semver. No PyPI package yet — install from source while we finalize the release pipeline. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://fleet.hackmap.win/readme.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.