BBergleandClaude Sonnet 5
5d4d76203f
Phase 0 deployment: three-service docker-compose.yml (caddy, api, db), a Caddyfile that proxies /api/* to the api service and serves the SPA with index.html fallback, and two Gitea Actions workflows (release.yml builds and pushes both images on a v* tag or manual dispatch; deploy.yml is manual-only and rolls them out to the Unraid host). The non-obvious part is the Docker-outside-of-Docker constraint on this act_runner setup: job containers share the host's Docker daemon over the socket but do NOT share its filesystem, so any command whose correctness depends on a client-side local path (docker cp to a host path, mv/rm -rf on a host path, a bind-mount source path on a `docker run` command line issued from inside a job) silently operates on the ephemeral job container's own throwaway filesystem instead. Two things are safe: a bind mount declared in a compose file's `volumes:` block (resolved by the daemon when `docker compose up` creates the service — this is why db's pgdata bind mount is fine), and a named volume populated by a one-shot `docker run` whose *command* does the copying (this is why the web image's static build output goes into a `web_build` named volume via `docker run -v ... sh -c 'cp -a ...'` in deploy.yml, rather than any `docker cp`). Local verification (see PR description for full detail) caught a real bug: `docker compose run api alembic upgrade head` needs VELODROME_DB_APP_PASSWORD/VELODROME_DB_AUTH_PASSWORD as container env vars to create the two runtime roles, but --env-file alone doesn't inject them since the api service's permanent environment block deliberately omits them (least-privilege — the long-running app should never need role-creation passwords). Fixed by passing them as explicit -e overrides on the migration step, same as VELODROME_DATABASE_URL_MIGRATE. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
35 lines
2.1 KiB
Bash
35 lines
2.1 KiB
Bash
# Copy this to /mnt/user/appdata/velodrome/.env on the Unraid host and fill in real values.
|
|
# Never commit the real .env — only this example, with placeholders, belongs in git.
|
|
|
|
# --- Postgres superuser (used to create the `velodrome_app`/`velodrome_auth` roles at migration
|
|
# time, and as the container's own POSTGRES_PASSWORD; never held by the long-running api process) ---
|
|
POSTGRES_SUPERUSER_PASSWORD=changeme-superuser
|
|
|
|
# --- Per-role app passwords (used to build the DSNs below) ---
|
|
VELODROME_DB_APP_PASSWORD=changeme-app
|
|
VELODROME_DB_AUTH_PASSWORD=changeme-auth
|
|
|
|
# --- DSNs. `db` is the in-compose-network hostname of the `db` service (not localhost, not the
|
|
# host's IP) — Docker's embedded DNS resolves it for any container on the same compose network. ---
|
|
VELODROME_DATABASE_URL_APP=postgresql+asyncpg://velodrome_app:changeme-app@db:5432/velodrome
|
|
VELODROME_DATABASE_URL_AUTH=postgresql+asyncpg://velodrome_auth:changeme-auth@db:5432/velodrome
|
|
# VELODROME_DATABASE_URL_MIGRATE is deliberately NOT set here. It's the Postgres superuser DSN,
|
|
# used only for the one-off `alembic upgrade head` step in deploy.yml, passed as an inline `-e`
|
|
# override built from POSTGRES_SUPERUSER_PASSWORD above. The long-running api service never gets
|
|
# it. See apps/api/README.md's "Why two database connections".
|
|
|
|
# --- App settings ---
|
|
# Not yet used by anything (arrives with Bryton credential encryption in a later phase) — declared
|
|
# now so the settings shape is stable. Generate with e.g. `openssl rand -hex 32`.
|
|
VELODROME_SECRET_KEY=changeme-secret-key
|
|
VELODROME_ENVIRONMENT=production
|
|
# Must exactly match how the app is actually reached — it's compared against the request's Origin
|
|
# header on cookie-authenticated mutations (CSRF check; see velodrome/auth/dependencies.py). If
|
|
# this doesn't match byte-for-byte how a browser reaches the app, authenticated POST/PUT/DELETE
|
|
# requests will be rejected.
|
|
VELODROME_PUBLIC_URL=http://192.168.0.103:8090
|
|
|
|
# --- Image tag to deploy. release.yml pushes both the git ref name and `latest`; deploy.yml's
|
|
# `tag` workflow_dispatch input picks which one to pull. ---
|
|
TAG=latest
|