mher/flower: A Web Admin for Celery, and What It Cannot Do

What Flower Is For in a Celery Deployment

Celery gives you a broker, workers and a result backend. It does not give you a window into them. When a queue backs up, the usual first move is to open a broker console or run celery inspect from a shell, and both answers are point-in-time text. Flower exists to fill that gap: it is a web application that subscribes to Celery Events and renders worker status, task progress and queue statistics continuously. The README lists the audience implicitly through its features: real-time monitoring of tasks and workers, remote control of worker instances, broker monitoring, and an HTTP API. That combination points at people who operate a Celery cluster rather than people who write tasks. If your job is to add a task to a queue, Flower is not part of your loop. If your job is to explain why a worker stopped consuming, or to revoke a task that is already running, it is the tool the project is built around.

How Flower Reads Celery Events and Serves Them

The mechanism is event consumption, not polling of your database. Celery workers publish events, and Flower attaches to the same broker to receive them. This is why the README's usage examples all pass a broker URL or a Celery application: `celery --broker=amqp://guest:guest@localhost:5672// flower` and `celery -A tasks.app flower` are two ways to tell Flower where the cluster lives. The docker-compose.yml in the repository shows the same wiring with Redis, setting CELERY_BROKER_URL and CELERY_RESULT_BACKEND to redis://redis for both the worker and the flower service. Two consequences follow from this design. First, Flower sees what the workers emit, so a worker started without event emission is largely invisible to it; the compose file starts its worker with `-E` for exactly this reason. Second, Flower is a consumer on your broker, not a passive observer of a database, so it adds a connection to the same infrastructure your tasks depend on. The web layer then serves three surfaces: the dashboard, the HTTP API under /api, and a Prometheus endpoint for scraping. The README points at flower.readthedocs.io for configuration and API reference rather than enumerating options inline.

Installing Flower and Watching a First Worker

The README gives the install as a single pip command, and the development version as an install straight from a GitHub zipball. Once installed, Flower is started as a Celery subcommand rather than as its own binary, which means it inherits the application configuration you already have.

pip install flower

After that, point it at a broker. The README's first example passes the broker URL directly; the second uses an existing Celery application, which is the more common arrangement in a real project.

celery -A tasks.app flower

By default it listens on port 5555, and the README shows the port option for moving it.

celery -A tasks.app flower --port=5001

If you would rather not install into your own environment, the repository ships a Dockerfile and a docker-compose.yml. The README's docker example mounts an examples directory and runs the tasks.app application inside the container.

docker run -v $(pwd)/examples:/data -p 5555:5555 mher/flower celery --app=tasks.app flower

What you should see is a web UI on the chosen port listing workers, their consumed queues, running and reserved tasks, and broker queue statistics. Nothing appears for a worker that is not emitting events, so check the worker's start command before assuming Flower is broken.

The HTTP API: Pool Growth, Task Calls and Revocation

Flower's API is not read-only. The README demonstrates three write operations with curl: growing a worker's pool, applying a task asynchronously, and revoking a task. The pool call targets a worker by name, which in the README's example is built from the hostname.

curl -X POST -d 'n=1' http://localhost:5555/api/worker/pool/grow/celery@$(hostname)

Calling a task takes a JSON body of arguments, and the task is named in the URL path.

curl -X POST -d '{"args":[1,2]}' http://localhost:5555/api/task/async-apply/tasks.add

Revoking a running task uses the task id, and the README passes terminate=True to make it a termination rather than a revocation.

curl -X POST -d 'terminate=True' http://localhost:5555/api/task/revoke/8a4da87b-e12b-4547-b89a-e92e4d1f8efd

This is the part of Flower that deserves the most caution. An endpoint that terminates tasks and resizes pools is an operational control plane, and the compose file sets FLOWER_UNAUTHENTICATED_API to "true" for its local example. That is fine on a laptop. On a shared network it means anyone who can reach port 5555 can call those endpoints. The README lists HTTP Basic Auth and OAuth providers as features, so authentication exists, but it is a configuration decision the operator has to make deliberately.

Where Flower Stops Being the Right Tool

Flower is a monitor and a control surface, and the README's feature list is the honest boundary of it. It does not schedule periodic work; Celery Beat does that. It does not store task results; your result backend does. It does not replace the broker's own management interface for exchange and binding inspection. The most common failure mode is quieter than any of those: Flower shows an empty or partial view because events are not being emitted or because the broker URL it was given is not the one the workers use. A second limitation is historical depth. Because the UI is fed by events, what you see is what has been emitted since Flower connected, plus whatever task metadata it retains in memory. The README does not document a persistent event store, so treating the task history page as an audit log is a mistake. If you need durable task records, that belongs in your result backend or a separate store, and Flower is the wrong place to look for it.

Flower Versus Scraping Celery Into Prometheus and Grafana

The repository contains a second, quite different monitoring path: prometheus.yml at the top level, a grafana directory with provisioning files, and examples/celery-monitoring-grafana-dashboard.json. The docker-compose.yml wires these together, running Prometheus on 9090 and Grafana on 3000 alongside Redis, a worker and Flower. The Grafana service is configured with anonymous access at the Viewer role and mounts the Celery dashboard JSON as its home dashboard. The difference in approach is real. Flower is an interactive console: you look at a live view and you can act on it by revoking a task or growing a pool. Prometheus and Grafana are a time-series pipeline: metrics are scraped on an interval, stored, and rendered as dashboards and alerts, with examples/prometheus-alerts.yaml in the repository as a starting point. Grafana will not let you terminate a task. Flower will not give you a retention window measured in weeks or an alerting rule that fires at 3am. The compose file runs both, which is the honest answer for a production cluster: Flower for inspection and control, Prometheus for history and alerting.

Maintenance, Packaging and the Licence Question

The last push to the repository was on 2026-09-13, and the most recent release is v2.1.0 from 2026-08-16, so the project is being updated. setup.py declares python_requires=">=3.10" and classifies the package for CPython and PyPy across Python 3.10 through 3.14. The same file carries the classifier Development Status :: 4 - Beta, which is worth reading literally: this is a long-lived project that still labels itself beta. Upgrade cost is mostly the usual Python dependency question. Flower is installed from PyPI or from a GitHub zipball, and the Dockerfile builds from the checkout rather than a pinned release, so an image built from master will move under you. The README states that Flower is licensed under the BSD 3-Clause License and points at the LICENSE file for the full text. Note that the repository metadata reports the licence as NOASSERTION while the README and setup.py both say BSD 3-Clause; if licence terms matter to your organization, read the LICENSE file itself rather than trusting either label. That is a factual discrepancy in the project's own metadata, not a legal opinion, and it is the kind of thing worth resolving before a compliance review rather than during one.

Editorial conclusion

Adopt Flower if you already run Celery and want a browser view of workers, queues and task history, or an HTTP API for pool growth and revocation. Do not adopt it as a scheduler, a durable task store or a replacement for broker-side monitoring, and do not expose it without authentication. Before rolling it out, verify that your workers are started with the -E flag so events are emitted, and decide whether the API should stay unauthenticated.

Frequently asked questions

Official sources

1. Issues
2. mher/flower on GitHub
3. Project website
4. README
5. Releases