Environment Variables

Environment variables belong to a service. Add them during service creation or from the Variables tab after the service exists.

Adding Variables

You can add variables one at a time or paste multiple .env lines. Forge understands lines like:

DATABASE_URL=postgres://user:password@host:5432/app
REDIS_URL=redis://default:password@host:6379

Lines starting with # are ignored. Duplicate keys are replaced by the latest pasted value.

Database Suggestions

When a project has database services, Forge suggests variables for app services in that project. Suggestions reference the database service instead of freezing one old URL.

Example:

DATABASE_URL=${postgres-db.POSTGRES_URL}

That makes app configuration easier to keep correct after Railway imports, database recreation, or a supported recovery operation.

.env.example Suggestions

For GitHub repository services, Forge can inspect .env.example variables from the selected branch and root directory. These suggestions help you remember required app variables without copying real secrets into source control.

Railway Imports

Railway imports can copy service variables. The default import option excludes RAILWAY_* variables because they usually describe Railway’s runtime, not the app’s portable configuration.

After a Railway import, Forge syncs database variables for recreated database services so app services point at the Forge-managed database URLs.

Secret Handling

Values are masked in the UI. Treat Forge service variables as runtime secrets and avoid using them as documentation. Keep source-controlled examples in .env.example without secret values.

Normal variables, including variables loaded from Doppler, are supplied to release commands and runtime containers. They are not supplied to source-analysis or Railpack build processes.

Names beginning with VITE_, NEXT_PUBLIC_, PUBLIC_, REACT_APP_, NUXT_PUBLIC_, GATSBY_, or EXPO_PUBLIC_ are different: Forge supplies them to source builds because those frameworks use them for public client configuration. Their values can appear in generated browser or mobile bundles. Never use a client-public prefix for a secret.

Forge does not currently accept private build-only secrets. Build private dependencies in a trusted external pipeline and deploy the resulting Docker image rather than exposing a credential through a public-prefixed variable.

Good Patterns

• Keep variables scoped to the service that needs them.
• Use database suggestions instead of hand-copying generated URLs when possible.
• Never add Forge Cloud platform credentials, GitHub App private keys, Agent registration tokens, or platform storage credentials to a workspace, project, service, build, or browser variable.
• Recheck variables after migrations and imports before deploying public traffic.