Shift production server off of runserver?

[jonfroehlich]

We are currently using runserver on both test and production (see docker-entrypoint.sh). It appears we should not be. In fact, the official docs say:

DO NOT USE THIS SERVER IN A PRODUCTION SETTING. It has not gone through security audits or performance tests. (And that’s how it’s gonna stay. We’re in the business of making web frameworks, not web servers, so improving this server to be able to handle a production environment is outside the scope of Django.)

Others agree.

So, it seems like we need to run with Gunicorn or Apache. See: https://docs.djangoproject.com/en/4.2/howto/deployment/

We want to keep our test and production environments simple and similar but we are running into some major latency issues (#959) that we need to address

[jonfroehlich]

Reframe: this doesn't require UW CSE IT after all.

Dug into the actual serving setup. The Django process runs inside our Docker container, which we control via push-to-deploy; Apache (IT's) only sits in front as a reverse proxy to 127.0.0.1:8571. Swapping the in-container server (runserver → Gunicorn) leaves the port mapping and everything Apache sees identical, so it ships on the normal path — push to master → test, tag → prod. No shell access, no Apache edits, no IT ticket.

One assumption to confirm with @mechanicjay (verification only, not a change): that Apache serves /static/ and /media/ from the filesystem rather than proxying them to the container. Almost certainly yes — prod runs DEBUG=False, and runserver refuses to serve static when DEBUG=False, yet our CSS/JS work in prod, so Apache must already be serving it.

Why it's necessary

• Security — Django's docs are explicit that runserver is unaudited and unfit for production.
• Robustness/concurrency — Gunicorn gives managed workers, crash-restart, and request timeouts; runserver also runs a filesystem auto-reloader that just wastes CPU on a server where files only change at deploy.
• Not a latency fix — the Makeability Lab website slow to load #959 slowness was N+1 queries (since fixed via the ORM). Gunicorn won't speed up a single render; it makes serving production-grade.

What's done (branch 1034-gunicorn, PR #1385)

• requirements.txt: add gunicorn==23.0.0
• docker-entrypoint.sh: run Gunicorn when DJANGO_ENV is TEST/PROD; keep runserver for local dev (DJANGO_ENV=DEBUG) so auto-reload, debug toolbar, and DEBUG=True static serving still work.
• Defaults tuned for the shared host: 3 workers, 120s timeout (avoids killing slow ImageMagick/PDF thumbnail ops), both overridable via GUNICORN_WORKERS / GUNICORN_TIMEOUT.

Rollout: push to master, verify on -test (browse pages; save an admin record with an image upload; confirm static/media load), then tag for prod. Trivially reversible — revert two lines, redeploy.