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.
- Manual trigger is canvas-only - it has no activation hook, so a Manual-rooted recipe cannot deploy.
If you try to deploy a recipe that doesn't satisfy both, you'll see an error naming the offending nodes. 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 → Sources → Library → 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 Run 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.
- Checks credentials - every credential reference in the snapshot must be owned by you (or be private and grantable). If not, you'll get an error with the suggested action: "Reconnect or select a passport you own, then deploy again."
- Confirms there's no existing deployment for this recipe.
- 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.
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, 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, the new snapshot is not saved and the workflow ends inactive. Resolve the underlying issue, then re-enable.
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 are authorized to deploy.
- Reauth at run time. A credential can drift to needs reauth (token expired, permissions 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.
How automations differ from a manual run
Same execution engine, different entry path.
Manual / canvas runs
- Trigger: Manual / Listen / Run step
- Where it runs: Your browser session
- Lifecycle: None - runs and ends
- Shows up in: /recipes only
- Edits go live by: Saving
Deployed automations
- Trigger: Live external event (Slack, GitHub)
- Where it runs: Server-side worker
- 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 deployment.