Environments

Environments are runtime targets where workflows actually execute.

The platform UI is the control plane. Environments are the execution plane.

This separation enables centralized design and governance while supporting distributed execution across cloud and edge devices.

Environment Types

Cloud Environment (Default)

Each project includes a default cloud environment.

Use it for:

early development
quick validation
centrally managed execution

Custom Environments (Edge / On-Prem)

Custom environments are user-managed runtime targets.

Use them for:

low-latency processing near data source
restricted-network/on-prem requirements
hardware-specific execution (GPU devices, gateways)

Environment Lifecycle

Create environment record in project
Install and run runtime agent with environment ID
Validate status and heartbeat
Deploy workflows to environment
Monitor health and execution behavior
Update, restart, or retire environment

Create an Environment in the Platform (If Missing)

If you don’t see the environment you expect in a project, create it from the platform UI:

Open your Project.
Go to Environments.
Click Create Environment.
Give it a clear name (location + purpose).
Save, then follow the Agent Install instructions shown for that environment.

After the agent is installed and running, the environment should switch to online once heartbeats are received.

Status Model

Common status states:

online: healthy and reporting heartbeats
offline: heartbeat missing beyond threshold

Practical implication:

Deployments to offline targets should be blocked or delayed
Monitoring should alert on repeated online/offline transitions

What to Validate Before Deployment

Environment status is online
Required models are available and compatible
Datasource connectivity is valid from target location
Bucket paths and permissions are accessible
Attributes and secrets are present (URLs, feature flags, credentials)

Do not deploy critical workflows to an environment that has not passed heartbeat and dependency validation checks.

Attributes and Secrets

Environments can store two kinds of configuration that are synchronized to the runtime agent:

Attributes: non-secret configuration (base URLs, IDs, feature flags, thresholds).
Secrets: sensitive values (API keys, tokens, passwords).

In the platform UI, you manage both under the environment’s settings. The backend persists them and the edge agent receives them via sync.

Using Attributes and Secrets in Workflows

Workflow node configs can reference environment values using templates:

{{environment.attribute.someKey}} (or shorthand {{attribute.someKey}})
{{environment.secret.someKey}} (or shorthand {{secret.someKey}})

Use this pattern to keep workflows portable across environments: encode structure in the workflow, and keep deployment-specific values in environment attributes/secrets.

For a deeper explanation of the runtime message shape, see Workflows.

Operational Best Practices

Use explicit environment naming by location and purpose
Separate dev, staging, and production targets
Keep one agent identity per physical runtime target
Track environment-level incidents in operations logs
Apply controlled rollout when deploying major workflow updates

Security Practices

Use scoped credentials per environment
Rotate tokens and secrets regularly
Restrict network access to required upstream/downstream endpoints
Minimize exposed management surfaces on edge nodes

Troubleshooting Priorities

When an environment fails, check in this order:

Agent/container process health
Network path to platform APIs
Credential/token validity
Runtime resource pressure (CPU, RAM, storage)
Workflow/model compatibility issues

Environment Reference Pages

PreviousAPI Endpoint Index

NextRead Timeseries Node