W08 | App en cloudstack komen tegelijk op hun plek

Build AI. Run AI. Own AI. — Week W08 · 16-22 februari 2026

Deze week staat de eerste PA-Service-code in Git. Ik begin meteen aan twee kanten: er moet een plek zijn waar de app kan draaien, en ik wil die omgeving niet met losse handmatige stappen bij elkaar houden. PA-admin komt als app-submodule in de nieuwe repo; daarnaast richt ik Compose, Flyway en Terraform in.

Lokaal kan dezelfde Compose-definitie met een andere omgevingsconfiguratie starten. `docker compose --env-file .env.dev` en `.env.acc` geven de services hun eigen waarden. Setup en start doen ander werk: setup importeert onder meer n8n-credentials via de CLI in de container, terwijl start de bestaande omgeving gebruikt. Een JSON-template krijgt de databasewaarden uit het gekozen env-bestand. Workflowconfiguratie kan zo versieerbaar blijven zonder omgevingsgeheimen erin vast te zetten.

Aan de cloudkant is Terraform niet alleen een mapje met resources. Ik beschrijf Scaleway-projecten per klant en werk aan PostgreSQL, een container registry en Serverless Containers voor n8n en PA-admin. Daarmee krijgt de app een route naar een echte omgeving terwijl ik tegelijk de backend eromheen opzet. De `SCW_ORGANIZATION_ID` en het project-ID zijn daarbij echte inputs: als die niet kloppen, kan Terraform wel draaien maar komt de stack niet in de plek die ik bedoel.

Flyway geeft databasewijzigingen een reproduceerbaar pad; Terraform moet de cloudresources kunnen aanmaken; Compose brengt services lokaal samen. Dat is al veel structuur voor de eerste week. Ik vind het fijn dat de app en de basisomgeving tegelijk vorm krijgen, maar ik zie ook dat “de app staat” uit verschillende stukken bestaat: UI, database, runtime en rechten moeten elkaar vinden.

Ik kies ook voor Git-submodules. Nu voelt het logisch om onderdelen hun eigen repository te laten houden. Of die repo-grenzen prettig blijven wanneer ik vaker tegelijk aan app en platform werk, moet nog blijken.