Why z4j?

The state of Python task-queue observability

• Flower - Celery only. In-memory. Restart = history lost.
• django-rq / rq-dashboard - RQ only. Framework-specific.
• Dramatiq admin - none in the box.
• Huey / arq / taskiq - no first-party dashboard at all.

If your company runs Celery in one service and RQ in another, you run two dashboards. If you run arq, you run none.

What "control plane" means

A control plane separates the runtime (your tasks, your workers) from the management layer (observation, action, scheduling). The two communicate over a stable wire protocol. The management layer persists history independently of the broker.

This is how Kubernetes, Nomad, and Temporal are organized. z4j is the same shape for Python task queues.

Non-goals

z4j does not:

• Replace your queue runtime. You still run Celery/RQ/Dramatiq/etc.
• Ship as a SaaS-only product. Self-host is the first-class path.
• Require you to rewrite tasks. One decorator (or zero, for most engines) captures what we need.
• Chase every queue in every language. We support six Python engines well, not twenty badly.

Why six engines (not one)

z4j supports Celery, RQ, Dramatiq, Huey, arq, and taskiq so teams can use one control surface across those runtimes. Download counts do not establish deployed usage, so this page makes no market-share claim.

Why AGPL + Apache split

• Brain (the dashboard) is AGPL v3. You can self-host freely. If you SaaS-ify the dashboard, you must open-source your modifications.
• Agents (the pip packages you install in your app) are Apache 2.0. Your application code is never AGPL-tainted.

This is the same split PostHog, Plausible, and others use. See license rationale.

What we won't build

A short list of things we have explicitly chosen not to scope, even if asked:

• JavaScript queues (BullMQ) - BullBoard already solves this.
• Ruby / Sidekiq - Sidekiq's own tooling is great.
• PHP / Horizon - first-party in Laravel.