Files
Hartmut 4a5edeef3e
CI / Unit Tests (pull_request) Successful in 5m46s
CI / Lint (pull_request) Failing after 3m49s
CI / E2E Tests (pull_request) Has been skipped
CI / Fresh-Linux Docker Deploy (pull_request) Has been skipped
CI / Assistant Split Regression (pull_request) Failing after 35s
CI / Architecture Guardrails (pull_request) Failing after 2m14s
CI / Typecheck (pull_request) Successful in 4m22s
CI / Build (pull_request) Has been skipped
CI / Release Images (pull_request) Has been skipped
rename(phase 1): CapaKraken → Nexus across code, UI, docs, CI
- @capakraken/* → @nexus/* across 12 packages (root + 11 workspaces),
  1551 import lines migrated via codemod
- User-visible brand strings renamed (emails, page titles, PWA
  manifest, mobile header, MFA backup-codes header, tooltips, signin
  page, invite page, weekly digest, install prompt)
- TOTP issuer "CapaKraken" → "Nexus" (existing secrets still valid;
  re-enrollment relabels them in users' authenticator apps)
- Function rename: assertCapaKrakenDbTarget → assertNexusDbTarget
- LocalStorage migration shim in apps/web/src/app/layout.tsx copies
  capakraken_* → nexus_* on first load (guarded by nexus_migrated_v1
  sentinel; runs once per browser, then never again)
- Service-worker cache name capakraken-v2 → nexus-v2 with one-time
  caches.delete('capakraken-v2') from the same shim
- Email-domain fixtures @capakraken.{dev,app} → @nexus.{dev,app} in
  seed data, e2e specs, SMTP default fallback
- Dockerfile.dev / Dockerfile.prod / all .github/workflows/*.yml
  pnpm --filter @capakraken/* → @nexus/*
- README, CLAUDE.md, LEARNINGS.md, all docs/*.md, .env.example,
  tooling/deploy/.env.production.example brand sweep

Phase 1 deliberately leaves untouched (handled in Phase 3 cutover):
- PostgreSQL DB name "capakraken" and POSTGRES_USER "capakraken"
- Volume names capakraken_pgdata etc.
- Compose project name "capakraken" / "capakraken-prod"
- db-target-guard default expectedDatabase
- env-var CAPAKRAKEN_EXPECTED_DB_NAME
- Container DNS names in docker-compose.ci.yml

Quality gates green: pnpm typecheck (7/7), pnpm test:unit (7/7),
pnpm lint (0 errors), check:exports/imports/architecture all pass.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-05-21 15:10:44 +02:00
..

Deploy Tooling

This directory contains the canonical host-side tooling for the image-based staging and production path.

Files

  • deploy-compose.sh: validates compose input, pulls images, runs migrations, starts the app, and waits for readiness
  • .env.production.example: example host-side runtime configuration
  • deploy.env.example: example short-lived deployment manifest written by GitHub Actions

Host Layout

On the target host, the deploy directory should contain:

<deploy-path>/
  docker-compose.prod.yml
  deploy.env
  .env.production
  tooling/deploy/deploy-compose.sh

deploy.env is ephemeral and written by GitHub Actions for one deployment. .env.production stays on the host and contains the long-lived runtime secrets and app configuration.

First Setup

  1. Copy tooling/deploy/.env.production.example to the target host as .env.production.
  2. Fill in the required secrets and URLs.
  3. Keep RATE_LIMIT_BACKEND=redis so production uses the shared counter path intentionally.
  4. Copy tooling/deploy/deploy.env.example to the host only if you want to dry-run the deploy script manually.
  5. Replace the placeholder images in deploy.env.example with a real sha-<commit> tag and save it as deploy.env for a manual dry run.
  6. Provision runtime AI/SMTP/anonymization secrets on the host through .env.production or the platform's secret facility.
  7. Keep admin settings for status/verification only; do not use them to enter or rotate operational secrets.
  8. After migration, use the admin cleanup action to remove any legacy database-stored runtime secrets.
  9. Ensure Docker Engine and Docker Compose v2 are installed.
  10. Ensure the target host can pull from ghcr.io.
  11. A normal release no longer needs a Git checkout on the host. The host only needs the deploy bundle plus the two env files.
  12. Merge to main, let release-image.yml publish the immutable images, then run the staging or production deploy workflow with the same image tag.

Manual Host Test

After the files are present on the host, the canonical flow can be tested manually:

set -a
. ./deploy.env
set +a
bash tooling/deploy/deploy-compose.sh staging