Environment variables

Your container gets its environment from three places, applied in this order:

The image. Whatever the Dockerfile's ENV lines set.
Platform variables. What bootload knows about the running service — its identity and the domains it answers on. Listed below.
Your secrets. Project-wide and service-scoped values you set with bootload secret set.

Later wins. A secret named BOOTLOAD_URL overrides the platform's, and a secret always overrides the image. Nothing bootload injects can shadow a value you set yourself.

What the platform injects

Every container gets these, with no configuration:

Variable	What it holds
`BOOTLOAD_SERVICE`	the service name, e.g. `web`
`BOOTLOAD_PROJECT`	the project name, e.g. `production`
`BOOTLOAD_IMAGE`	the image reference this replica booted from
`BOOTLOAD_DEPLOYMENT`	the deployment id, useful as a release tag for error reporting
`BOOTLOAD_REPLICA`	this replica's id, so log lines can say which one spoke

A service with at least one HTTP route also gets:

Variable	What it holds
`BOOTLOAD_FQDN`	the primary domain, e.g. `shop.example.com`
`BOOTLOAD_URL`	the primary domain as a URL, e.g. `https://shop.example.com`
`BOOTLOAD_FQDNS`	every domain the service answers on, comma-separated
`BOOTLOAD_PORT`	the container port the platform routes to

BOOTLOAD_PORT is deliberately not called PORT: many images set their own PORT and bootload will not overwrite it.

A service with no route, such as an internal-only database, gets the identity variables and none of the URL ones. They are absent rather than empty, so a missing value fails loudly instead of building a link to https://.

Several domains

BOOTLOAD_FQDNS is the whole set:

BOOTLOAD_FQDN=shop.example.com
BOOTLOAD_FQDNS=shop.example.com,shop.example.be,www.shop.example.com
BOOTLOAD_URL=https://shop.example.com

Use it at startup for configuration that needs the list up front: allowed hosts, CORS origins, a cookie domain, a framework's canonical URL setting.

For deciding what to serve per request, read the Host header instead. That is the domain the visitor actually typed, and it is the only thing that distinguishes two domains pointing at the same service. bootload passes it through unchanged from the edge to your container.

app.use((req, res, next) => {
  req.tenant = req.headers.host;   // shop.example.be
  next();
});

When the values change

They are rendered when a replica starts. Attaching or removing a domain does not restart your app, deliberately, so the new value appears on the next restart:

bootload domain attach shop.example.be web
bootload restart web                        # picks up the new BOOTLOAD_FQDNS

Everything else about the domain works immediately. Only the variables wait.

Seeing them

bootload status web            # lists the platform variables for the service

The service page in the portal shows the same list, read-only, under the service's environment.

Your own values

bootload secret set DATABASE_URL            # project-wide
bootload secret set API_KEY --service api   # one service only

Secrets are injected as environment variables and as files under /run/secrets/, on tmpfs, never written to the image or the disk. A service-scoped value shadows a project-scoped one with the same name. See getting started for the full secrets story.