Core Concepts

These are the fundamental concepts that power Tensorify. Read this page when you want to understand how the pieces fit together.

A workflow is a directed graph of nodes and edges that defines an automation. Workflows:

• are created and edited in the canvas editor at app.tensorify.io
• are compiled to Python by Tensorify at runtime
• are executed by the CLI on your infrastructure or by the Tensorify managed executor
• are uniquely identified by a workflow ID (visible in the URL)

Nodes are the steps in a workflow. Each node has a type that determines what it does. There are four categories:

Every workflow must begin with exactly one trigger node.

Edges connect node outputs to node inputs. Data flows through edges as the workflow executes.

Each node produces output variables that downstream nodes can use. For example:

• A Webhook trigger produces a webhook variable containing the full request envelope (body, headers, query, method)
• An HTTP Request node produces an http_request variable with status, data, and headers
• A Code node produces a code variable containing whatever your Python function returns

You reference upstream values in node settings using {{ }} expressions. For example, to pass the webhook body as the HTTP request body, set the body binding to {{ webhook.body }}.

tensorify watch is the development tool. It connects your local machine to the canvas editor so you can trigger test executions and inspect node outputs in real-time.

tensorify watch <workflowId>

How it works:

1. You click Test in the canvas editor and select a target node
2. The editor sends an execution signal to Tensorify's servers
3. The signal is forwarded to your local CLI process
4. The workflow runs locally up to the selected node
5. Outputs appear in both the terminal and the canvas editor

tensorify run is the production command. It registers your machine as an active runner and processes real incoming webhook and API trigger requests.

tensorify run <workflowId>

The CLI connects to Tensorify's hooks service via WebSocket and listens indefinitely. Every time a real request hits your deployed workflow endpoint, the hooks service routes it to your runner and the workflow executes locally.

Keep this process alive using a process manager like pm2, systemd, or a Docker container.

When you deploy a workflow, you choose an execution mode:

You set the execution mode in the Deploy dialog for each workflow.

A runner is an active tensorify run process that has registered itself with Tensorify. You can see all connected runners on the Runners page in the sidebar.

When execution mode is CLI, Tensorify routes incoming requests to a connected runner for the workflow. If no runner is connected, the request waits or fails depending on your timeout settings.

Every workflow execution creates a job record. Jobs are visible on the Jobs page and contain:

• execution status (running, completed, failed)
• start time and duration
• trigger details (which endpoint was hit, what payload was received)
• per-node output snapshots (available during and after execution)

Jobs are your primary debugging tool for production issues.

Team-level environment variables are managed on the Env Vars page. They are injected into workflow execution at runtime and accessible from Code nodes as standard Python environment variables:

import os
db_url = os.environ["DATABASE_URL"]

See Environment Variables for details.

• CLI Reference — full command reference
• Deploying Workflows — how execution modes and runners work in production
• Plugins — browse all available nodes