Set variables and secrets

Set inherited configuration and secrets, then deploy to apply changes.

Copy page

Set variables at the product, environment or service level, then redeploy to apply them. The most specific value wins: service overrides environment, which overrides product. Saving or deleting a variable does not restart a running container.

Before you start

• Choose the product, environment and service that should receive the value.
• Use keys of up to 128 uppercase letters, digits and underscores, starting with a letter or underscore. DATABASE_URL is valid; 2ND_TRY is not.
• Keep a copy of credentials you cannot regenerate: secret values cannot be read back.
• For MCP, use a product-scoped token with Deployment write for service/environment variables and redeploy, admin for product variables, and read for listing.

1. Choose the level

In the Product App, Service → Variables shows the merged result. Inherited rows are tagged product or env; edit them where defined. Environment values are under Environment → Settings → Variables.

For MCP, use deployment_variable_set, deployment_variable_set_env or deployment_variable_set_product. Each takes key and value; service and environment operations also take their respective ID.

2. Save the value

Values are strings and can contain line breaks. The setter schema allows up to 262,144 characters. Mark credentials with isSecret: true when using MCP.

A secret is encrypted and write-only: listings return its key without its value. You can overwrite it, but cannot change it back into a plain variable. To make a value readable again, delete the secret and create a plain variable with that key.

Forking an environment omits environment-level and service-level secrets entirely, including their keys. Set the new environment’s secrets before deploying services that need them. Plain variables at those levels are copied.

3. Add references if needed

Use ${{KEY}} inside a value to resolve another variable when a release is built. You can combine references with ordinary text.

For an environment-managed PostgreSQL database whose slug is postgres, set the service’s DATABASE_URL to ${{postgres.DATABASE_URL}}. Replace postgres with your database’s slug. Copy exact keys from the database’s Connect view, and mark a variable referring to a secret connection string as secret too.

4. Redeploy and verify it works

Choose Redeploy, or use deployment_service_redeploy. Lepsto merges the levels, decrypts secrets and resolves references into a fixed release snapshot.

Check the merged keys with deployment_variable_list, then confirm the deployment is Active and the application uses the new setting. Check behavior without printing secret values. Removing a key also needs a redeploy; use the matching service, environment or product unset operation in the tool reference.

Static repository builds receive non-secret variables at build time only. They have no runtime container to receive later changes.

Variables supplied by Lepsto

Change the service’s port setting to change PORT; do not set the variable. These values can be referenced with ${{KEY}}.

Git-built services also receive LEPSTO_GIT_COMMIT_SHA and LEPSTO_GIT_BRANCH. You cannot reference these two with ${{KEY}}: variable references resolve before the build knows the commit. Reading them from the running container is supported.

Reserved keys

You cannot define these at any level:

• Any key starting with LEPSTO_PLATFORM_.
• The exact keys LEPSTO_SERVICE_ID, LEPSTO_ENVIRONMENT_ID, LEPSTO_ENVIRONMENT_NAME, LEPSTO_PRODUCT_ID, LEPSTO_DEPLOYMENT_ID, LEPSTO_PUBLIC_DOMAIN, LEPSTO_GIT_COMMIT_SHA and LEPSTO_GIT_BRANCH.
• PORT.

The whole LEPSTO_ prefix is not reserved. Keys such as LEPSTO_REALTIME_API_KEY, LEPSTO_USERS_SERVER_KEY, PUBLIC_LEPSTO_API_KEY and LEPSTO_REGION remain ordinary keys you can set.

A reserved key is refused when saved. A second check while assembling a deployment drops conflicting stored variables and records deployment.variable.ignored in its events.

LEPSTO_PUBLIC_DOMAIN is reserved but currently not injected into the container, even when the service has a domain. Read the address from the service’s domains instead of expecting this variable.

Rollback keeps current variables

Editing a value or a referenced database connection does not change an existing release. The next deployment resolves it again. Rollback also resolves current values: it restores the image, not the old configuration. Undo a bad variable change yourself before redeploying or rolling back.