Master dashboard op Coolify

Live gecontroleerd op 9 september 2026

Het masterdashboard draait op https://dashboard.okhema.studio, Coolify-app kziwszehmo3orgugjc6sq3d5 in project Okhema / production. De voorbereiding hieronder is historisch; app, beheerder en integraties zijn inmiddels aanwezig.

• Actieve release: cd0472b312564360e4c8f1c303099107d852487c, deployment qm72bxkhd6zx9evwemyhqbhn. Container healthy, netwerk coolify, healthcheck /login op poort 3000.
• Vastgesteld: Coolify 4.3.18, Node 22.23.2, Nuxt 4.5.2, Nitro 2.13.4, PostgreSQL 18.6. De npm-registry bevestigt Nuxt 4.5.2 als latest en Node ^22.19.0 || ^24.11.0 || >=26.0.0 als eis. Geen dependencies toegevoegd.
• Alle vijf mastermigraties (0000–0004) toegepast; herhaling slaagt zonder extra migraties. Voor 0004 is een verse databasebackup gemaakt.
• Echte masterlogin via Better Auth geslaagd; geauthenticeerd geven /api/session, /api/tenants en /migrations 200. Zonder sessie geeft /api/tenants 401. De bestaande beheerder is niet opnieuw aangemaakt.
• Bestaande auth-secret en NUXT_SECRETS_KEY behouden. Runtimeconfiguratie staat in /data/okhema/master/application.env (0600) en versleuteld in Coolify. Geen mastersecrets als buildvariabelen ingesteld.

Let op bij Restart: Coolify heeft bij deze herstart de huidige main gebouwd, niet uitsluitend het oude image hergebruikt. Daardoor kwam migratie 0004 mee; die is direct na de herstart toegepast. Bij volgende releases eerst de bedoelde commit en migraties controleren, backup maken en migreren voordat de app wordt gestart. Vertrouw niet op het label Restart om de release gelijk te houden.

Provisioningconfiguratie

De NUXT_COOLIFY_*-configuratie is ingevuld voor het bestaande project, environment en server. Eigen token okhema-master-provisioning met read, write, deploy; geen root of read:sensitive. Coolify beperkt dit token tot het team, niet tot uitsluitend het Okhema-project. De bestaande read-only GitHub-deploykey is via Coolify geregistreerd als okhema-readonly-deploy; repository git@github.com:Albatrauz/okhema.git, branch main.

NUXT_POSTGRES_ADMIN_URL gebruikt de nieuwe rol platform_provisioner: CREATEDB, CREATEROLE, geen superuser, met createrole_self_grant = 'set, inherit'. De normale platform_master-rol en tenantrollen hebben geen van die beheerrechten. De gedeelde S3- en Resend-instellingen zijn overgenomen uit de werkende pilotconfiguratie. NUXT_PREVIEW_BASE_HOST blijft preview.okhema.studio.

Backup en restore bewezen

De geplande backup van 9 september om 03:30 UTC voor platform_master heeft status success en s3_uploaded=true. Het dumpbestand van 23.788 bytes is daadwerkelijk uit R2 gedownload en met pg_restore --exit-on-error hersteld in platform_master_verify_20260909. Resultaat: tien applicatietabellen, één beheerder, één tenant en vier migraties (de stand van die nacht). De restore zelf duurde circa 0,19 seconde; dit is geen volledige RTO-meting. De controledatabase is daarna opgeruimd; productie is niet overschreven.

Na de integratieconfiguratie en migratie 0004 zijn een nieuwe masterdump en de herstelconfiguratie inclusief encryptiesleutel opgeslagen in de bestaande privébucket platform-backups, onder okhema-master/recovery/20260909/ (master.dmp en application.env). Beide objecten zijn teruggelezen en met SHA-256 vergeleken. Publieke r2.dev-toegang staat uit; de backupbucket heeft geen custom domains. De herstelconfiguratie bevat secrets en mag uitsluitend door bevoegde operators worden gelezen. Werk deze herstelkopie bij wanneer sleutels of integratiecredentials veranderen; de dagelijkse databasebackup doet dat niet automatisch.

Provisioningtest en resterende stappen

