First Production Deployment

A generated Djass app needs a production environment, an application image, HTTPS routing, and a verified user workflow before you invite customers. A successful local boot or a green web container does not prove that email, background jobs, or uploaded files will work after deployment.

Use this checklist inside your downloaded project, after completing local development. It covers the bundled single-server Docker Compose path, not the hosted Djass generator's infrastructure. Your generated files remain the reference for older downloads. This is a preparation and acceptance guide, not a claim that your server has been deployed or tested.

1) Identify the files you will operate

The production Compose file references an image; it does not build one. Both backend and workers use APP_IMAGE, falling back to the generated project's local :latest tag. A registry image must exist and be accessible to this server; an unpushed image on your laptop is not available on a remote host.

The generated repository also includes deployment material for other platforms. Choose one deployment path rather than mixing commands from its Fly, Render, and CapRover examples. The commands below apply only to docker-compose-prod.yml.

2) Prepare private production settings

Create a separate production configuration; do not upload your development .env unchanged. Follow the environment-variable checklist for URL overrides and container connection addresses.

Before starting services, verify:

• ENVIRONMENT=prod and DEBUG=off. These are separate settings: production mode does not override an explicitly enabled debug flag.
• SITE_URL is your public HTTPS origin. The bundled settings derive allowed hosts and trusted CSRF origins from it; adding an arbitrary ALLOWED_HOSTS environment variable does not change that implementation.
• SECRET_KEY, database credentials, and Redis credentials are unique private values, not the example defaults. Keep them out of Git, image layers and shared command output.
• Web and workers use the same database, broker, queue name and release image. For the bundled Compose services, db and redis are internal network names. External services require their own reachable addresses and credentials.
• Production email reaches a real inbox. With debug disabled, no explicit EMAIL_BACKEND override and no Mailgun key, the bundled fallback writes email to the console. Mandatory account email verification still needs a delivery path; seeing the homepage is not a signup test.

Production mode enables HTTPS redirects, secure cookies and HSTS defaults. Configure TLS and a trusted reverse proxy accordingly. The app trusts the forwarded HTTPS header in production: your proxy must set it correctly and prevent clients from supplying a trusted value directly to the backend. Review Django's deployment checklist against your actual settings before enabling customer access.

3) Build or pull one identified application image

For a locally built image on the deployment host, the following illustrative commands use example-app:first-release and first-release as image and revision labels. Replace both with your own release identifiers. A commit SHA makes comparison with your source revision easier.

export APP_IMAGE=example-app:first-release
docker build --build-arg DEPLOYMENT_REVISION=first-release -f deployment/Dockerfile -t "$APP_IMAGE" .

Keep APP_IMAGE set for subsequent Compose commands, or put its non-secret image reference in the production .env. If your pipeline already builds and pushes an immutable image, set that reference instead and pull it on the host. Do not build a different image for the worker.

These commands follow the bundled Dockerfile and Compose configuration checked October 21, 2026. The image builds frontend assets before copying them into the runtime image; the server entrypoint runs collectstatic. This path does not run the local frontend watcher or offer a separate frontend port.

4) Review startup and persistence before exposing the app

The bundled backend publishes 8000:8000. When a reverse proxy runs on the same host, restrict that binding in your deployment copy to 127.0.0.1:8000:8000 and route public HTTPS through the proxy. Other proxy/network layouts need an appropriate private binding and firewall policy. Port publication alone does not configure a domain, certificate or renewal.

The server entrypoint waits for the database, collects static files, applies migrations, then starts Gunicorn. The worker starts the generated runworker command. For the first single-server release, review pending migrations before startup. For later releases or multiple web replicas, plan migration ordering and compatibility deliberately; this is not a zero-downtime rollout recipe.

The Compose file declares PostgreSQL and Redis volumes, but no application media volume. If uploads use the local filesystem, choose durable media storage and a serving path before accepting files. If you enabled S3-compatible storage, verify the actual provider, bucket and access policy using the storage guide; presence of an integration is not proof of private-file access control. Keep a tested database restore procedure using the backup guide. A named volume is not a backup.

5) Start, inspect, then test a real workflow

After the configuration, image and network checks above, run these from the project root on your deployment host:

docker compose -f docker-compose-prod.yml up -d
docker compose -f docker-compose-prod.yml ps
docker compose -f docker-compose-prod.yml logs --tail=100 backend workers
docker compose -f docker-compose-prod.yml exec backend uv run --no-sync python manage.py check --deploy

The service names and management command follow the bundled Compose file, entrypoint and Django 6 deployment checks. Investigate warnings in context; do not hide an unsuccessful command with || true. Inspect logs privately and redact credentials or account details before sharing them. Consult Docker's production guidance for process restart and host-operation planning; do not assume the supplied Compose file already implements your restart policy.

Before inviting users, verify:

1. Your public HTTPS URL loads the expected release, including CSS and admin assets. Inspect /api/healthcheck and compare its revision with the image you built, rather than accepting a response from an older deployment.
2. Both web and worker containers become healthy. The generated /api/healthcheck/workers endpoint checks recent, revision-scoped worker readiness when a deployment revision is configured; it is not proof that your business task completed. Follow the worker troubleshooting guide and verify the result of one bounded task your app actually uses.
3. A test account can receive its verification message, finish signup, sign in and sign out through the production domain. Check password recovery if your chosen authentication flow uses it.
4. If your app accepts uploads, a test file survives recreation of the app container and has the intended access rules. Test in an isolated acceptance environment before using customer data.
5. The previous application image and a tested data recovery path are known. Reverting an image does not automatically undo database migrations.

Do not delete volumes to troubleshoot a failed release. If one check fails, fix that layer and repeat the affected acceptance check. Once the release works, use the first-feature workflow to ship your next user outcome with its own tests.