Deploying Workflows
Deploying a workflow means making it reachable by real traffic. This page covers execution modes, trigger configuration, and how to verify everything is working.
Every deployed workflow uses one of three execution modes. You set this in the Deploy dialog.
| Mode | Where your code runs | Best for |
|---|---|---|
| CLI | Your server or machine | Full control, data stays on your infra |
| Managed | Tensorify cloud | Zero infra, no runner to maintain |
| Auto | CLI if a runner is connected, Managed as fallback | Hybrid — local when available |
Your workflow only executes when tensorify run <workflowId> is running and connected. If the runner goes offline, incoming requests will queue or fail depending on your timeout configuration.
Use CLI mode when:
- Your workflow accesses local resources (databases, file systems, internal APIs)
- You need payload data to stay within your infrastructure
- You want full control over the execution environment
Tensorify runs your workflow in its cloud execution environment. No runner is required.
Use Managed mode when:
- You don't want to maintain any server infrastructure
- Your workflow only calls external APIs (no internal resources)
- You want automatic scaling
Routes to your CLI runner when one is connected. If no runner is online, falls back to Managed execution automatically.
A Webhook trigger workflow responds to HTTP POST requests from external services.
Open the Webhook Deploy dialog
Click the Deploy button in the top toolbar of the canvas editor while your Webhook trigger node is selected.
Copy the webhook URL
The Deploy dialog shows your unique webhook URL. Copy it — this is the URL you will give to the external service (Stripe, GitHub, etc.).
Set execution mode
Choose CLI, Managed, or Auto. If you choose CLI, make sure tensorify run <workflowId> is running on your server before any requests arrive.
Configure verification (optional)
If the external service signs its requests (Stripe uses HMAC-SHA256, GitHub uses X-Hub-Signature-256), enable verification in the Webhook node settings and paste your signing secret.
Test it
Send a POST request to the webhook URL and check the Jobs page to verify execution succeeded.
An API Endpoint trigger exposes a programmable HTTP endpoint that can return a synchronous response.
Open the API Trigger Deploy dialog
Click Deploy in the toolbar. The dialog shows your endpoint URL, which includes the path you configured in the API Endpoint node settings.
Copy the endpoint URL
This URL is where callers send requests. It supports multiple HTTP methods if you configured them in the node.
Configure auth
In the API Endpoint node settings, set authType to api-key or bearer-token and provide a secret. Callers must include this credential in their requests.
Connect a Return node
For synchronous responses, your workflow must include a Return node connected to the final output. The value wired into the Return node becomes the HTTP response body.
If you set responseMode to use-workflow-response but do not connect a Return node, the caller's request will hang until the timeout.
When using CLI execution mode, your runner must be connected before requests arrive.
- Start your runner:
tensorify run <workflowId> - Go to the Runners page in the sidebar
- Confirm your runner shows a Connected status and a recent heartbeat timestamp
Every execution creates a job record. After deploying, check the Jobs page to monitor runs.
From the Jobs page you can:
- See execution status and duration
- Inspect per-node outputs for any run
- Identify which node failed and why
- Re-run a job with the same trigger payload
- Running Workflows — keep runners alive in production
- Webhook plugin — full webhook configuration reference
- API Endpoint plugin — full API endpoint configuration reference
- Jobs page — team settings and permissions