Variables and secrets

Variables configure builds and running services. Secrets use the same runtime delivery path but must never be committed to the repository.

Open variables

1. Select the environment.
2. Open Project Settings → Variables.
3. Choose the service variables or shared environment variables section.

Service variables affect one service. Shared variables reduce duplication across services in the selected environment.

Add values

Use the key/value editor for individual values or the raw editor for a reviewed .env-style block.

NODE_ENV=production
LOG_LEVEL=info
API_BASE_URL=https://api.example.com

Do not paste comments, shell export statements, or unreviewed local development credentials into production.

Managed-resource bindings

When a value comes from a managed resource, use an Application Plan binding instead of manually copying the resolved secret. The project workspace renders the binding in this form:

bindings:
  - source: resource.cache.connection_url
    target: service.worker.environment.REDIS_URL

Bindings remain correct if the underlying credential or private hostname is rotated. Source-connected projects can commit this binding because it contains only stable object keys and a variable name, not a credential.

When changes take effect

Variable changes require a redeploy to reach existing containers. Review the selected environment and changed keys, save, then redeploy the affected service or project.

Security rules

• Keep secrets out of autodisc.yml, Dockerfiles, build arguments, and Git.
• Never paste secret values into an AI preparation instruction or support message.
• Use different production and preview credentials.
• Rotate a credential after accidental exposure; deleting it from the UI does not remove it from Git history or old logs.
• Give a service only the variables it requires.

Common failures