The runtime-vs-compile split

A Mix release runs config/runtime.exs once when the node starts, inside the container that will serve traffic. Everything that file reads — System.get_env(...), the chosen bind_ip, the assembled endpoint config — is resolved against the live deploy. By contrast, config/prod.exs is read while the image is being built, so its values are baked into the artifact and cannot change between one boot and the next. The same configuration system spans both moments; which file a value lives in decides when it is decided.

The whole boot block in runtime.exs is wrapped in if config_env() != :test do. Under the test environment the file returns before that block, so the suite neither binds a port nor demands a real secret — the runtime reads belong to a real deploy, not to a unit run. One detail inside the guard matters: config_env/0 is a macro and cannot be called from inside a guard expression, so it is bound to a plain variable first — env = config_env() — and every later case branches on env, not on a fresh macro call.

Use the inspector below to select a configuration value and read which layer owns it, what it reads at boot or bakes at build, and how it differs between prod and dev.

Inside the guard, runtime.exs reads four values from the environment. SECRET_KEY_BASE goes through a case {System.get_env("SECRET_KEY_BASE"), env} that raises on {nil, :prod} — with mix phx.gen.secret guidance — falls back to a fixed 64-byte string (String.duplicate("0", 64)) outside :prod so a local mix phx.server needs no env set, and uses the supplied value otherwise. No insecure default ever leaks to prod, because the only fallback is gated behind “not prod”.

PORT is String.to_integer(System.get_env("PORT", "4000")) — defaulted to 4000, and the fly.toml [env] block sets PORT = "4000". bind_ip is {0, 0, 0, 0} under :prod, so the Fly edge proxy can reach the endpoint on every interface, and {127, 0, 0, 1} under dev, so a local boot stays on loopback and is not exposed. PHX_HOST is read only under :prod into config :portal_web, PortalWeb.Endpoint, url: [host: host]; a missing value raises, joining the SECRET_KEY_BASE and DATABASE_URL raises.

A point worth keeping straight: PHX_HOST is the Portal’s own public host — echo-portal.fly.dev — not :deep_link_base_url, the strangler-fig fallback origin that stays https://jonnify.fly.dev. Two hosts, two keys: one names where the Portal serves, the other where unmigrated links still point.

On the other side of the split, config/prod.exs bakes the values that never vary per deploy. The endpoint carries a fixed url: [host: "echo-portal.fly.dev", port: 443, scheme: "https"] shape and cache_static_manifest: "priv/static/cache_manifest.json". The port: 443, scheme: "https" shape is build-time because it never changes between deploys; the host is supplied at boot by PHX_HOST and merges over this compile-time placeholder under :prod. prod.exs also picks the event-store adapter — config :portal, :event_store, Portal.EventStore.Postgres — flipping the config.exs Portal.EventStore.InMemory default. The adapter is a build decision: which store the release ships with is fixed when the image is assembled.

The server? gate is the value that looks compile-time but must not be. server? is true only when PHX_SERVER in ~w(true 1) under :prod, else true in dev, and it feeds config :portal_web, PortalWeb.Endpoint, http: [ip: bind_ip, port: port], server: server?. It is read at boot for a precise reason: a release runs maintenance tasks with bin/portal eval (a migration, say) with PHX_SERVER unset, and that eval must not bind a port. If the gate were a compile-time System.get_env("PHX_SERVER"), the build host’s env would be frozen into the image, and the eval could come up with a listener it should never start.

The simulator below runs the gate as runtime.exs would: choose MIX_ENV and whether PHX_SERVER is set, and read whether the boot block runs, what server? evaluates to, whether the HTTP listener binds a port, and what bind_ip resolves to.