All documentation
Getting Started

Webhooks: Local and Production Operations

Run webhook delivery locally without extra services, then switch safely to Redis and Celery in production.

Bash

Overview

Local development and production use the same webhook models and delivery logic but different task execution modes. Local development: - DEBUG=True - CELERY_TASK_ALWAYS_EAGER=True - A webhook request runs immediately in the Django process. - Redis and a separate Celery worker are not required for basic testing. Production: - Redis acts as the shared queue/broker. - Celery workers perform outgoing HTTP requests away from web requests and WebSocket consumers. - Celery Beat periodically dispatches scheduled retries and cleanup. - This keeps PulseGrid responsive under load.

Setup

Initial installation: 1. Install requirements. 2. Apply migrations. 3. Seed billing limits. 4. Collect static files. 5. Start Django/Daphne. Production environment: REDIS_URL=redis://127.0.0.1:6379/0 CELERY_BROKER_URL=redis://127.0.0.1:6379/0 CELERY_TASK_ALWAYS_EAGER=False Run one or more Celery workers and one Celery Beat scheduler. Do not run multiple Beat instances unless using a scheduler that guarantees a single active scheduler.

Code example

Webhooks: Local and Production Operations 
pip install -r requirements.txt
python manage.py migrate
python manage.py seed_billing
python manage.py seed_webhook_docs
python manage.py collectstatic
python manage.py check

# Production worker
celery -A pulsegrid worker -l info

# Production scheduler
celery -A pulsegrid beat -l info

Notes

SQLite and immediate tasks are suitable for controlled local testing. Before running multiple production application processes, use PostgreSQL and Redis. Only one Beat scheduler should schedule retries. Multiple workers are allowed and can be added as traffic grows.