Skip to main content
Environment variables are encrypted configuration values for hosted servers. They are attached to a server, scoped to the deployment environment that will use them, and provided to your Python process when Horizon builds and runs a deployment artifact. Use environment variables for values your server code needs at startup, during manifest inspection, or while handling MCP requests: upstream API keys, database URLs, feature toggles, model names, and similar configuration.
Environment variables are available to hosted servers. External and remix servers use their own connection and authorization settings instead of hosted build-time environment variables.

Variable contract

Horizon treats an environment variable as part of the build and deployment input. When a build starts, Horizon resolves the target environment, decrypts the matching variables, applies any branch override, and includes the resulting key-value map in the build request. That timing matters. Changing a variable after a build starts does not change that build, and changing a variable after an artifact is live does not update the running server by itself. Create a new build and make sure the deployment selects that artifact before expecting server code to see the new value.
Avoid printing secret values to stdout or stderr. Horizon captures those streams as server logs.

Scopes

Environment variables are scoped by where the deployment will run.
ScopeUsed byBehavior
ProductionDefault-branch builds and production deploymentsValues used for the live production deployment path.
PreviewNon-default branch and pull request preview buildsValues used before production promotion.
Branch overrideA named preview branchOverrides the preview value for the same key on that branch only. Other preview keys are inherited.
Branch overrides only apply to preview deployments. If a preview branch has an override for DATABASE_URL, that branch receives the override and still inherits any other preview variables that are not overridden.
Keep production and preview credentials separate when the upstream system has separate projects, databases, accounts, or rate limits. Preview builds should be safe to test without touching production data.

Manage variables

Open the hosted server, then go to Settings > Environment Variables.
1

Add a variable

Choose Add New Variable, enter the key, value, optional description, and the scopes that should receive the value. Selecting both production and preview creates one variable record in each scope with the same initial value.
2

Choose whether the value is sensitive

Sensitive variables are write-only in the dashboard after creation. Non-sensitive variables can be revealed by users who can manage server settings.
3

Update or delete values per scope

Production and preview values are separate records. Updating one does not update the other unless you edit both.
4

Redeploy

Create a new build and deploy or promote it so server code receives the changed values.

Key rules

Variable names must:
  • Be 255 characters or fewer.
  • Start with an uppercase letter or underscore.
  • Use only uppercase letters, numbers, and underscores.
  • Not start with FASTMCP_CLOUD_ or HORIZON_, which are reserved by Horizon.
The dashboard uppercases keys as you type. Values must not be empty and can contain multiline content such as JSON.

Build-time and runtime behavior

Environment variables can affect both the build and the deployed server. During a build, variables may be available while Horizon installs dependencies, loads the entrypoint, and inspects the server manifest. If your server registers tools conditionally based on an environment variable, preview and production builds can produce different manifests. At runtime, the deployed Python process receives the variables that were included in the selected artifact. Horizon does not reinstall dependencies or refresh environment variables when a request arrives. For the full build lifecycle, see Build system. For runtime behavior, see Compute model.

Branch preview behavior

Preview variables are the base configuration for preview builds. Branch overrides layer on top of that base for one branch: each key takes the branch override if one exists, otherwise it inherits the preview base. For example, if the feature/search branch overrides only DATABASE_URL:
KeyPreview basefeature/search overrideBuild receives
DATABASE_URLpreview-dbsearch-branch-dbsearch-branch-db (overridden)
MODEL_NAMEtest-modeltest-model (inherited)
A different preview branch receives the base preview values unless it has its own override.

Rotation

Rotate a variable in the scope where the credential is used.
1

Create the replacement upstream credential

Keep the old credential active until Horizon has deployed the new value.
2

Update Horizon

Update the production, preview, or branch-scoped value that should use the replacement credential.
3

Build and verify

Start a new build, deploy it to the relevant preview or production deployment, and confirm representative tool calls succeed.
4

Revoke the old credential

Revoke the old value only after the deployment using the new value is live.

Troubleshooting

Confirm a new build started after the variable was saved, then confirm the deployment selects that build artifact. Existing artifacts keep the values they were built with.
Check whether the build is for the expected branch. Preview builds use preview variables, then apply branch overrides for that branch.
Branch overrides apply only to preview deployments. Confirm the override is attached to the exact branch name used by the build, then rebuild that branch.
Check the key name. Keys must start with an uppercase letter or underscore, use only uppercase letters, numbers, and underscores, and avoid reserved prefixes.
If tool registration depends on environment variables, compare the manifest for the build that is live with the expected scope and branch values.
Rotate the credential, update the matching Horizon scope, rebuild and redeploy, then remove or mask the logging statement in server code.

Hosted servers

Understand the hosted-server lifecycle and ownership boundary.

Builds

See how build inputs become immutable artifacts.

Deployments

Confirm which artifact is live for production or preview traffic.