# Environments

Understand where configuration values and live Workflow versions are separated, and how a Run selects an Environment.

Last updated: 2026-10-22

An Environment is a named setup inside your Workspace, such as staging or production. It has its
own configuration values and Deployments: the records of which Workflow versions are live there.

Use separate Environments when the same Workflow needs different values or account access during
testing and live use.

These are your Workspace's Environments. Their names do not select Typenode's own staging or
production service, or change which Google app Typenode operates for that service.

## What is separate

Each Environment has its own Variable values, Secret values and Credentials. Workflows running in
the same Environment use that Environment's configuration.

For example, `vars.API_URL` can point to a test service in staging and the live service in
production. Setting it in staging does not set a value in production. Environment names do not
establish a parent-child hierarchy or a chain of inherited values.

The names themselves belong to the Workspace. A name cannot be a Variable in one Environment and
a Secret in another. See [Variables](/configuration/variables#names-and-values) and
[Secrets](/configuration/secrets#scope-and-workflow-access) for their value and access rules.

Custom [OAuth apps](/configuration/oauth-apps) belong to the Workspace. The
[Credentials](/configuration/credentials) authorized through them belong to individual Environments.

## Which Environment a Run uses

The selection depends on what you ask Typenode to do:

| Action | Environment selection |
| --- | --- |
| Read or change configuration through the Agent's tools | Specify the Environment explicitly |
| Test a Workflow's draft | Uses `test` unless another Environment is specified |
| Test a specific saved Workflow version | Specify the Environment explicitly |
| Ask an Agent to run a published Workflow | With one deployed Environment, Typenode can select it. With several, specify one. Publish first if none is deployed. Access and Deployment checks still apply. |

> [!WARNING]
> Test Runs can make real external calls
> A test Run uses the selected Environment's actual accounts and values. This applies in every Environment, including one named test or staging. The name alone does not make outside-service calls harmless.

Choose the Environment whose service accounts and values you intend to use, and check what the
Workflow will do before testing it.

## Publishing and configuration changes

Publishing makes a Workflow's draft live in a selected Environment. A Deployment in staging does
not make that Workflow live in production.

Updating an existing Variable or Secret value does not require republishing for later Runs to use
it. Timing differs for Runs already underway; see
[Variable changes](/configuration/variables#when-a-change-takes-effect) and
[Secret changes](/configuration/secrets#changing-a-secret).

## Removing an Environment

Unpublish its Workflows first and finish or cancel active Runs. Typenode blocks Environment deletion
while published Workflows or unresolved active Runs remain.

Deleting an Environment removes its configuration values and Credentials. Keep any values you need
elsewhere before deleting it. Authorization at an outside service has its own lifecycle; see
[Credentials](/configuration/credentials).