Evaluate django.tasks as Celery replacement (Django 6.x+)

[rdhyee]

Priority: Low — future exploration only. No action needed until Django 6.x upgrade.

Background

Django 6.0 (released December 2025) introduced a built-in tasks framework (django.tasks) via DEP 0014. This could eventually replace our Celery dependency.

Eric noted on the April 10 call that Celery might be overkill for our current needs. django.tasks could be the simpler alternative — but not yet.

Current state of django.tasks (as of Django 6.0)

What it has:

• @task decorator and .enqueue() API
• Database-backed queue (no Redis/RabbitMQ required)
• Integration with Django's ORM and settings

What it lacks:

• No built-in worker process — still needs external execution (review)
• No deferred/scheduled tasks (our CELERY_BEAT_SCHEDULE equivalent)
• No retry logic
• No task chaining or workflows

What regluit uses Celery for

• Beat scheduling: ~12 periodic tasks in production (update_active_campaign_statuses, emit_notices, refresh_acqs, etc.)
• Async task execution: email sending, book loading, campaign status updates
• Worker management: separate process via systemd

When to revisit

• After we're on Django 5.2 LTS and planning the 6.x hop
• When django.tasks adds scheduled/periodic task support (expected in later 6.x releases)
• If we simplify our periodic tasks enough that a cron-based approach could replace beat

References

• Django 6.0 release notes
• Django tasks framework docs
• DEP 0014: Background Workers
• Django 6.0 Tasks: a framework without a worker (Loopwerk)