Environments
Understand where configuration values and live Workflow versions are separated, and how a Run selects an Environment.
Last updated
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 and Secrets for their value and access rules.
Custom OAuth apps belong to the Workspace. The 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. |
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 and Secret changes.
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.