Environment variables. Set configuration and secrets for an app without committing them.

hub app my-app env                                   # the names, never the values
hub app my-app env set API_URL=https://api.example.com MODE=production
hub app my-app env set API_KEY                       # asks for the value, without echo
hub app my-app env set --file .env                   # every pair in a dotenv file
hub app my-app env unset MODE

Variables belong to one instance: my-app/staging has its own. Names use A to Z, 0 to 9 and _, and don't start with a digit. PORT and names starting with HUB_ are reserved.

Hub stores values encrypted and never prints them, in the CLI or on the dashboard.

What a change does

A change to an app that is running makes a new release and restarts the app once, however many variables it touched. The CLI waits and prints Restarted with the new environment. An app with no release yet keeps the values for its first deploy.

Build-time variables

A frontend reads some values when it builds, such as VITE_API_URL. Mark those with --build:

hub app my-app env set --build VITE_API_URL=https://api.example.com

A change to a build variable builds the app again. Build variables reach the build as build arguments: the Dockerfiles Hub writes declare them, and a Dockerfile of your own declares the ARGs it wants. Build arguments stay visible in the image history on your host, so keep secrets in runtime variables.

Dotenv files

--file reads blank lines, # comments, export NAME=value and quoted values. A pair on the command line wins over the same name in the file. A line Hub cannot read fails the whole change and names its line number, never its text. The dashboard takes the same files through its import form.

Compose files

${NAME} in a compose file reads these variables, and only these: Hub ignores the .env in your folder. Services Hub builds also get every variable in their environment. A service that runs a ready image gets only what the compose file passes it.