feat(deployment): add Coolify Compose templates for Postgres and SQLite

[flyingwebie]

Adds Coolify as a documented deployment target, alongside the existing Railway, Render, VPS Compose, and generic Docker paths.

What changed

• docker-compose.coolify.yml — bundled Postgres 16 stack, app gated on a Postgres readiness healthcheck.
• docker-compose.coolify.sqlite.yml — single-container SQLite stack.
• docs/deployment/coolify.md — setup walkthrough, database trade-offs, domains/PUBLIC_ORIGIN, secret-key handling, persistence, updating, ARM64 notes.
• docs/deployment/README.md — Coolify row in the TL;DR table, docs inventory, and Related file list.
• scripts/build-release-bundle.ts — ships both Compose files and coolify.md in the release bundle, with a Coolify section in the generated install notes.
• src/__tests__/server/dockerConfig.test.ts — a coolify docker config suite gating the invariants below.

Why Coolify needs its own Compose files

Coolify reads a single Compose file as the source of truth — there is no -f a.yml -f b.yml overlay mechanism — so these are standalone rather than a layer on compose.prod.yml. Both files deliberately omit networks:, ports:, container_name:, and restart:, because Coolify owns the per-stack bridge network, the Traefik route, and the container lifecycle. Declaring any of them fails silently rather than loudly (a second network makes Traefik route non-deterministically; a published port bypasses the proxy and would expose Postgres on the VPS), so the test suite gates them instead of leaving it to review.

Two settings are load-bearing and easy to get wrong:

• PUBLIC_ORIGIN=${SERVICE_URL_INSTATIC} — Coolify's Traefik terminates TLS and forwards plain HTTP, and server/auth/security.ts deliberately never trusts X-Forwarded-Proto/Host. resolvePublicOrigins() in server/config.ts auto-detects Render and Railway but has no Coolify branch, so without this the server believes it is http:// and four things degrade — only one of them loudly: the session cookie loses its Secure flag, the CSRF origin check compares the wrong origin, the collab WebSocket upgrade is rejected by that same guard, and MCP connector URLs resolve local-only.
• INSTATIC_SECRET_KEY=${SERVICE_REALBASE64_32_INSTATIC} — the image runs NODE_ENV=production, where server/secrets/masterKey.ts fails boot unless the key decodes to exactly 32 bytes. Coolify's REALBASE64_32 emits base64 of 32 random bytes; the similarly named BASE64_32 emits a bare 32-character string that is not base64 and would fail validation.

The SQLite stack mounts /app/uploads and /app/data as two named volumes rather than one shared root, because the Dockerfile creates exactly those two paths and chowns them to bun before USER bun. A volume mounted at a path the image does not contain — notably the single /app/storage root the Railway and Render templates use — is created root-owned and every write fails with EACCES. Railway works around that with RAILWAY_RUN_UID=0; there is no equivalent escape hatch here.

Impact

Operators get a Coolify install that is deploy-and-assign-a-domain, with Coolify generating the Postgres password and master key once and keeping them stable across redeploys. No runtime, server, or schema code changes — this is deployment configuration, docs, and tests only.

Verification

bun run build   # tsc -b && vite build — clean
bun test        # 6747 pass, 0 fail
bun run lint    # clean

docker compose -f docker-compose.coolify.yml config
docker compose -f docker-compose.coolify.sqlite.yml config
docker compose -f compose.prod.yml -f compose.sqlite.yml -f compose.build.yml config

Branch is rebased onto current main and contains a single commit.

🤖 Generated with Claude Code