Skip to main content
Deploying publishes your workflow so it can be run by your team or called through the API. You edit freely on the canvas, but only a deployed version serves real traffic.

​
What a deployment is

A deployment is a versioned snapshot of your workflow at the moment you deploy it. Editing the canvas afterward does not change a deployment — your live version stays stable until you deploy again. This means you can keep improving a workflow without disrupting whatever is already running in production.

​
Deploying

1

Save your workflow

Make sure the builder header shows your workflow as saved. The Deploy control is disabled while you have unsaved changes.
2

Click Deploy

Use the Deploy control in the builder header. You’ll be asked for an application name — this identifies the deployment. The platform then creates a new deployment version.
3

Confirm it's live

When deployment finishes, the workflow shows a Deployed status.

​
The active deployment

Each time you deploy, a new version is created (v1, v2, and so on). One version is active at a time — that’s the one that actually runs when the workflow is triggered. From the version selector you can see every version and switch which one is active: select an earlier version to load it back into the canvas, then activate it. This lets you roll back to an earlier version if a new deployment doesn’t behave as expected.
Deploying again doesn’t delete earlier versions. Your deployment history is kept so you can always return to a known-good version.

​
Stopping a deployment

If you need to take a workflow out of service, use Stop Deployment in the builder header. This deactivates the active deployment — the workflow can no longer be triggered by your team or through the API until you deploy again. Your version history is retained.

​
After deploying

A deployed workflow can be run in two ways:

By your team

Through the platform interface.

Through the API

Triggered from your own applications.