← All open source projects

Celery

celery/celery

Celery is a distributed task queue for Python with workers, brokers, and scheduling.

Forks 5,084
Author celery
Language Python
License NOASSERTION
Synced 2026-06-27

In Short

Celery moves long-running and background operations out of web requests: tasks go to a broker, workers execute them separately, and the app stays responsive.

What It Is

Celery is a distributed task system for Python. It helps run background work, queues, periodic jobs, and event processing outside the main application process.

What Is Inside

The project supports brokers such as RabbitMQ and Redis, workers, task results, retry behavior, and scheduling. The documentation covers queues, jobs, and integrations.

How People Use It

Celery is used in web applications and services with email sending, image processing, file imports, periodic reports, notifications, and other operations that should not block user responses.

Example

Background Task

The example shows a Celery task: the application sends work to a queue, and a worker runs it separately.

Language: Python
from celery import Celery

app = Celery("jobs", broker="redis://localhost:6379/0")

@app.task
def send_digest(user_id: int) -> str:
    return f"digest sent to {user_id}"

Strengths

Celery’s strength is a mature background-work model. It has long been used in Python projects and fits systems with many different task types.

Limits

The limitation is operational complexity. A broker, workers, retries, idempotency, and queue monitoring appear; those must be designed, not just enabled.

Project Context

Celery is maintained in the celery/celery repository; its public history starts on 2009-04-24. The primary metadata language is Python, and the license is NOASSERTION. The project also has a dedicated site: https://docs.celeryq.dev.

This context keeps the page grounded in a specific repository: the project has an owner, technical base, license, change history, and real constraints of its ecosystem.

Celery should be evaluated through a concrete scenario: who will maintain it, where it fits in the existing stack, which updates must be tracked, and what happens if it fails. That view is more useful than installing a project just because it is popular, because open source helps only when its role in the system is clear to the team.