Flip apps (including website/) to using managed postgres database

[Will-Howard]

Description

We have a new managed postgres database provisioned (#2572) and synced to Airtable (#2624). This PR flips all consumers to using the new database. I am doing all at once to reduce the risk of data inconsistencies due to different apps reading from different databases.

Because both postgres instances are synced via pg-sync-service, this should be a zero downtime change.

Issue

#2580

Developer checklist

• Front-end code follows Component Accessibility Checklist (for Testing)
• Considered having snapshot tests and/or happy path functional tests
• Considered adding Storybook stories

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 36920cd3-0b96-41d9-bc6c-1eee92c1f117

📥 Commits

Reviewing files that changed from the base of the PR and between 423e428 and a00aac8.

📒 Files selected for processing (1)

• apps/infra/src/k8s/serviceDefinitions.ts

---

📝 Walkthrough

Walkthrough

This PR updates nine Kubernetes service definitions to use a managed Postgres connection string for their database configuration. The affected services—bluedot-app-template, bluedot-frontend-example, bluedot-website, bluedot-website-production, bluedot-editor, bluedot-meet, bluedot-availability, bluedot-course-demos, and bluedot-speed-review—now reference appPgConnectionDetails.uri for their PG_URL environment variable instead of the in-cluster airtableSyncPg connection. Other services such as bluedot-pg-sync-service retain their existing in-cluster configuration.

Possibly related PRs

• bluedotimpact/bluedot#1018: Introduces the airtableSyncPg connection pattern that this PR migrates away from; both PRs modify the PG_URL wiring strategy across services in serviceDefinitions.ts.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely summarises the main change: migrating multiple applications to use the managed Postgres database instead of the in-cluster instance.
Description check	✅ Passed	The description covers all essential sections: rationale for the change, related issue reference, and developer checklist completion.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch wh-2580-website-managed-pg-2026-06

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[greptile-apps]

Greptile Summary

This PR migrates 9 production services from the in-cluster CloudNativePG instance (airtableSyncPg) to the new managed Vultr Postgres instance (appPg) by swapping each service's PG_URL source from getConnectionDetails(airtableSyncPg).uri to appPgConnectionDetails.uri. The shadow pg-sync-service (already running) keeps appPg in sync with Airtable, ensuring no data gap during the cutover.

• All app services (website, editor, meet, availability, course-demos, speed-review, app-template, frontend-example) are consistently updated to the new managed database connection.
• The primary pg-sync-service and Keycloak remain on their existing databases, which is the correct transitional state — the follow-up step is to flip the primary sync service and then remove the shadow instance.

Confidence Score: 5/5

Safe to merge — the change is a uniform config swap across all app services, the shadow sync service already keeps the target database populated, and no service logic is affected.

All 9 affected services receive the same straightforward substitution. The managed database was already being kept in sync by the shadow pg-sync instance, so no data gap can occur. The primary pg-sync and Keycloak are correctly left untouched as part of the documented two-step migration. No logic errors or missing cases were found.

No files require special attention.

Important Files Changed

Filename	Overview
apps/infra/src/k8s/serviceDefinitions.ts	Switches PG_URL for 9 app services from the in-cluster airtableSyncPg to the managed appPgConnectionDetails.uri; primary pg-sync and Keycloak remain unchanged as expected during this transitional step.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    AT[Airtable]

    subgraph "Before PR"
        PGS1[pg-sync-service]
        OLD_DB[(airtableSyncPg\nin-cluster)]
        APPS1[All app services\nwebsite, editor, meet, etc.]
        AT --> PGS1 --> OLD_DB --> APPS1
    end

    subgraph "After PR"
        PGS2[pg-sync-service\nprimary]
        PGS_SHADOW[pg-sync-shadow]
        OLD_DB2[(airtableSyncPg\nin-cluster)]
        NEW_DB[(appPg\nmanaged Vultr)]
        APPS2[All app services\nwebsite, editor, meet, etc.]
        KC[Keycloak]
        KC_DB[(keycloakPg)]

        AT --> PGS2 --> OLD_DB2
        AT --> PGS_SHADOW --> NEW_DB --> APPS2
        KC --> KC_DB
    end

Loading

_{Reviews (1): Last reviewed commit: "Swap apps to managed postgres" | Re-trigger Greptile}