Environment variables

Each application and compose stack keeps an environment of its own: plain text, one NAME=value per line, set on the service's Environment section. It is where configuration and secrets go.

NODE_ENV=production
LOG_LEVEL=info
DATABASE_URL=postgresql://app:<password>@<engine name>:5432/app

Values stay hidden until you edit them: the section lists each name with its value written as dots, so a screen you share shares no secret. Press Edit to see and change the real text, then Save, or Cancel to drop your changes.

The rules:

• One variable per line, up to 64 KB in all. A larger environment is refused with "The environment is text, one name=value on each line, at most 64 KB."

• Lines are kept exactly as you write them, leading spaces included.

• The environment belongs to one service. Cloud returns it to you on that service's own page and nowhere else, and Cahaves operators who open a support session on your account see your services without it.

• While a service is suspended its environment is read only.

A restart does not rebuild. A value that the build bakes into its output, such as a variable a frontend framework inlines into its bundle while it builds, keeps its old value in the running service until the next deployment builds it again. After changing one, press Deploy.

A nixpacks build runs with the service's environment: that is how it reads the NIXPACKS_* commands described below.

A database is configured on its Overview section: name, user, password, version and port. The console still shows an Environment section on a database, and Save there reports success, but nothing you save is stored. Databases covers what a database takes.

A database's Connection card shows its Internal address: a full connection address with the user, the password, the host and the port filled in, and a copy button beside it. Copy it into the application's environment under the name your code reads, such as DATABASE_URL.

If you later change the database's password, applications that connect with the old one stop connecting until their environment carries the new one. Update and save their environment after the change.

For a service built from GitHub, Cloud looks in the repository for a template of the environment it needs. It checks the build path first, then the repository's root, and in each uses the first of these it finds:

While the service's environment is empty, the Environment section opens in editing mode, filled in from the template, with the line "Filled in from" and the template's path, then "Nothing is saved until you save it." Check the values, replace the examples with real ones, and press Save.

• Each variable the template sets is copied with the value the template gives it.

• A variable commented out in the template, such as # SENTRY_DSN=, counts as optional and is left out.

• A value in quotes is copied without them.

Cloud reads templates only. It never reads a .env file from your repository.

Some variables reach a service without appearing in the text you edit:

Cloud adds these each time it hands the environment to the service, so an address value follows the domain when you add, rename or remove one. A name you set yourself always wins: if your text already carries the name, Cloud leaves its own value out.

Two more kinds are written into your text when a catalogue application is created, and you can read and change them like any other line: secrets Cloud generates for the application, and the answers you gave on its form, such as an API key.