z4j vs. Flower

The classic Celery viewer. Built in 2011.

Scope: Celery only
Positioning: Read-only viewer
License: BSD-3, open source

Flower upstream project

what Flower does well

Credit where it's due

Battle-tested on Celery for over a decade

Single process, no database, very simple to deploy

Live broker-event stream gives good real-time feel

Familiar to anyone who has ever run Celery in production

capability matrix

z4j vs. Flower, feature by feature

Capability	Flower	z4j
Engine coverage	Celery only	Celery, RQ, Dramatiq, Huey, arq, taskiq
Persistent history	In-memory only, lost on restart	Postgres-backed, every task ever seen
Actions (retry, cancel, bulk)	None, strictly a viewer	Universal across every engine
Bulk operations	None	bulk_retry, purge_queue with filters
Schedule management	Read-only via Celery Beat viewer	Full CRUD: create, edit, delete, enable/disable, trigger-now
RBAC / multi-user	Single basic-auth user	Owner / Admin / Operator / Viewer per project
Invitation flow	None	Admin mints links, SMTP auto-send, single-use tokens
Password reset	N/A (no user model)	Constant-time, single-use tokens, session revoke
Audit log	None	HMAC-chained, tamper-evident
Reconciliation worker	None - tasks stuck 'started' stay that way	Periodic probe closes the gap automatically
Historical trends	None	Built-in: success, failure, p50/p95/p99 over time
Visual DAG (chains/groups/chords)	Flat parent/child list	Tidy-tree SVG with runtime badges
Secret redaction	Raw args shown in UI	Recursive scrubber + per-task overrides
Notifications	None	Email / Slack / Telegram / webhook, SSRF-hardened
Real-time updates	Polling	WebSocket with HMAC-signed frames

migration guide

Cut over from Flower in a week (or a weekend)

1

Keep Flower running during the migration

z4j and Flower don't interfere. Leave Flower up; install z4j alongside; compare views during the cut-over week. Turn Flower off when you're confident.
2

Install the z4j-celery adapter in the same worker process

Flower subscribes to Celery's broker events via a separate process. z4j-celery uses the same events, plus worker signals, plus the result backend for reconciliation. Both can observe concurrently.
3

Point z4j at the same broker + result backend

z4j reads your existing CELERY_BROKER_URL + CELERY_RESULT_BACKEND. No data migration. Historical tasks that Flower forgot on its last restart won't appear in z4j, but every task after z4j install is persistent.
4

Mint per-operator users

Flower's single-user basic-auth was always a compromise. z4j has real RBAC: invite your team, give each person a login, make operators actual operators. Audit log shows who retried what and when.
5

Delete your Flower docker-compose entry

Keep the compose file in git. If you hit a z4j bug, you can re-enable Flower in one minute. You won't need to.

honest trade-offs

Where we don't win

Flower has been around since 2011. It is battle-tested on Celery in a way z4j will not be for another year.

Flower is a single-process deploy: one container, no database. z4j needs SQLite at minimum, Postgres for production. That is a real operational delta.

If your stack is pure Celery and you only need a viewer, Flower is fine.

other comparisons