Three hardcoded container passwords moved to Cloudflare Worker secrets. The externalization works. The container still doesn't start — but for unrelated reasons that predate this session.
The radio-station directory was committed during the drift cleanup earlier in the day. It contained three hardcoded passwords in icecast.xml and liquidsoap.liq used for internal container-to-container auth between Liquidsoap (the audio engine) and Icecast (the streaming server). The repo had just gone private, but hardcoded credentials in any repo is bad hygiene regardless of visibility.
The config files got renamed to .tmpl versions with ${ICECAST_SOURCE_PASSWORD}, ${ICECAST_RELAY_PASSWORD}, and ${ICECAST_ADMIN_PASSWORD} placeholders. An entrypoint.sh script runs envsubst at container start to generate the real config files from the templates, then hands off to supervisord. Three new random passwords got generated via openssl rand -base64 24, stored in a password manager, and set on Cloudflare via wrangler secret put — keeping the password values entirely out of the AI context.
The Durable Object side needed a getter pattern, not a class field. import { env } from "cloudflare:workers" at module scope works for simple bindings but does not populate Worker secrets at class-field initialization time. Using get envVars() that reads from this.env defers the lookup until after the DO constructor has populated the binding. This is the part of the docs that needs a worked example.
The container deployed and then failed to start. The SDK reported only "The container is not running, consider calling start()" — a symptom, not a cause. wrangler tail captures Worker runtime events but not container stdout. There is no wrangler containers logs subcommand yet. This is a real beta-product limitation; when your container fails to start on Cloudflare, you cannot see why from Cloudflare's tooling.
The fix was pivoting to local Docker. docker build the image, docker run with dummy env vars, watch stdout fill the terminal. Two bugs surfaced immediately.
The first: Debian bookworm's icecast2 refuses to run as root and requires a <changeowner> block in the <security> section of icecast.xml. The container runs as root because the Dockerfile has no USER directive. Icecast exits on every attempt, supervisord retries three times, marks FATAL.
The second: the installed Liquidsoap on Debian bookworm is 2.1.3. The .liq template uses 2.2.x tuple-destructuring syntax at lines 37 and 42 — (_, t) = entry, (u, _) = entry. That syntax is not valid in 2.1.3. Liquidsoap exits with a parse error on every attempt.
Neither bug is caused by the externalization work. Both predate it. The radio-station code was scaffolded by an earlier Claude Code session and was never end-to-end verified — the externalization is the first time anyone actually tried to run the container. It was always going to fail.
The externalization is correct, verified locally, and shipped. entrypoint.sh runs all steps, substitutes both templates cleanly, hands off to supervisord. The password externalization did exactly what it was designed to do.
The radio-station container itself goes on the queue for a v2 rebuild in a dedicated session. The current radio-station/ stays on disk as reference. v2 will start with the smallest possible working config — one track on loop from R2 to one Icecast mount — verified locally before a single line of Human Rhythm Engine logic gets added on top. The two bugs above become explicit acceptance criteria for v2, not discovered failures.
Two things worth preserving for the record. First: wrangler tail is Workers-only — no container stdout — so local docker run is the debugging surface for anything that crashes inside a Cloudflare Container. Second: AI-scaffolded infrastructure that was never run end-to-end often has non-trivial pre-existing bugs. The externalization surfaced bugs the scaffold had always carried. Better to find them now than after launch.