Environment Variables & Service References

Adding variables

Open a service's Environment tab to add variables one at a time, or paste a whole .env file at once — pasting re-uses existing keys (updating their value) and creates any new ones, the same way you'd expect re-pasting an updated .env to behave.

Values are encrypted at rest and never shown again in the list view after you save them — click Reveal on a specific variable if you need to see its value again.

Runtime vs. build time

A variable you set here is available to your running process — for a Web Service, set before your app starts; for a Cron Job, injected into each scheduled execution. Your app reads it exactly like any other environment variable (process.env.KEY, os.environ["KEY"], etc.).

These variables are not available inside your build command. If you need a value baked in at build time — a public API URL compiled into a JS bundle, for example — pass it inline in the Build Command field itself, which Infrly runs as a real shell command:

MY_PUBLIC_VALUE=https://example.com npm run build

This is the only way to get a value into a build, for every service kind, including a Static Site (which has no runtime process at all afterward, so this is also the only place a Static Site can ever receive a configured value — see that guide for the full explanation).

Referencing a sibling service

Rather than copying a database's connection string by hand, reference it directly:

DATABASE_URL=${{my-database.URL}}

${{<service-name>.FIELD}} is resolved at deploy time to the referenced service's real value. <service-name> is the display name you gave that service when creating it (not its public hostname), so it has to match exactly, and has to be unique within the project — if two services in the same project share a name, or the name doesn't match anything, the deploy fails immediately with a clear error rather than silently using the wrong value or a broken reference.

Referencing a sibling that hasn't been deployed yet is fine for HOST and PORT, which are just address construction. USER, PASSWORD, DATABASE, and the URL of a database or Key Value instance (which contains its password) need the sibling to have finished provisioning first; until then the deploy stops with a message telling you to redeploy once the sibling is running.

Field	Resolves to	Which service kinds
HOST	The sibling's internal hostname	any
PORT	The sibling's internal port	any
URL	The sibling's full internal connection string	any
USER	Database username	managed_postgres only
DATABASE	Database name	managed_postgres only
PASSWORD	Auth password	managed_postgres, managed_keyvalue

# A web service in the same project as "my-database" and "my-cache"
DATABASE_URL=${{my-database.URL}}
REDIS_URL=${{my-cache.URL}}

Next

• PostgreSQL · Key Value
• Build & Start Commands