Environment variables

The engine reads almost nothing from the environment on its own. Configuration reaches it through the ${VAR} interpolations in your configuration files, so the variable names are whatever your engine.yaml says. A new project’s files, the examples and this handbook use the conventional names below; keep them unless you have a reason not to.

Read directly by the engineCopy Anchor Link

Nothing else changes the engine’s behaviour unless your configuration names it. The engine does not read .env files.

Conventional names in engine.yamlCopy Anchor Link

These are the names engine-dmo init writes into a new project’s config/engine.yaml, and the ones the deployment pages use. Each is only read because the file interpolates it.

Names the deployment pages and examples add:

Setting them in developmentCopy Anchor Link

Once a file names a variable with no default, every command that loads the configuration needs it set, on your laptop as much as in production. Which commands load what is in Commands and the environment. For local work without a database, and once engine.yaml names ${SIGNING_KEY} for production:

export DATABASE_URL=postgres://localhost/placeholder   # any address; check --no-db and describe never connect
export SIGNING_KEY=""                                  # empty is a derived development key; or 32 or more random characters

SIGNING_KEY set to 1 to 31 characters is refused everywhere (signing_key must be at least 32 characters). With a real development database, set DATABASE_URL to it. The engine does not read .env files: export the variables in your shell, or load a file yourself (set -a; . ./.env; set +a).

Only string-typed settings can be interpolated; a boolean or number setting cannot come from a variable. Configuration and secrets explains ${VAR}, ${VAR:-default} and the secret rule.

Variables commands read secrets fromCopy Anchor Link

Some commands take a secret from a variable you name, so it never appears on the command line or in shell history:

Variables the engine sets for child processesCopy Anchor Link

Set MERIDIAN_ENGINE yourself in a container build stage that runs the Vite build, so the plugin uses the engine binary you copied in rather than looking for one (see Container images).

A plugin process receives only PATH, HOME, TMPDIR, USER, LANG, LC_ALL, SSL_CERT_FILE and SSL_CERT_DIR from the engine’s environment, plus what its env declares and TZ=UTC. It never sees the database URL or a key it was not given.