Set by name, never committed

A production deploy needs a set of environment values, and not all of them are alike. Most are plain configuration that carries no risk if read: the Portal’s public host, the listen port, the env name, the pool size, the IPv6 networking substrate. These live in echo/fly.toml under the [env] stanza, are committed to the repository in the open, and ship inside the image — there is nothing to protect, so there is no reason to hide them.

The non-secret [env] keys, as built: PHX_HOST = "echo-portal.fly.dev" (the Portal’s own host, read in runtime.exs under :prod — distinct from :deep_link_base_url, which stays https://jonnify.fly.dev), PHX_SERVER = "true", MIX_ENV = "prod", PORT = "4000", POOL_SIZE = "10", the IPv6/cluster trio ERL_INETRC = "/app/inetrc" / ECTO_IPV6 = "true" / ERL_AFLAGS = "-proto_dist inet6_tcp", and TZ = "UTC" / LANG = "en_US.UTF-8". None of these is a secret.

The two secrets sit on the other side of the line. SECRET_KEY_BASE signs and encrypts the endpoint’s tokens and cookies; DATABASE_URL carries the database credentials Portal.Repo connects with. Both are sensitive, so neither belongs in a committed file — not fly.toml, not a config, not a comment. Select a value below to read which store owns it, whether it is a secret, and how a deploy provisions it.

Because SECRET_KEY_BASE and DATABASE_URL stay out of every committed file, a deploy has to hand them to Fly some other way — by name, with fly secrets set. This is bring-up step 0, run once against the app before the first fly deploy: fly secrets set SECRET_KEY_BASE=… DATABASE_URL=… -a echo-portal. Fly stores the values in its own encrypted secret store, injects them into the machine’s environment at boot, and never writes them back to the repository. To confirm the names are present without revealing any value, fly secrets list -a echo-portal prints the names (and a digest), not the contents.

Two names keep recurring — the OTP release and the Fly app — and conflating them is the common slip. The OTP release is portal (you run it as bin/portal); the Fly app is echo-portal (the -a echo-portal flag every fly secrets and fly deploy command targets). They are independent identifiers that happen to live in the same deploy.

So where do the secret values come from when the Operator runs fly secrets set? From a local file the Operator keeps and the repository never sees: echo/.env.production. It holds SECRET_KEY_BASE and DATABASE_URL by name, the Operator feeds those values to fly secrets, and the values are never written into any committed file — not a spec, not a config, not a comment (F7.4-INV1). The committed artifact carries the secret names and nothing more.

Setting a secret by name only matters because runtime.exs reads it by name — and the two sides have to agree. Each secret name a deploy provides must equal a name the boot config reads, or the boot fails. That agreement is not enforced by hope: config/runtime.exs contains three explicit raises under :prod, one per required value, so a missing value fails the boot loudly instead of booting with an insecure default.

The three raises, with their exact messages. A missing SECRET_KEY_BASE emits environment variable SECRET_KEY_BASE is missing; a missing PHX_HOST emits environment variable PHX_HOST is missing; a missing DATABASE_URL emits environment variable DATABASE_URL is missing. Worth keeping straight: PHX_HOST is a non-secret [env] key that also raises when absent — the raise enforces presence, regardless of whether the value is secret. Secrecy decides which store a value lives in; the raise decides that it must be there at all.

Run the contract below: pick a required prod value and a state. With the value set, its name matches a runtime.exs read and the boot proceeds; with it missing, runtime.exs raises the exact string and the boot fails before it can serve a request.