Deployment
How the frontend, docs and backend reach production today, and what a deploy affects.
Two lanes, with the manual backend steps listed.
Frontend and docs: automatic
Both are Vercel projects connected to the same GitHub repository, each with its own root directory (app/ and docs-site/). Every push to main triggers a build and production deploy of each project. NEXT_PUBLIC_* variables are set in each Vercel project and inlined at build time.
Backend: manual
Full runbook
There is no CI/CD pipeline for the backend yet. A deploy is:
Update the code on the server
Pull the latest main in the repository checkout on the server.
Rebuild and restart
From infra/, rebuild and recreate the changed services with the production compose file and env file:
docker compose -f docker-compose.yml --env-file prod.env up -d --build api worker--env-file matters: it supplies the values Compose substitutes into the infrastructure services.
Apply migrations, if any
If the release adds an Alembic migration, run alembic upgrade head inside the API container. The API's startup create_all() creates missing tables but never alters existing ones.
What a deploy interrupts
| Service recreated | Effect |
|---|---|
api | A few seconds of failed requests while Uvicorn restarts (single instance, no rolling update) |
worker | The video being processed is interrupted; on startup the worker marks it failed and starts the next queued video. It has to be re-queued. |
| Others | Untouched unless their configuration changed |
An upload that starts or finishes while the API is restarting can have its tusd hook call fail, since hooks are handled by the API.
First-time setup
A new server also needs: Docker, the env file created from infra/.env.example, a production Caddyfile from the example, DNS for the API domain, public-read access on the processed and thumbnail buckets, and an admin user promoted in the database.
What a production-grade pipeline would add
- Build images in CI, push them to a registry, and only pull on the server (no compilation on the production box).
- Run migrations automatically as a release step.
- Health checks and a graceful worker shutdown period, so deploys wait for the current task.
- Backups of PostgreSQL and MinIO before each deploy.
See Improvements.