Skip to content

What is z4j?

z4j is a control plane for Python task infrastructure. It gives Django, Flask, FastAPI, and bare-Python applications a modern dashboard for Celery, RQ, Dramatiq, Huey, arq, and taskiq - with persistent history, unified actions (retry / cancel / bulk-retry / restart), schedule CRUD, HMAC-chained audit logging, and secure-by-default redaction - without touching your existing task code.

z4j integrates with the queue you already run. If you're on Celery today, stay on Celery. Install the matching agent package, connect it to the brain, and verify the reported state in the dashboard.

z4j provides a shared management layer across supported Python queues:

  • Observation - task events, worker state, schedule runs, error rates.
  • Action - retry, cancel, bulk-retry, restart, purge - one vocabulary, offered per engine only where the adapter implements it. See the capability matrix.
  • Schedule CRUD - create/update/delete periodic tasks from the UI (on supported schedulers).
  • Persistent history - task history and the audit trail live in z4j's own database (SQLite or PostgreSQL), not in the broker, so they survive broker restarts.
  • Multi-engine - run Celery + RQ in the same org without switching tools.

z4j is one central service: the server, plus a separate z4j-scheduler process in the shipped Compose stacks. Agents are how it sees the rest of your stack.

+------------------------------+
| z4j | FastAPI + React dashboard
| (SQLite/Postgres storage + | + WebSocket server for agents
| unified action surface) | AGPL v3
+--------------^---------------+
| WebSocket (outbound from your app)
|
+--------------+---------------+
| z4j-<framework> | thin pip package you install in
| + z4j-<engine> adapters | your app (Django/Flask/FastAPI/bare)
| | Apache 2.0
+------------------------------+
|
v
Celery / RQ / Dramatiq / ... your existing task code, unchanged
Feature What it does
Task list Task lifecycle events from every connected engine on one timeline; which steps (enqueue or worker receipt, start, success, retry, failure) an engine reports depends on its adapter
Engine actions Actions follow what the connected engine adapter advertises: the dashboard disables Retry and Cancel when the selected agent has not advertised them, and the agent refuses any verb its adapter does not support. How the gating works
Schedule CRUD Create, update, pause, delete periodic tasks (supported schedulers)
Audit log Admin actions and auth events, HMAC-chained, so an edit or deletion by anything writing through z4j is evident. What that does and does not cover
RBAC Project-scoped roles (admin / operator / auditor / viewer) + multi-user invitations. There is no owner tier.
Rate limits Per-IP buckets on the login, password-reset, setup, invitation, MFA, agent-connect, and bulk-action routes. Not a fleet-wide ceiling: each worker process counts separately
Reconciliation Background worker reconciles "running forever" tasks against real engine state
Redaction Best-effort scrubbing of task fields in the worker and again at the brain, by key-name pattern and value shape. Not a guarantee, and schedule arguments are not redacted at all. What it covers

Three paths, three audiences. Pick the one that matches what you are doing:

If you are… Run
Evaluating (one-venv demo) pip install z4j - z4j + core in one command. AGPL-3.0.
Instrumenting a production app pip install z4j-<framework> z4j-<engine> - agents only, Apache 2.0.
Running z4j in production docker run z4jdev/z4j for the central process; agents via pip in the app.

See the install guide for the full breakdown of each path and their licence implications.