Deploy Patterns

Every part of a running Entirius service as the reference setup runs it, and the file you configure it in. The integration harness (entirius-zeno, docker-compose.yml) is the executable reference for every part below, but it runs the Django development server and is not a deployment target.

What a Deployment Consists Of

Part	Runs as	Configured in
Settings file	Python module imported at boot	main/settings_local.py
PostgreSQL	system service	DATABASES in the settings file
Redis	system service	REDIS_URL, CELERY_RESULT_BACKEND, CACHES in the settings file
RabbitMQ	system service	CELERY_BROKER_URL in the settings file
Web process	WSGI server under a supervisor	main/wsgi.py, the WSGI server’s own config
Celery worker	supervised process	main/celery.py, the -Q queue list on its command line
Celery beat	one supervised process	CELERY_BEAT_SCHEDULE in the settings file
Static and media files	files served by the web server	STATIC_ROOT, MEDIA_ROOT in the settings file
Mail	SMTP server you already run	EMAIL_*, EMAIL_SMTP_CONFIGURATION_CHANNELS in the settings file
Admin CMS	static app served by the web server	.env and __client/ at build time
Storefront	Node server	_CONFIG/ at build time

Settings File

Each environment has its own main/settings_local.py, and the service refuses to boot without it. The names it must define: Start From the Service. What a working installation sets beyond them, with the harness file as a worked example: Settings Per Environment.

Database

PostgreSQL. django.contrib.postgres is installed in the base settings. The lookup module’s first migration creates the vector, pg_trgm and unaccent extensions, so either the database role has CREATE on the database or the extensions exist before the first migration. The pgvector build of PostgreSQL ships all three; the harness uses the pgvector/pgvector:pg16 image.

Migrations

Run make migrate in the service checkout on every deploy, before the web process restarts. make health fails while a migration is pending, so a forgotten one shows up in the gate.

Web Process

The WSGI application is main.wsgi.application. Put it behind a web server under a process supervisor. No WSGI server is a dependency of the service; the reference runs uWSGI under supervisor, see Process Supervision. Never the Django development server.

Workers and Beat

The Celery app is main/celery.py. It reads CELERY_-prefixed keys from the settings file: CELERY_BROKER_URL points at RabbitMQ, CELERY_RESULT_BACKEND at Redis. REDIS_URL also backs the task locks some module tasks take.

The worker consumes named queues and must list every queue of the modules you install. Where the list comes from: Worker Queues. What a missing queue costs: Process Supervision. The harness worker runs with this list:

celery,quantities,fill_product_representation,pricemanager_create_pricelist,contact_forms,contact_forms_conversions,lookup,leads_default,communicator_default,communicator_send,communicator_inbound,siteintel_default,notifications_default

The suppliers modules add atlas_default, atlas_images and atlas_results (the dev mode worker in docker-compose.dev.yml consumes them).

The default cache must be django-redis: Settings Per Environment.

Run exactly one beat process per environment. Its schedule is CELERY_BEAT_SCHEDULE in the settings file; the harness file shows one.

Static and Media Files

The base settings set STATIC_URL, MEDIA_URL and MEDIA_ROOT, but no STATIC_ROOT. Set STATIC_ROOT in the settings file, run python manage.py collectstatic --noinput on every deploy, and serve both directories from the web server. The service serves media itself only under DEBUG.

TMP_DIR, DATA_DIR, EXPORT_DIR and PRIVATE_DIR must be writable by the app user. PRIVATE_DIR holds customer files and is never served.

Mail

The Django EMAIL_* settings are the fallback. EMAIL_SMTP_CONFIGURATION_CHANNELS sets SMTP per channel; the email module reads it. The email.smtp configuration check reports a channel without working SMTP, see Configuration Health.

The Two Frontends

Admin CMS. npm run build produces a static app for the web server. Its variables and the builder configuration: Admin CMS.

Storefront. pnpm build bakes _CONFIG/ in and pnpm start serves the build. The files and their keys: Storefront.

After Every Deploy

1. make health in the service checkout.

2. The configuration checks:

   python manage.py check --database default --tag entirius_config --fail-level WARNING

3. The post-deploy gate.

Next

Configuration Health