41f7099fb3
disclosure-realtime had been restarting on a ~60 s cycle since the stack was
brought up — RestartCount climbed past 29,000. The seed step crashed with
`{:badarg, 'Bad key size'}` from `:crypto.crypto_one_time(:aes_128_ecb,
"ca2c785fedb0a728dbf2c0e4fcb5d2bf", …)`. The Supabase Realtime image expects
DB_ENC_KEY to be a raw 16-byte key for AES-128-ECB, but VAULT_ENC_KEY (the
value it was being mapped to) is a 32-char hex string — 32 bytes when read
verbatim, which AES-128 rejects.
Fix: separate the realtime key from the Vault key. New env REALTIME_ENC_KEY
holds a fresh 16-byte ASCII string and the compose now maps DB_ENC_KEY to
that. VAULT_ENC_KEY stays untouched for whenever the Postgres Vault
extension is actually used (`vault.secrets` has zero rows, so nothing was
encrypted under the old shared key).
Verified live: realtime restarted clean (Restarts=0, ExitCode=0, stable
across 100 s of polling), seed succeeded (public.tenants now has the
'realtime-dev' row), Tzdata refreshed to 2026b, RealtimeWeb.Endpoint
listening on :4000. The dockerd churn from ~one recreate per second is
gone.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|---|---|---|
| .. | ||
| coolify | ||
| disclosure-stack | ||
| embed-service | ||
| supabase | ||
| DEPLOY-CHECKLIST.md | ||
| README.md | ||
| RETRIEVAL.md | ||
Infrastructure — Disclosure Bureau
Self-hosted stack on a single VPS (16 GB / 4 CPU / 200 GB NVMe) managed via Coolify.
Internet (443/80)
│
┌─────────▼─────────┐
│ Caddy (Coolify) │ ← auto-TLS Let's Encrypt
└────┬──────────────┘
│
┌─────────────┼──────────────────────┬──────────────────┐
▼ ▼ ▼ ▼
┌─────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ Next.js │ │ Supabase │ │ Supabase │ │ shared │
│ web │ │ disclosure│ │ project-B │ │ services │
│ :3000 │ │ stack │ │ stack │ │ Meili··· │
└─────────┘ │ ┌─────┐ │ │ ┌─────┐ │ │ Imgproxy │
│ │PG/GT│ │ │ │PG/GT│ │ │ Dragonfly│
│ └─────┘ │ │ └─────┘ │ └──────────┘
└──────────┘ └──────────┘
disclosure.top projeto-b.com
Components
| Layer | Service | Notes |
|---|---|---|
| Orchestration | Coolify v4 | Self-hosted PaaS — manages all containers, TLS, backups |
| Database + Auth + Storage | Supabase self-hosted (one per project) | Each project gets own Postgres + GoTrue + Storage |
| Frontend | Next.js 15 (this repo's /web) |
Deployed via Coolify Git integration |
| Search | Meilisearch (shared) | Full-text search across pages + entities |
| Cache + Queue | Dragonfly (shared) | Redis-compatible, multi-threaded |
| Images | Imgproxy (shared) | On-the-fly resize / WebP conversion |
| Backups | restic + Backblaze B2 | Nightly Postgres + Storage dumps |
Quick path
coolify/INSTALL.md— install Coolify on the fresh VPS (~10 min)coolify/SUPABASE.md— create thedisclosureSupabase project (~5 min)- Run
supabase/migrations/0001_chat_schema.sqlvia Supabase Studio SQL editor coolify/NEXTJS.md— deploy the/webapp pointing at the Supabase URLcoolify/SHARED.md— bring up Meilisearch, Dragonfly, Imgproxy
Adding more projects later
For each new project, repeat step 2 (new Supabase project in Coolify UI) and step 4 (new Next.js app). They get their own subdomain, own auth, own data. Total isolation.
Local development
For dev on macOS/Linux without the VPS, see ../web/README.md — uses the Supabase CLI to spin up a local stack on localhost:54321.