Distributed Python tasks.
Zero brokers.
FastWorker is a brokerless task queue for Python. No Redis. No RabbitMQ. Just 2–3 Python processes, a built-in web dashboard, and native FastAPI integration.
A brokerless task queue for Python.
FastWorker is an open-source (MIT) Python task queue that runs distributed background jobs without an external message broker. Where Celery needs Redis or RabbitMQ plus a result backend and a separate dashboard, FastWorker coordinates work with a first-class control plane process and direct Python-to-Python NNG messaging — typically just 2–3 Python processes total.
It ships an async-native client for FastAPI, four built-in priority levels, a real-time management dashboard, and optional OpenTelemetry tracing. It targets Python-only stacks running roughly 1K–10K tasks/minute across 1–50 workers.
- Processes
- 2–3
- vs 4–6+ services for Celery + Redis
- External broker
- None
- No Redis, RabbitMQ, or Kafka
- Priority levels
- 4
- critical · high · normal · low
- Dashboard
- Built-in
- Auto-starts at :8080
- FastAPI
- Native
- Async client, no sync wrapper
- License
- MIT
- Python 3.12+ · Alpha
The problems FastWorker removes
Most Python task-queue pain is really infrastructure pain. FastWorker deletes the infrastructure instead of managing it.
A broker to run and babysit
The problem
Celery means Redis or RabbitMQ, a result backend, and often a Sentinel or cluster on top — services to deploy, secure, monitor, and page on at 3am.
FastWorker's answer
FastWorker has no external broker. A control-plane process coordinates work over direct NNG messaging. One less moving part in production.
Sync workers fighting async web code
The problem
FastAPI is async, but most task queues expose a synchronous API. You end up wrapping calls in thread pools or run_in_executor just to enqueue a job.
FastWorker's answer
FastWorker ships an async-native Client. Call await client.delay("task", ...) straight from an async endpoint — no wrapper, no thread-pool gymnastics.
Monitoring is a separate project
The problem
Seeing what your workers are doing means standing up Flower or rq-dashboard — another service, another port, another thing to configure.
FastWorker's answer
A real-time dashboard ships in the box and auto-starts at http://127.0.0.1:8080. Workers, queue depth by priority, and task history — no add-ons.
Queue priorities bolted on after the fact
The problem
Getting priority and fair load-balancing right usually means hand-rolling routing rules and multiple queues per priority tier.
FastWorker's answer
Four priority levels — critical, high, normal, low — are built in, with dispatch to the least-loaded subworker. No custom routing to maintain.
Three steps. Three terminals.
Define tasks, start the control plane, submit from your app. No broker setup, no YAML.
Write a task module
# mytasks.py
from fastworker import task
@task
def add(x: int, y: int) -> int:
return x + y
@task
def send_email(to: str, body: str) -> bool:
# ... your logic
return TrueStart the control plane
# Terminal 1: start the control plane
# (GUI auto-starts at http://127.0.0.1:8080)
fastworker control-plane --task-modules mytasks
# Terminal 2+: add subworkers for scale
fastworker subworker \
--worker-id w1 \
--control-plane-address tcp://127.0.0.1:5555 \
--base-address tcp://127.0.0.1:5561 \
--task-modules mytasksCall from FastAPI
# app.py (FastAPI example)
from fastapi import FastAPI
from fastworker import Client
app = FastAPI()
client = Client()
@app.on_event("startup")
async def _start():
await client.start()
@app.post("/add/{x}/{y}")
async def add(x: int, y: int):
task_id = await client.delay("add", x, y)
return {"task_id": task_id}Everything you need. Nothing you don't.
Task queues usually mean orchestrating 4–6 services. FastWorker is 2–3 Python processes with sensible defaults.
Brokerless Architecture
No Redis, RabbitMQ, or Kafka. FastWorker uses direct Python-to-Python NNG messaging. One less service to run, monitor, and secure.
Built-in Management GUI
Real-time Vue + Tailwind dashboard ships with the control plane. Monitor workers, queues, and task history out of the box at port 8080.
FastAPI Native
Submit tasks from async request handlers with one line. Non-blocking submission, result polling, and task-completion callbacks.
Automatic Worker Discovery
Subworkers find the control plane and register automatically. Scale horizontally by spawning more processes — zero reconfiguration.
Priority Queues
Four priority levels (critical, high, normal, low) with automatic load balancing to the least-loaded subworker.
OpenTelemetry Support
Drop-in distributed tracing and metrics. Plug into Jaeger, Honeycomb, or any OTLP collector to trace a task end to end.
Where FastWorker fits
Built for Python-only stacks that need real background jobs without operating a broker.
FastAPI background jobs
Offload email, webhooks, PDF generation, and third-party calls out of the request path with an async client built for FastAPI.
Priority-aware job processing
Route urgent work ahead of bulk work with four built-in priority levels and least-loaded dispatch — no custom routing rules.
Observable worker fleets
Trace a task end to end with OpenTelemetry and watch your fleet in real time — without bolting on a separate monitoring stack.
Lean Python-only deployments
Ship distributed background work on small teams and small infra — 2–3 Python processes instead of a fleet of services.
How it stacks up
FastWorker trades extreme scale for operational simplicity. It's the pragmatic choice for teams shipping FastAPI services at 1K–10K tasks/min.
| Capability | FastWorker | Celery | RQ | Dramatiq |
|---|---|---|---|---|
| External broker | None | Redis / RabbitMQ | Redis | Redis / RabbitMQ |
| Services to run | 2–3 Python procs | 4–6+ | 3–4 | 3–5 |
| Built-in dashboard | Yes | Flower (separate) | rq-dashboard | Third-party |
| Priority queues | 4 levels built-in | Configurable | Multi-queue | Multi-queue |
| FastAPI integration | Native async | Sync wrapper | Sync wrapper | Sync wrapper |
| Setup time | < 5 minutes | 30+ minutes | 15 minutes | 15 minutes |
From the knowledge base
Guides, comparisons, and articles on FastAPI, async Python, and task-queue architecture.
Brokerless vs storage-backed task queues
"No Redis" isn't one category. Storage-backed queues (Huey, Procrastinate) still need a database; brokerless queues (FastWorker) need neither a broker nor a DB.
FastWorker vs ARQ
Comparing FastWorker and ARQ — two async-native Python task queues for FastAPI. Both speak asyncio; the difference is whether you run Redis.
The NNG control-plane architecture, explained
A deep dive into FastWorker's internals — how NNG socket patterns, a first-class control plane, and in-memory dispatch combine into a brokerless task queue.
Why we built a brokerless task queue
The backstory of FastWorker — why we decided Python deserved a task queue with zero external services, and what we learned shipping it.
FastWorker vs Celery
Honest, detailed comparison of FastWorker and Celery — setup, features, scalability, failure modes, and when to choose each for Python task queueing.
FastWorker vs RQ
Comparing FastWorker and RQ (Redis Queue) — simplicity, features, FastAPI integration, and when to choose each for Python background jobs.
Frequently asked questions
Short answers to the questions we hear most. See the full FAQ for more.
Is FastWorker a drop-in replacement for Celery?
FastWorker covers the common Celery use case — defining tasks, enqueuing them from your app, and running workers — without a broker. The API differs (an async client and a control-plane/subworker model), so it is a migration rather than a byte-for-byte drop-in. See the Celery migration guide for a step-by-step path.
Does FastWorker really need no Redis or RabbitMQ?
Correct. FastWorker uses direct Python-to-Python NNG messaging coordinated by a control-plane process. There is no external message broker and no separate result backend to deploy or secure.
What scale is FastWorker designed for?
FastWorker targets Python-only stacks running roughly 1,000–10,000 tasks per minute across 1–50 workers. For extreme fan-out or polyglot fleets, a broker-based system like Celery may still fit better.
Does it integrate with FastAPI?
Yes. FastWorker ships an async-native Client designed for FastAPI. You can await client.delay("task", ...) directly inside async request handlers with no synchronous wrapper.
Explore FastWorker
Everything else worth reading before you deploy — the full feature set, answers, terminology, and the team behind it.
Features
Every FastWorker capability in one place — brokerless control plane, built-in dashboard, priority queues, FastAPI integration, and OpenTelemetry.
FAQ
Answers to the questions we hear most: the brokerless model, FastAPI integration, scale, priorities, the dashboard, and requirements.
Glossary
Plain-English definitions of FastWorker and task-queue terms — brokerless queue, control plane, subworker, NNG, priority levels, and more.
About
Built by Neul Labs, an independent Python consultancy founded by Dipankar Sarkar. MIT licensed, alpha, and actively developed.
Ship production FastAPI faster.
Work directly with Dipankar Sarkar, the maintainer of FastWorker, on FastAPI architecture reviews, async migrations, background-job design, and performance audits for Python teams shipping at scale.