Afzonderlijke testtenant provision-check-20260909 is via het dashboard aangemaakt en geprovisioneerd; MAAKM Studio is niet gewijzigd. Coolify-app xriwqov8m9jgdqvjcigtazop is automatisch aangemaakt, gebouwd vanaf dezelfde release en healthy. Database, migraties, tenantsecrets, runtimevariabelen en previewdomeinen zijn automatisch ingesteld.

Provisioneren vult geen sitecontent en maakt geen CMS-gebruiker. De lege site gaf eerst 404 op / en 500 op /login door een ontbrekende site-rij. De bestaande operator-CLI is vervolgens gebruikt voor bootstrap (eerst dry-run) en een afzonderlijk test-CMS-account. Daarna bewezen:

• Publieke homepage en /robots.txt: 200.
• CMS-login: 200; echte aanmelding via Better Auth en geauthenticeerde CMS-homepage: 200.
• Geldig HTTPS voor publiek en admin.provision-check-20260909.preview.okhema.studio.
• /api/platform/health: 401 zonder sleutel, 200 met tenantsleutel en database: ok.

De testtenant blijft beschikbaar ter beoordeling. Het dashboard toont voor de preview nog In behandeling en voor de deployment running; dit zijn geen bevestigingen van de actuele Coolify-health of certificaatstatus. De testcredentials en operatorbestanden staan uitsluitend in /data/okhema/master/verify-20260909/ (directory 0700, secretbestanden 0600). De testdatabase is niet toegevoegd aan de dagelijkse backuplijst; voeg echte nieuwe klantdatabases wel expliciet toe aan planning ID 2.

Cloudflare for SaaS is tijdens deze controle door de gebruiker geactiveerd. customers.okhema.studio is aangemaakt als proxied A-record naar 88.99.184.55 en ingesteld als fallback origin; de API bevestigt active. Na expliciet akkoord is account-token okhema-master-custom-hostnames aangemaakt met uitsluitend SSL and Certificates Write voor okhema.studio. Alle drie NUXT_CF_*-variabelen zijn ingesteld; de token is runtime-only. De herstelkopie in R2 is bijgewerkt en teruggelezen. Masterdeployment qm72bxkhd6zx9evwemyhqbhn is geslaagd op dezelfde release.

Een volledige klantdomeintest is uitgevoerd met het externe DNS-domein saas-check.michaelvg.dev. Registratie via de master-API gaf 201 en maakte de Cloudflare-custom-hostname en Coolify-routing aan. Het DNS-only CNAME wijst naar customers.okhema.studio. Cloudflare bevestigde hostname en certificaat als active; de master-verificatie gaf eveneens active. Publieke DNS resolveerde naar Cloudflare-anycast, het certificaat was geldig en de response bevatte Server: cloudflare en CF-Ray. De homepage gaf in de browser en met een gewone browseridentificatie 200 en bevatte de content van de testtenant. Een kale Python-client kreeg 403 / Cloudflare-code 1010 door Browser Integrity Check; dat was geen routing- of certificaatfout.

De eerdere same-zone-proef saas-check.okhema.studio valideerde wel in Cloudflare, maar was geen geldig bewijs voor de SaaS-proxyroute omdat Cloudflare het CNAME binnen dezelfde zone naar het origin-adres kon afvlakken. Deze proef is na de controle verwijderd. De bestaande Traefik-DNS-token is niet verruimd.

Nog open:

• Nieuwe klanten hebben na provisioning nog content-bootstrap en een CMS-account nodig. Deze stap is niet geautomatiseerd in deze wijziging.
• Resend- en media-instellingen zijn gekoppeld, maar er is in deze test geen e-mail verstuurd of mediabestand geüpload. Webhooks zijn niet end-to-end getest. De bestaande pilotacceptatie blijft apart bewijs.

Voorbereid op 8 september 2026 (historisch)

