By default, a recipe runs from the canvas: you click the run button on the trigger node, the trigger fires, and the rest of the graph executes. Deploying turns a recipe into a server-side automation — a managed deployment that runs whenever its trigger fires, without the canvas open and without anyone clicking Run. Deployed automations live under /automate, separately from the /recipes authoring gallery.
What can be deployed
Not every recipe can be deployed. A recipe is deployable when both of these are true:
- It starts from a server-side trigger that supports activation. Today that means Slack trigger or GitHub trigger. Webhook trigger and Schedule trigger are coming soon and will deploy through the same path. Manual trigger is canvas-only — it has no activation hook, so a Manual-rooted recipe cannot deploy.
- It contains no Local nodes. Local file, Extract image, and Local preview need a browser session, so any recipe that uses one is local-only and will be rejected at deploy time.
If you try to deploy a recipe that doesn't satisfy both, you'll see a WORKFLOW_NOT_DEPLOYABLE error naming the offending nodes (or "Add a schedule, webhook, or provider trigger before activating this workflow." if there's no activatable trigger). Remove or replace the offending nodes, then deploy again.
Typical deployable shapes
- Slack trigger → GitHub → Library → Create share link → Slack
- GitHub trigger → GitHub (list changed files) → GitHub (fetch file) → Library → Create share link → Slack
Typical non-deployable shape (canvas-only)
- Manual trigger → Local file → Extract image → Library → Local preview → Send to desktop
Authoring against a real trigger before you deploy
Triggers like Slack and GitHub fire from real external events, so you usually can't design a recipe blindly — you need a sample payload to wire downstream nodes against.
Use the trigger node's Listen button in the property panel's run footer:
- Select the trigger node and click Listen. The button label flips to Listening while the platform waits for the next matching inbound event.
- Trigger the event from the source — post in the watched Slack channel, push a commit to the watched GitHub repo, etc.
- The platform captures one real event and feeds it into the recipe's authoring run data, so the rest of your nodes see real fields and you can map against them.
- Click Listen again to cancel before an event arrives, or wait until it expires.
Once the trigger has a captured payload, you can use Test step on any downstream node to run the recipe up to that point and iterate.
Deploying a recipe
When the recipe is in shape, deploy it from the canvas title menu at the top-left of the canvas:
- Click the recipe title to open the menu.
- Pick Deploy.
The platform flushes any pending local saves, compiles the canvas into a deployment snapshot, and sends it to the server. On success you'll see "Workflow deployed — This recipe is now available in Automate." and the title menu's deploy entry switches from Deploy to Update deployment.
Behind the scenes, the deploy step:
- Validates the snapshot.
- Rejects local-only nodes (WORKFLOW_NOT_DEPLOYABLE).
- Checks credentials — every credential reference in the snapshot must be owned by you (or be private and grantable). If not, you'll get WORKFLOW_CREDENTIAL_GRANT with the suggested action: "Reconnect or select a passport you own, then deploy again."
- Confirms there's no existing deployment for this recipe (otherwise WORKFLOW_ALREADY_DEPLOYED — use Update deployment instead).
- Saves the deployment. It starts inactive.
The recipe now appears in /automate.
Activating a deployment
A deployed recipe doesn't run yet — you have to activate it.
In /automate, each deployment has a switch on its card. Toggling the switch on tells the platform to wire up the trigger to receive real events. For each built-in trigger this means:
- Slack — registers the workflow so inbound Slack events get routed to it.
- GitHub — installs (or refreshes) the webhook subscription on the selected repository.
- Webhook (coming soon) — registers the inbound URL on the platform's webhook router.
- Schedule (coming soon) — installs the cron entry.
If activation succeeds, the card flips to Active and the trigger is live. If it fails, the deployment stays inactive and you'll see the diagnostic — fix the cause (reconnect a credential, change the watched repo, etc.) and toggle again.
Toggling the switch off tears down those trigger registrations. Your "turn this off" intent is always honored — even if teardown surfaces errors, the state still flips to inactive so a misbehaving automation can be stopped.
Updating a deployment
Edits to a deployed recipe are not pushed automatically. The deploy entry in the title menu stays as Update deployment until you re-publish.
Pick Update deployment from the title menu to push the latest canvas state. What happens depends on the current state:
- If the deployment is inactive, it just replaces the snapshot.
- If the deployment is active, the platform tears down the old subscriptions, saves the new snapshot, and rebuilds against it.
- If the rebuild fails (WORKFLOW_REACTIVATION_FAILED), the new snapshot is saved but the workflow is left inactive — re-enable it from /automate once you've resolved the cause.
- If the old-snapshot teardown fails (WORKFLOW_PUBLISH_TEARDOWN_FAILED), the new snapshot is not saved and the workflow ends inactive. Resolve the underlying issue, then re-enable.
If you click Update deployment before the workflow has ever been deployed, you'll see WORKFLOW_NOT_DEPLOYED with the suggestion to use Deploy first.
The deploy entry only appears in the title menu after the platform has settled which state the workflow is in (deployed vs. undeployed), so the label can never lie.
Credentials and reauth
Connect-page credentials are referenced by id from inside the deployed snapshot. Two things to know:
- Ownership at deploy time. Deploy and update both check that you own (or have a grant for) every credential the snapshot references. Reconnect or pick a credential that's yours and re-deploy.
- Reauth at run time. A credential can drift to needs reauth (token expired, scope changed, app uninstalled). The deployment stays active, but executions using that credential will fail until you reconnect it from the Connect page. The original deployment doesn't need to be republished.
Removing a deployment
Two paths, depending on whether you want to keep the recipe to keep iterating on:
- Remove from Automate (the trash button on the /automate card) — tears down the deployment, runs the deactivation sweep, and removes the deployment record along with any related trigger registrations, webhook subscriptions, or schedules. The local recipe stays in /recipes so you can edit and re-deploy.
- Delete the recipe (full delete from /recipes) — same teardown, plus drops the local draft. Blocked if the recipe is currently shared via a public share link — disable sharing first.
Both are safely coordinated against any in-flight deploy or activate operations, so a remove can't race a concurrent change.
How automations differ from a manual run
Same execution engine, different entry path.
Manual / canvas runs
- Trigger: Manual / Listen / Test step
- Where it runs: Your browser session
- Local nodes allowed: Yes
- Lifecycle: None — runs and ends
- Shows up in: /recipes only
- Edits go live by: Saving
Deployed automations
- Trigger: Live external event (Slack, GitHub, webhook, schedule)
- Where it runs: Server-side worker
- Local nodes allowed: No (gated at deploy time)
- Lifecycle: Managed — activation and teardown are coordinated by the platform
- Shows up in: /recipes and /automate
- Edits go live by: Clicking Update deployment
The recipe in /recipes and the deployment in /automate are two views of the same workflow — a deployed recipe always has a backing local copy, and editing it in the canvas does not affect the live automation until you explicitly Update.
Common failure modes
- WORKFLOW_NOT_DEPLOYABLE — Snapshot has Local nodes, or no activatable trigger. Fix: Replace the local-only nodes or add a server-side trigger, then re-deploy.
- WORKFLOW_ALREADY_DEPLOYED — You hit Deploy on a workflow that already has a deployment. Fix: Use Update deployment instead.
- WORKFLOW_NOT_DEPLOYED — You hit Update on a workflow with no deployment yet. Fix: Use Deploy first.
- WORKFLOW_CREDENTIAL_GRANT — Snapshot references a credential you don't own. Fix: Reconnect the credential, or pick one you own, and try again.
- WORKFLOW_ACTIVATION_IN_PROGRESS — Another deploy, activate, or remove is in flight. Fix: Retry shortly.
- WORKFLOW_REACTIVATION_FAILED — Old snapshot torn down, new one saved, but rebuild failed. Fix: Re-enable from /automate after fixing the cause.
- WORKFLOW_PUBLISH_TEARDOWN_FAILED — Old-snapshot teardown failed; new snapshot was not saved. Fix: Resolve the underlying issue, then re-enable.
- WORKFLOW_SHARED_REMOVAL — Tried to delete a recipe that's currently shared. Fix: Disable sharing, then retry.
Every failure ends with exactly one toast, and the deployment-state label refreshes from the server, so you can re-read the current state without reloading the page.