Infrastructure and Deploy

What changes in CatalyzeUp/catalyzeup-devops (Terraform), in the Docker image and in the GitHub workflows when Sondely moves to the TourCockpit stack. Every Azure change goes through Terraform in catalyzeup-devops/azure/, read with terraform plan before apply. The data move these pieces serve is on the Cutover Runbook; the plan is on the overview.

Sources: catalyzeup-devops/azure/main.tf, outputs.tf, providers.tf and modules/container-app/; sondely/Dockerfile and .github/workflows/; TourCockpit's Dockerfile, docker-entrypoint.sh, src/lib/db.ts, .github/workflows/ci.yml, deploy-dev.yml, deploy.yml; the IdeaPlaces precedent in ideaplaces-devops/infrastructure/terraform/azure/environments/shared/ (main.tf, tour-platform.tf, outbox.tf). Live values were read from Azure and GitHub, read-only, on 5 November 2026. What was built on 7 and 8 November 2026 was read from catalyzeup-devops/azure/sondely-platform.tf and from the CatalyzeUp/sondely-platform repository (Dockerfile, docker-entrypoint.sh, .github/workflows/).

Today: the Python app

The container app names keep impactpulse on purpose (comment in main.tf); renaming them would mean re-binding four custom domains and their certificates, so the migration keeps the names.

As built on 7 and 8 November 2026

The new app is not a new image for the Python container apps, as the first version of this page planned. It runs in two container apps of its own, beside impactpulse and impactpulse-prod, on temporary hosts until the cutover moves sondely.com. All of it is in catalyzeup-devops/azure/sondely-platform.tf.

As of 8 November 2026 the dev app runs develop and the production app runs main: platform.sondely.com/health names commit a003202 with database: ok.

Postgres: decided

Decision 1 on the overview, taken on 7 November 2026: A, new CatalyzeUp servers, built as listed above. The comparison that decided it:

Terraform in catalyzeup-devops

The database and its secrets

Roles

The same three connections TourCockpit uses, built into each app's secrets:

The app role is a database object, not an Azure resource: Terraform owns only its password, and the role is created once per server by hand with that password. In CI and locally it is created by scripts/db/init-role.sql. Every migration that adds a table grants it to sondely_app.

Container app settings

Set by Terraform on both apps (sondely_common_env, sondely_common_secrets and the database URLs):

GIT_COMMIT_SHA is set by the deploy workflow, not by Terraform, so /health can name the commit. WRITE_FREEZE is not set on either app and nothing in the new app reads it yet; the freeze the runbook needs is still to build.

Sona's voice

Sona's call runs on Azure AI Voice Live through the CatalyzeUp Speech resource speech-catalyzeup-sondely in Canada Central (kind = SpeechServices, S0). Voice Live is limited and billed on the Speech resource. The other path, a gpt-realtime-2.1 deployment on Azure OpenAI, needs GlobalStandard quota, which is counted per subscription across every region; on 7 November 2026 it was at 10 of 10, all used by TourCockpit's Faro (openai-tourcockpit-voice). This is the same path Faro's native-voice calls take.

A Canada Central Azure OpenAI account, openai-catalyzeup-voice, exists with a gpt-4o-mini-transcribe deployment, for transcription. Its realtime and voice note deployments, and the settings that would point the app at that account, are behind sondely_voice_quota_available = false in Terraform and are not created; the app does not use the account today. During a call, what the caller says is transcribed by Voice Live itself.

The reminder job

The app serves POST /api/v1/jobs/reminders, guarded by JOBS_SECRET, and claims each reminder before sending it. A scheduled Container Apps job, azurerm_container_app_job.sondely_reminders in azure/sondely-platform.tf, calls it every 15 minutes with a curl container: sondely-reminders-dev against platform-dev.sondely.com runs today. The production job is created only when local.sondely_prod_reminders_enabled is true; it is false until the cutover, because the Python app still sends its own reminders to the same people and both together would send twice (Switchover checklist, step 5).

Not built yet

• Health probes. modules/container-app defines none, and the Sondely apps set none. The plan stands: optional readiness_probe and liveness_probe variables on the module, readiness on /health, so a revision that cannot reach Postgres never takes traffic.
• Geo detection in the deployed apps. The app reads a MaxMind GeoLite2 database from GEOIP_DB_PATH, then falls back to Cloudflare's CF-IPCountry header. The image carries no GeoLite2 database, GEOIP_DB_PATH is not set, and the platform hosts are DNS only, so Cloudflare adds no header: a response's country is unknown on both apps today. The Python image fetches the database at build time with the maxmind_key secret.
• Session affinity for calls, which is what lets production run more than one replica.

After the rollback window

Listed in the runbook, Decommissioning Cosmos and Redis: remove module.impactpulse and module.impactpulse_prod or their Mongo and Redis variables, remove azurerm_redis_cache.main, archive both databases, remove azurerm_cosmosdb_account.main and the cosmosdb_connection_string and redis_hostname outputs.

The Docker image

As built: the Dockerfile at the root of sondely-platform, copied and stripped from TourCockpit's. It serves the Next.js app only; there is no Vite stage, because every screen is in Next.js (Frontend Screens).

Because the entrypoint migrates while the previous revision is still serving (single revision mode starts the new one before the old one stops), every migration must be backward compatible with the running code: add, backfill, then remove in a later release. TourCockpit's Session.activeCompanyId comment in prisma/schema.prisma is the worked example.

CI/CD

The Python app today

These keep deploying the Python app from CatalyzeUp/sondely until the cutover and the rollback window are over.

The new app, as built

There is no migration step in the workflows: the container migrates itself at start, as TourCockpit does, which keeps the database firewall closed to CI runners. There is no runtime switch variable either, because the new app does not replace the Python image in the same container app.

Runners

Decision 4 on the overview, taken on 7 November 2026: GitHub-hosted runners (ubuntu-latest) for CI and deploy. The Nous pool is not registered for the CatalyzeUp organization. The options weighed:

What must reach Azure Postgres (the migration script, its verifier) runs from an Azure address, which the firewall admits; no CI job needs it.

Discord

Neither workflow of the new app notifies Discord yet. The target stays: Ideaplaces/discord-ci-status@v1 (public, usable from the CatalyzeUp organization) posts on failure and deletes the post when the job goes green, never posts on success. It needs a webhook and DISCORD_BOT_TOKEN as repository secrets. CatalyzeUp's channels and webhooks are created by catalyzeup-devops/discord/setup-cicd-notifications.sh and stored in kv-catalyzeup.

Health checks

There is no /api/health or /api/version: /health carries the commit.

Environments

Branches follow the workspace rule: feature branches from develop, pull requests to develop, production from main only. When sondely.com moves is Chip's call (Runbook). Organization custom domains (today hit.wehappers.org) are bound by hand, as today, and resolved by the app's organization-by-host lookup.

Cost

Azure first-party spend is paid from sponsorship credits until 28 July 2027, and Sondely runs in that same subscription (the account shows only "Microsoft Azure Sponsorship", and rg-catalyzeup is in it). So the migration's Azure cost is credits until then.

After July 2027 the Postgres servers are the recurring item. GitHub-hosted runner minutes are not Azure spend and are not covered by the credits; that was accepted with the runner decision.