siftlode/deploy/README.md
npeter83 c19f4d9d31 chore(repo): remove internal deployment plan, sanitize infra references
Drop docs/deployment-plan.md (internal planning doc, kept out of the repo) and
replace the personal lab DB IP and host names in the env/compose/deploy docs with
generic placeholders, so the repo is safe to make public later.
2026-06-14 23:20:02 +02:00

2.1 KiB

Deploying Siftlode to the public VPS

The public test instance runs on a VPS at https://siftlode.b1fr0st.eu, behind Caddy (which terminates TLS and reverse-proxies to the app on 127.0.0.1:8080).

Layout on the host

/srv/siftlode/
  src/                 git clone of this repo (build context + compose file)
  .env                 secrets, mode 0600 — NEVER committed

The hardened compose is docker-compose.prod.yml: Postgres is never published, the app binds to localhost only, and every service is memory/CPU-capped for the small VPS.

First-time setup

  1. DNS A/AAAA for siftlode → the VPS (via your DNS provider).

  2. Caddy vhost block siftlode.b1fr0st.eu { reverse_proxy 127.0.0.1:8080 } (+ the shared security-headers snippet), then reload Caddy.

  3. git clone this repo to /srv/siftlode/src.

  4. Create /srv/siftlode/.env (mode 0600) with the required keys — see .env.example. Generate the secrets:

    • SECRET_KEY: python -c "import secrets; print(secrets.token_urlsafe(48))"
    • TOKEN_ENCRYPTION_KEY: python -c "from cryptography.fernet import Fernet; print(Fernet.generate_key().decode())"
    • POSTGRES_PASSWORD: any long random string.
    • OAUTH_REDIRECT_URL=https://siftlode.b1fr0st.eu/auth/callback
    • GOOGLE_CLIENT_ID / GOOGLE_CLIENT_SECRET / YOUTUBE_API_KEY from Google Cloud Console.
    • ALLOWED_EMAILS / ADMIN_EMAILS = the invited Google accounts.

    The app refuses to start in production (an https redirect URL) if SECRET_KEY is the placeholder/too short or TOKEN_ENCRYPTION_KEY is missing — by design.

Rolling out a new version

/srv/siftlode/src/deploy/deploy.sh

It pulls main, rebuilds the image on the host, and restarts the stack (migrations run automatically via the entrypoint's alembic upgrade head).

CI

.forgejo/workflows/ci.yml type-checks/builds the frontend and byte-compiles the backend on every push to main. It does not auto-deploy; rollout is the script above. (A future improvement: a Forgejo-triggered or watchtower-based auto-rollout.)