CALENDAR_ENCRYPTION_KEY was named after the calendar module because that
module needed encryption first, in Phase 5. Every feature since has shared the
same key -- SMTP, the DKV and tender mailboxes, and as of today the LDAP bind
password -- so the name has been describing one of five users rather than the
thing itself, and each new feature inherited the confusion.
TESSERA_ENCRYPTION_KEY is the name now. The old one is still read, because
renaming outright would stop every existing installation at the next start:
their .env carries the old name, and compose was just made to fail hard on a
missing key. When only the old name is present the API logs a deprecation
warning naming both, and when both are set the new one wins -- otherwise a
half-migrated .env would encrypt with one key and decrypt with the other.
CalendarCryptoService becomes CryptoService in its own global CryptoModule.
Four modules used to import CalendarModule purely to reach the provider, which
read as a dependency on calendars where there was none; that import is gone.
Compose keeps the hard failure: without either name the stack refuses to
start. Verified in both files for all three cases -- neither name set (abort),
only the old name (starts), only the new name (starts).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The base compose file carried a hardcoded fallback key, so a stack whose .env
never set the variable started anyway and encrypted every stored credential
(LDAP bind, calendar, SMTP, DKV and tender mailboxes) with a value that is
public in this repository. That is encryption which looks present and protects
nothing.
Both compose files now use the ${VAR:?message} form, so an unset or empty key
fails at compose level with a message naming the variable and how to generate
one, instead of starting with a known key or dying later inside the API with a
stack trace.
Verified both ways: without the variable `docker compose config` exits 1 and
prints the hint; with a key present it exits 0.
Consequence for a fresh clone: the local stack no longer comes up until
CALENDAR_ENCRYPTION_KEY is set in .env. That is the point.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- Add CALENDAR_ENCRYPTION_KEY env var to docker-compose api service
- Push CalendarSource table to live PostgreSQL (16 columns verified)
- Regenerate Prisma client with CalendarSource model
- DB reports in sync on second push (no drift)
- Use window.location.href for full page reload after login (ensures auth state)
- Add API_INTERNAL_URL for server-side requests within Docker network
- Remove unnecessary credentials:'include' from SSR fetch calls
- Update planning state for Phase 03 progress
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Next.js 15 app with Tailwind CSS v4, standalone output for Docker
- Root layout with de locale, page with Tessera placeholder
- Multi-stage Dockerfile for web with monorepo root context
- Docker Compose with 4 services: traefik, web, api, db
- Three segregated networks: frontend-net, backend-net, data-net (internal)
- Traefik v2.11 reverse proxy routing / to web, /api to api
- API strip prefix middleware for clean routing
- PostgreSQL 16-alpine with health checks and named volume
- Fixed API Dockerfile for pnpm monorepo node_modules structure
- Fixed Next.js standalone path for monorepo (apps/web/server.js)
- Fixed Traefik Docker API version compatibility
- Network segmentation: web NOT on data-net, api NOT on frontend-net
schalli