Celery 5.6 sends Python functions through a broker
Celery 5.6 turns a decorated Python function into a message that a separate worker can execute. An application puts the message on RabbitMQ, Redis, SQS, or another transport, and a worker pulls it from the queue. The caller can continue immediately. If the application needs status or a return value, Celery sends that data to a configured result backend. This split is why Celery fits web requests, batch jobs, and work spread across machines.
The breadth is visible before a worker starts. commit 319d9c7 had 828 files and about 106,878 source lines in a 6.3 MB checkout. Our install pulled 121 packages and occupied 272 MB. Celery also separates several supporting projects, including Kombu for messaging and Billiard for process pools. Adopting it means learning a small ecosystem and its operating model, not merely adding a decorator to slow functions.
RabbitMQ and Redis are the two feature-complete brokers
Celery 5.6 documents RabbitMQ and Redis as its feature-complete transports. The first-steps guide calls RabbitMQ suitable for production and warns that Redis is more susceptible to data loss after abrupt termination or power failure. Amazon SQS and Google Pub/Sub are supported, while several other transports are described as experimental. Broker choice changes acknowledgement, failover, and visibility behavior, so an existing service is not automatically the right Celery broker.
Python 3.9 through 3.13 is supported by the 5.6 series, with 5.6 documented as the last line for Python 3.9. A worker also needs a broker URL and a process manager in production. Results add another decision: Redis, RPC, SQLAlchemy, Django ORM, and other stores have different persistence and retrieval rules. You can skip the result backend when nobody needs task state or return values, which removes one service from the path.
What happened when we ran it
Our measurement setup was a fresh unprivileged Debian container with 3 CPUs and 8 GB of RAM. Installing commit 319d9c7 succeeded in 54 seconds, adding 121 packages and using 272 MB on disk. The build completed successfully in 5 seconds. This is a reasonable repository setup for a mature Python system, though it does not include provisioning RabbitMQ, Redis, SQS, or a result store for an application.
Pytest ran for 599 seconds and exited 1: 3,912 tests passed, 8 failed, and 39 were skipped out of 3,920. The tail also recorded 3 expected failures, 85 warnings, and 27,673 passing subtests. Every listed failure raised celery.exceptions.SecurityError with a message about running a worker with superuser privileges. The log printed uid and euid 1000, and it does not explain why those checks reached that conclusion. Pip-audit reported 10 known vulnerabilities.
Late acknowledgment can execute a Celery 5.6 task again
The Celery 5.6 task guide asks authors to make task functions idempotent, meaning a repeat call with the same arguments should not create an unintended second effect. By default, a worker acknowledges a message just before execution. Turning on acks_late moves that acknowledgment until after the task returns, but the documentation warns that the task may execute multiple times if the worker crashes during it. Payment, email, and inventory code needs its own duplicate protection.
Retries, time limits, prefetch settings, and result persistence all alter failure handling. Celery supplies the controls, while the application owns the policy. Periodic work adds Celery beat, and the guide says only 1 scheduler should run for a schedule or duplicate tasks will be emitted. Our 599-second test run exercises a large body of project code, yet it cannot prove that a buyer's task is safe to repeat or that a shutdown sequence preserves every side effect.
Windows is unsupported, and SQS has a shutdown report
Celery 5.6 says Microsoft Windows is unsupported, though it may work, and asks users not to file issues for that platform. Linux teams still need to test the selected pool, broker, and shutdown signals. Open issue #10172 describes Celery 5.6.2 with SQS receiving a message during warm shutdown, leaving it in flight and invisible until the queue's visibility timeout. That report is specific to the supplied SQS reproduction; it does not establish the same behavior for RabbitMQ or Redis.
Release v5.6.3 arrived on March 26, 2026 with worker, backend, scheduling, and documentation fixes. It includes a Redis failover reconnection fix and an update for PyMongo 4.16 compatibility. Main has continued moving since that release. Our commit 319d9c7 build passed in 5 seconds, while pip-audit still found 10 known vulnerabilities in the lab environment. Pin the Celery line and extras, then review the complete resolved dependency set instead of assuming the base package tells the whole story.
A same-day push shows activity across a large surface
GitHub recorded a push on September 12, 2026, and issues and pull requests were being updated that day. The repository had 28,876 stars and 733 open issues and pull requests when fetched. Current work included fixes for task-name collisions, database result metadata, and multi-server URL handling. That is strong evidence of maintenance. The combined open count is not a bug total, and its size also shows how many brokers, pools, backends, and workflow features need attention.
Celery earns its place when background jobs are infrastructure: several applications publish work, worker groups need separate queues, or broker and result choices must stay open. The 121-package install and 272 MB footprint are modest beside the operational decisions it exposes. For one application with a Redis queue and a few jobs, RQ or Huey is easier to hold in your head. Once routing, retries, scheduling, and worker fleets become shared concerns, Celery's maturity repays the added machinery.