Dockerfile (repo root) builds a single OCI image with the Vite frontend already built in, and a .venv with all Python deps. At runtime it uses supervisord (deploy/docker/supervisord.conf) to run two processes in the one container:

web - one daphne process serving the Django/Channels app on :8000
worker - two rqworker processes for background jobs (submission OCR, AAndT sync, etc.)

Postgres, Redis and S3-compatible storage are not bundled (see deploy/docker/polylan-submitter.env.dist for the full list of env vars: POSTGRES_*, REDIS_HOST/REDIS_PORT, AWS_*, DJANGO_SECRET_KEY, etc.). Point those at wherever those services already live (other containers/LXCs, or existing infra).

Build

Requires BuildKit/buildx (RUN --mount=type=cache in the Dockerfile is rejected by the legacy builder):

docker buildx build --load -t polylan-submitter .

Run

docker run -d \
  --name polylan-submitter \
  --env-file deploy/docker/polylan-submitter.env \
  -p 8000:8000 \
  polylan-submitter

Migrations run automatically on container start (set MIGRATE_ON_START=false to skip). collectstatic does not run automatically - it pushes to the shared S3 bucket, so run it once per deploy instead of racing multiple replicas on every boot:

docker run --rm --env-file deploy/docker/polylan-submitter.env \
  polylan-submitter python manage.py collectstatic --noinput

Scaling

There's one daphne process per container - it binds the only port the container exposes, so running more of them would need a reverse proxy inside the container too. Scale by running multiple container replicas behind an external reverse proxy/load balancer instead (each replica also runs its own pair of rqworker processes, so worker capacity scales the same way).

Deploying to Proxmox

Recent Proxmox VE versions can create an LXC container directly from an OCI image (pct create <vmid> <image-ref> ... with an OCI-format image reference, currently a tech-preview feature - check pct create --help and the Proxmox VE docs for your installed version, since the exact flags have been changing across releases). Practically that means:

Push the built image to a registry Proxmox can reach (a local registry, GHCR, Docker Hub, etc.) - docker tag/docker push.
Create the container on the Proxmox host from that image reference, passing the same env vars as above.
Map/forward port 8000 as needed, and put whatever TLS-terminating reverse proxy you already run in front of it.

If OCI-to-LXC isn't available on your Proxmox version, the same image runs fine in a plain VM (or an LXC) with any container runtime (Docker/Podman) installed instead.