fix: build compose images without host networking

[satriadhikara]

Description

Remove build.network: host from the 9 services in docker-compose.yml that build from source. No Dockerfile needs host networking, and current Buildx refuses it under Compose's default build path. This makes the ui and docker-integration (test_integration_expire.sh) CI jobs fail on every PR, and breaks docker compose build locally for anyone on Buildx >= 0.37.2.

Failure

Both CI jobs stop right after #1 [internal] load local bake definitions with:

additional privileges requested: pass "--allow=network.host" to grant requested privileges

Example: run 38134879446 on #117 (runner image ubuntu-24.04 20261004.327.1). The same jobs passed on #114's run 37577263223 (image 20260927.320.1).

Root cause

Bake treats build.network: host as a privileged entitlement that has to be granted with --allow=network.host. Compose builds through buildx bake --progress rawjson and only passes --allow for fs.read and security.insecure, never network.host. This is still true on Compose main (v5.6.0). So any docker compose build that touches a service with network: host now fails.

Why it only started failing now

The config has needed this entitlement since mid-2025. A Buildx bug hid the error until the latest runner image fixed it:

When	Change	Effect
Jan 2024	network: host added to the build sections (97e179a, 1.4.0 release)	Compose used its classic builder, which needs no entitlement. Builds pass.
Jun 2025	Compose 2.37.0 makes bake the default builder	network: host now needs --allow=network.host, which Compose never passes. Builds should fail but don't, because of the next row.
until Sep 2026	Buildx < 0.37.2 skips the entitlement consent check under --progress=rawjson	Ungranted entitlements go through silently. This is the bug fixed as GHSA-gwr2-q96m-6682.
Sep 30 2026	Buildx 0.37.2 released: bake with --progress=rawjson rejects ungranted entitlements	The latent misconfiguration becomes a hard error.
Oct 2026	GitHub runner image ubuntu-24.04 20261004.327.1 ships Buildx 0.37.2. Compose is unchanged at 2.38.2.	#114 (Oct 7, old image, Buildx 0.37.1) passes. #117 (Oct 11, new image) fails.

The same failure will reach local builds once Docker Desktop or OrbStack bundles Buildx >= 0.37.2.

Why remove it rather than work around it

• No build step uses the host network. None of the 9 Dockerfiles reference localhost, 127.0.0.1, host.docker.internal, a proxy or a private registry. They only fetch packages (Maven, pip/pipenv, apk, bun), which works on the default build network.
• .docker/docker-compose.yml (the release/install compose) never set it.
• It was added in bulk in the 1.4.0 release commit (97e179a, Jan 2024) with no recorded reason.
• Setting COMPOSE_BAKE=false in CI would also unblock CI. But it leaves local builds broken, and Compose v5 ignores it (it still went through bake when tested locally), so it would break again on the next runner image.

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Refactoring (no functional changes, no API changes)
• Dependency update

Related Issue

Closes # (issue number)

Checklist

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing tests passed.

Additional Notes

Local verification (OrbStack, CI's exact toolchain)

I ran Compose 2.38.2 and Buildx 0.37.2 (docker/compose-bin:v2.38.2, docker/buildx-bin:0.37.2) in a container against the local daemon:

• origin/main: docker compose build dbrepo-ui fails with the same --allow=network.host error as CI.
• This branch: docker compose build dbrepo-ui succeeds.
• This branch: full docker compose build, as in publish-ghcr-images, builds all 9 images after the CI prep scripts. A separate --no-cache build with host Compose v5.1.2 also built all 9.
• ui job smoke test: the dbrepo-ui container ran and test_heap.sh completed, with 0 failed requests in 4×1000.
• test_integration_expire.sh: all 5 tests pass.
• Full stack up: these services came up healthy: auth, broker, cache-db, metadata-db, data-db, auth-db, dashboard-db, dashboard-ui, search-db, identity, storage, search-service, dashboard-service, ui, and metadata-service. storage-service-init, search-service-init and dashboard-service-init exited 0.

Pre-existing issue found during e2e (not caused by this PR)

dbrepo-data-service and dbrepo-consumer-service built from current main crash at startup:

LoggerFactory is not a Logback LoggerContext but Logback is on the classpath ... NOPLoggerFactory loaded from ... bundle-2.23.19.jar

With Spring logging disabled, data-service then fails with NoSuchFieldError: ... AwsClientOption CREDENTIALS_IDENTITY_PROVIDER. That points to an AWS SDK version mix on the classpath. A data-service image built from the same context with --network host crashes identically, so this is independent of build networking. The gateway then fails on the missing data-service upstream. I will raise it separately.

Limits

• If someone builds behind a network where the default build network can't reach the package registries (VPN or DNS setups), they would need network: host back. They can set it in a local docker-compose.override.yml. Please flag if a known setup relies on it.