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.

Execution Modes

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

Self-Hosted mode

Your workflow only executes when a runner is connected (tensorify runner start or tensorify runner install) and the workflow is deployed to it from the UI. If the runner goes offline, incoming requests will queue or fail depending on your timeout configuration.

Use self-hosted execution 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

Managed mode

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

Auto mode

Routes to your CLI runner when one is connected. If no runner is online, falls back to Managed execution automatically.

Plugin Compatibility by Execution Mode

All plugins execute in both CLI and Managed mode, but some have restricted capabilities in the managed cloud sandbox. The sandbox provides an ephemeral filesystem, limited installed tools, and no access to your local machine or network.

Plugin	CLI Runner	Managed (Cloud Sandbox)
File Ops	Full access to the runner host's filesystem	Runs in an ephemeral sandbox filesystem — no access to your local files, writes are discarded after execution
Shell	Full shell access with the runner process's permissions	Restricted sandbox shell — no sudo, limited installed tools, no access to localhost services
System Info	Reports the runner host's real resources (CPU, memory, disk, processes)	Reports the sandbox container's resources, not your machine
Code	Full Python environment with pip packages from your runner's venv	Python standard library only — no pip packages
All other plugins	Full capabilities	Full capabilities (HTTP Request, Transform, AI Agent, etc. work identically)

If your workflow uses File Ops, Shell, or System Info to interact with your own infrastructure, deploy with CLI execution mode. The managed sandbox runs these plugins but cannot access your local files, databases, or services.

Deploying a Webhook Trigger

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 a runner is connected on your server (tensorify runner start or tensorify runner install) before any requests arrive.

Configure authentication (optional)

Protect your endpoint from unauthorized requests. In the Webhook node settings, choose a verification method:

Tensorify API Key — callers send Authorization: Bearer tfk_... using a workspace API key. Simplest option.
Static Secret — match a secret value in a custom header.
HMAC Signature — cryptographic verification for providers like Stripe or GitHub.
Named Provider (Stripe, GitHub, Shopify, Clerk, Slack) — automatic signature verification with just a signing secret.

Test it

Send a POST request to the webhook URL and check the Jobs page to verify execution succeeded.

Deploying an API Trigger

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

Protect your endpoint. In the API Endpoint node settings, set authType:

Tensorify API Key — callers send Authorization: Bearer tfk_... using a workspace API key from Settings → API Keys. Recommended for quick setup.
API Key — custom key in a configurable header (default X-API-Key).
Bearer Token — custom token in the Authorization header.

For Chat Trigger workflows, auth is configured the same way — set authType in the Chat node settings.

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.

Verifying Your Runner

When using CLI execution mode, your runner must be connected before requests arrive.

Start your runner: tensorify runner start (or tensorify runner install on a VPS)
Go to the Runners page in the sidebar
Confirm your runner shows a Connected status and a recent heartbeat timestamp

Monitoring with Jobs

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

Next Steps

Running Workflows — keep runners alive in production
Webhook plugin — full webhook configuration reference
API Endpoint plugin — full API endpoint configuration reference
Chat Trigger plugin — OpenAI-compatible chat endpoints
Jobs page — team settings and permissions