Skip to content

fix(deploy): map DATABASE_URL_APP into the base compose api service#2526

Merged
ToddHebebrand merged 2 commits into
mainfrom
fix/base-compose-database-url-app
Jul 15, 2026
Merged

fix(deploy): map DATABASE_URL_APP into the base compose api service#2526
ToddHebebrand merged 2 commits into
mainfrom
fix/base-compose-database-url-app

Conversation

@ToddHebebrand

Copy link
Copy Markdown
Collaborator

Problem

v0.95.0 makes DATABASE_URL_APP the preferred way to point the request pool at the unprivileged breeze_app role, and the only option for multi-host/HA URLs — requestDatabaseConfig.ts throws rather than derive one:

Cannot derive the request database URL from DATABASE_URL. Set an explicit DATABASE_URL_APP for postgres.js multi-host/HA URLs.

The base docker-compose.yml never mapped it into the api service environment: block. Compose only interpolates vars listed there, so a self-hoster setting DATABASE_URL_APP in .env had it silently dropped.

This is the same failure mode #2522 fixed for deploy/docker-compose.prod.yml — which already carries a comment spelling out why all three must be mapped, while the base file it mirrors omitted one of them.

Fix

Map DATABASE_URL_APP: ${DATABASE_URL_APP:-} alongside the existing POSTGRES_PASSWORD / BREEZE_APP_DB_PASSWORD.

Verification

docker compose config against an env file, base compose:

DATABASE_URL_APP occurrences in rendered api
main today 0 — silently dropped
with this fix 1 — value intact, incl. comma-separated HA hosts
fix + var unset renders "", config still valid (rc=0)

Confirmed via awk that the var lands in the api service specifically.

Why now

Blocks cutting v0.95.0 — this is the release that introduces the variable, so shipping it inert on the default compose file would strand base-compose HA users on the exact footgun the release is meant to close.

🤖 Generated with Claude Code

v0.95.0 makes DATABASE_URL_APP the preferred way to point the request
pool at the unprivileged app role, and the only option for multi-host/HA
URLs (requestDatabaseConfig throws rather than derive one). The base
compose file never mapped it, so a value set in .env was silently
dropped — the same failure mode #2522 fixed for deploy/docker-compose.prod.yml,
which already carries a comment explaining why all three must be mapped.

Verified with `docker compose config`: before, a DATABASE_URL_APP set in
the env file produced 0 occurrences in the rendered api service; after, the
value reaches the api service intact, including comma-separated HA hosts.
Unset still renders as "" and leaves the config valid.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@cloudflare-workers-and-pages

cloudflare-workers-and-pages Bot commented Jul 15, 2026

Copy link
Copy Markdown

Deploying breeze with  Cloudflare Pages  Cloudflare Pages

Latest commit: 1c98c11
Status: ✅  Deploy successful!
Preview URL: https://c810ff35.breeze-9te.pages.dev
Branch Preview URL: https://fix-base-compose-database-ur.breeze-9te.pages.dev

View logs

requestDatabaseCompose.test.ts asserted DATABASE_URL_APP was ABSENT from
the base compose api env — the shape this PR deliberately changes. Update it
to the new contract: the var is now mapped as an empty string when unset, and
the resolver still derives (resolveRequestDatabaseConfig trims + truthiness-
checks, so blank == not set — verified the empty mapping does not shadow
derivation). Adds a case proving an explicitly-set DATABASE_URL_APP flows
through to the api service, which is the capability the mapping restores.

Runs green locally on Node 22.20.0 (3/3).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@ToddHebebrand
ToddHebebrand merged commit dda946b into main Jul 15, 2026
41 checks passed
@ToddHebebrand
ToddHebebrand deleted the fix/base-compose-database-url-app branch July 15, 2026 18:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant