Turns the console on from the environment, for deployments that run a release rather than write a sys.config.

Why this is Erlang and not sys.config.src

relx substitutes ${VAR} into sys.config before the VM starts, which is fine for a value that is always set and fatal for one that is not: an unset ${ASOBI_CONSOLE} renders {console, } and the node will not boot. The existing keys get away with it only because the image declares ENV defaults for every one of them, and asobi itself ships no image.

Reading the environment here instead means a missing variable is simply a missing variable, the keys stay optional, and a self-hoster who does write a sys.config is unaffected - an OS variable overrides it only when set.

Precedence

ASOBI_OPS_SECRET_FILE beats ASOBI_OPS_SECRET. Reading a secret from a file keeps it out of docker inspect, out of the process environment, and out of a compose file that tends to end up in git, which is why Docker and Kubernetes both hand secrets over as files.

The database password cannot work this way - it is substituted into sys.config before any of this runs - so ASOBI_DB_PASSWORD_FILE is not a thing, whatever the deployment guide used to imply.

Enabled with nothing to sign in with

The console stays off and says so at error level. It does not stop the node: the game is the product and the console is an accessory, so taking players offline because an operator surface is misconfigured is the wrong trade. A console that renders a sign-in nothing can pass is the worse failure, because it looks like it works.

ops_secret is not the only credential that counts. A managed environment configures none on purpose - the only thing its console accepts is a token console.asobi.dev minted for someone it authenticated, verified against ops_token_secret and env_id (asobi_ops_token). Either credential being configured is enough; neither is what turns the console off.