LoopfourDeployment
Version and deploy workflows for production
Workflows are versioned. Each time you publish, the current canvas is captured as an immutable version and promoted to production. New triggers run against the deployed version, while in-progress runs continue on the version they started with. This section covers how versioning and deployment work.
Versioning Model
Every workflow has two tracks:
- Draft -- the working copy you edit on the canvas. Changes here do not affect production.
- Deployed -- the published version that live triggers execute against.
When you publish a draft, it becomes a new immutable version with an incrementing version number. Previous versions are retained so you can roll back.
| State | Description |
|---|---|
draft | Unpublished working copy, safe to edit |
deployed | Current production version, executed by triggers |
archived | A previous version, retained for rollback and audit |
Publishing a Workflow
Publishing captures the draft, validates it, and promotes it to production.
- Validate -- the DAG is checked for cycles, missing connections, and invalid block configuration
- Version -- a new immutable version is created with an incremented number
- Promote -- live triggers begin executing the new version
- Retain -- the prior version is archived for rollback
In-flight runs are not affected by a new deployment. A run always completes on the version it started with. Only new trigger events use the newly deployed version.
Deployment and Triggers
How a deployed version starts running depends on the trigger type:
| Trigger | Behavior after deploy |
|---|---|
| Webhook | Next incoming webhook uses the new version |
| Schedule | Next scheduled fire uses the new version |
| Event | Next platform event uses the new version |
| API | Next API invocation uses the new version |
Disabling a workflow stops new triggers from starting runs without deleting any versions.
Rollback
If a deployed version misbehaves, roll back to a previous version. Rollback re-promotes an archived version to deployed; new triggers immediately use it. Runs already in progress are unaffected.
Rolling back does not retroactively fix runs that already failed on the bad version. Re-run affected inputs after rolling back if reprocessing is required.
Best Practices
- Test in draft before publishing. Use the draft track and manual runs to validate changes before promoting to production.
- Publish small, focused changes. Smaller deployments are easier to reason about and roll back.
- Design for idempotency. Because runs can overlap across versions and triggers guarantee at-least-once delivery, workflows should be safe to re-run with the same input.
- Keep a rollback plan. Know which version was last known-good before deploying a risky change.