Multi-Environment Deployments
NodeLoom supports deploying workflows across multiple environments: Development, Staging, and Production. Each environment is isolated, allowing you to test changes safely before they reach production users.
Enterprise feature
Overview
Every workflow can exist in up to three environments simultaneously. Each environment maintains its own activation state, execution history, and configuration. This separation ensures that changes made during development do not affect production traffic.
| Environment | Purpose |
|---|---|
| Development | Build and iterate on workflows freely. Errors here do not impact real users or data. |
| Staging | Test workflows with realistic data and integrations. Validate behavior before promoting to production. |
| Production | Live environment serving real users and processing real data. Only promote workflows here after thorough testing. |
Using the Environment Bar
When multi-environment deployments are enabled, the workflow editor displays an environment bar at the top of the page. The bar shows three cards (one per environment) arranged in a horizontal pipeline.
Each card displays the following information:
- Environment name and status dot. A colored dot indicates whether the environment is active (colored) or inactive (gray).
- Version number. Shows which version of the workflow is deployed in that environment.
- Active / Inactive toggle. For Staging and Production, a clickable badge lets you activate or deactivate the workflow in that environment without re-promoting.
- Promote button. An explicit button at the bottom of the card (for example, "Promote to Staging") triggers the promotion flow to the next environment.
Click any deployed environment card to view a read-only snapshot of the workflow definition at the version that was promoted to that environment. Development is always editable.
Promoting Workflows
Promotion copies the current workflow definition from one environment to the next. The promoted snapshot is independent of later edits in the source environment.
Open the workflow editor
Navigate to the workflow you want to promote. The environment bar appears at the top.
Click the promote button
On the Development card, click Promote to Staging. To promote from Staging to Production, click Promote to Production on the Staging card (available only after a Staging deployment exists).
Add optional notes
A confirmation dialog appears showing the source and target environments. You can add optional promotion notes (for example, "Added email notification step") to help your team track what changed. Click Promote to confirm.
Activate the environment
After promotion, the target environment shows an Inactive badge by default. Click it to toggle the workflow to Active so it starts responding to triggers.
Promotion rules
Activating and Deactivating
Each environment has an independent activation state. Activating a workflow in an environment means it will respond to triggers (webhooks, schedules, API calls) in that environment. Deactivating pauses trigger processing while preserving the deployed definition.
| Action | Effect |
|---|---|
| Activate | The workflow begins responding to triggers in that environment. Webhooks, schedules, and API-triggered executions are processed. |
| Deactivate | The workflow stops responding to triggers. The deployed definition and version are preserved for later reactivation. |
To toggle activation, click the Active or Inactive badge on the environment card in the environment bar. A workflow can be active in multiple environments at the same time.
Execution per Environment
When a workflow is triggered, NodeLoom determines which environment to execute in based on the trigger source:
- Webhook triggers use the environment-specific webhook URL to route requests to the correct environment.
- Schedule triggers execute in whichever environments the workflow is activated in. If active in both Staging and Production, the schedule runs in both.
- Manual executions from the editor always run in the Development environment.
- API-triggered executions accept an optional environment parameter. If omitted, they default to Production.
Execution history is tracked separately per environment. You can filter execution logs by environment to isolate debugging to a specific deployment stage.
Environment-Scoped Credentials
Credentials can be scoped to a specific environment or shared globally across all environments. This lets you use separate API keys, database connections, and service accounts for each stage of your pipeline.
- Global credentials are available in all environments. Use these for services where a single set of keys is acceptable (for example, internal utilities).
- Environment-scoped credentials are only used when executing in the matching environment. Use these for services where you need separate keys per stage (for example, a sandbox payment gateway for Staging and a live gateway for Production).
Credential isolation
Best Practices
- Always test in Staging first. Promote from Development to Staging and run end-to-end tests with realistic data before promoting to Production.
- Use environment-scoped credentials. Configure separate API keys, database connections, and service accounts for each environment to prevent test data from leaking into production systems.
- Add promotion notes. Include a brief description of what changed when promoting. This creates an audit trail that helps your team understand what each promotion introduced.
- Plan your rollback strategy. If a production deployment causes issues, deactivate the workflow in Production and promote a known-good version from Staging.
- Monitor after promotion. After promoting to Production, monitor execution logs and error rates closely for the first few hours to catch issues early.
- Keep Staging active. Maintain an active Staging deployment so you always have a tested fallback ready to promote to Production if needed.
Rollback