• Dockerfile: apps/master-dashboard/Dockerfile, buildcontext de repository-root.
• Build en runtime getest met origin/main commit 66e64628d3889f907686887793a52a786f8f2992, plus deze Dockerfile en .dockerignore. De lokale checkout liep achter; bestaande wijzigingen zijn behouden. De Dockerfile moet nog naar de deploybranch worden gecommit/gepusht.
• Geteste versies: Nuxt 4.5.2, pnpm 11.20.0, Node 22.23.2, Drizzle ORM 0.45.2, postgres-js 3.4.9. Nuxt vereist Node ^22.19.0 || ^24.11.0 || >=26.0.0 (npm-registry gecontroleerd). De basisimage volgt Node 22 security-updates.
• Image okhema-master:66e6462-prep is lokaal gebouwd voor Linux ARM64 en op de VPS getest. Dit is een voorbereidingsimage, geen Coolify-deployment.
• Database platform_master is aangemaakt in de bestaande Postgres-resource fyr11h3mnrgkvhkhkrrxdb2b op netwerk coolify, met een eigen gelijknamige rol. Die rol heeft geen superuser-, CREATEDB- of CREATEROLE-rechten.
• Vier mastermigraties zijn toegepast: 0000 t/m 0003. Een tweede run slaagt zonder nieuwe migraties. Er staan tien applicatietabellen in schema public.
• Verbindingsstrings staan uitsluitend op de VPS in /data/okhema/master/database.env (directory 0700, bestand 0600, eigenaar root). Dit bestand bevat MASTER_DATABASE_URL voor de CLI en NUXT_DATABASE_URL voor de app. Waarden nooit in Git, build arguments of logs opnemen.
• platform_master is toegevoegd aan de bestaande ingeschakelde per-database Coolify-backup met S3-opslag (planning ID 2). De eerstvolgende geslaagde offsite-backup en een restore moeten nog worden gecontroleerd.

De tijdelijke testcontainer had geen gepubliceerde poorten en is verwijderd. Resultaten: /login 200, / 302 naar login, /api/session 200 met user: null, /api/tenants 401. Er zijn nog geen masterbeheerders of tenants aangemaakt. Een echte dashboardlogin en provisioning zijn hiermee nog niet getest.

Coolify-app aanmaken

1. Gebruik dezelfde repository met de deploybranch waarop deze Dockerfile staat.
2. Kies Dockerfile als build pack, buildcontext /, Dockerfile /apps/master-dashboard/Dockerfile, poort 3000.
3. Kies het dashboarddomein en laat het naar de VPS wijzen. Stel datzelfde HTTPS-origin in als NUXT_BETTER_AUTH_URL.
4. Voeg runtime-variabelen toe (geen build secrets):
   • NUXT_DATABASE_URL: bestaande waarde uit het afgeschermde serverbestand.
   • NUXT_BETTER_AUTH_SECRET: nieuwe willekeurige, blijvende auth-secret.
   • NUXT_BETTER_AUTH_URL: het gekozen HTTPS-origin.
   • NUXT_SECRETS_KEY: nieuwe 32-byte sleutel in base64. Bewaar deze veilig naast de databasebackups: bestaande tenantsecrets vereisen dezelfde sleutel.
   • NUXT_PREVIEW_BASE_HOST=preview.okhema.studio.
5. Controleer dat de app de Postgres-resource op netwerk coolify kan bereiken.
6. Stel de HTTP-healthcheck in op /login, poort 3000, status 200. De image bevat hiervoor curl en ook een eigen Docker-healthcheck. Deze controle toont HTTP-beschikbaarheid; zij vervangt geen database- of provisioningtest.

De volledige lijst integratievariabelen staat in apps/master-dashboard/.env.example. Coolify-, Cloudflare-, S3- en Resend-config zijn nodig voor de bijbehorende beheer/provisioningfuncties. Voor database- provisioning is een aparte beheerverbinding via NUXT_POSTGRES_ADMIN_URL nodig; geef de normale platform_master-rol hiervoor geen extra rechten.

Migraties vóór een volgende deployment

Bouw de image van de bedoelde release en maak eerst een databasebackup. Voer vervolgens op de VPS uit (vervang de imagetag):

docker run --rm --network coolify \
  --env-file /data/okhema/master/database.env \
  okhema-master:66e6462-prep node database/scripts/migrate-master.mjs

De image start migraties bewust niet automatisch bij iedere containerstart. Voer ze eenmaal uit per release voordat de nieuwe app wordt gestart. Het CLI gebruikt MASTER_DATABASE_URL; Nuxt gebruikt NUXT_DATABASE_URL. Een rollback van de app draait databasemigraties niet terug.

Maak daarna via de bestaande @platform/ops-CLI de eerste beheerder aan (zie Operations). Rond vóór ingebruikname een login, tenantbeheer, backup/restore en een volledige provisioningtest af.