FastWorker
Alpha v0.1.1 · MIT Licensed · Python 3.12+

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.

✓ Brokerless ✓ Built-in dashboard ✓ FastAPI native ✓ Priority queues ✓ OpenTelemetry
What is FastWorker?

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.

How brokerless works →

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.

FastAPI background tasks →

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.

Built-in dashboard →

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.

Priority & load balancing →

Three steps. Three terminals.

Define tasks, start the control plane, submit from your app. No broker setup, no YAML.

1 · Define

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 True
2 · Run

Start 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 mytasks
3 · Submit

Call 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.

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.

Browse everything →

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.

FastAPI Consulting · Neul Labs

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.