Code node

Purpose

The Code node runs your own Python code as a step in a workflow. Use it for data transformation, custom logic, calculations, reshaping data between nodes, or anything that’s easier to express in code than with other nodes. Like every other node, the Code node receives inputs from upstream nodes through the workflow’s variable store and returns output that downstream nodes can use. It’s the escape hatch for the moments when a quick bit of Python is clearer than wiring together a chain of nodes.

Python is the only supported language today.

When to use Code vs other nodes

Reach for the right node for the job. The Code node is for logic you write yourself — not for talking to the outside world.

Node	Use it for
Code	Custom logic, calculations, and data transforms you express in Python
Tool	Acting on external systems via MCP (email, calendar, databases, files)
Agent	LLM reasoning, interpretation, and decisions over natural language
API	Direct HTTP calls to external services

If you can describe the step as “take this data and reshape/compute it,” use a Code node. If the step needs to reach an external system or service, use a Tool node or API node instead.

How it works

Inputs arrive from upstream nodes

The Code node reads its inputs from the variable store, exactly like other nodes. Data produced by previous nodes — and any files passed in as inputs — are available to your code.

Your Python runs in an isolated sandbox

Your code executes inside a strict, single-use sandbox with a working directory of its own. Each run is fully isolated and cannot see other executions or the platform itself.

Output is captured

The value your code returns becomes the node’s output. Console output is captured for debugging, and any files your code writes are registered as downloadable workflow files.

Downstream nodes consume the result

Your output is written to the variable store so subsequent nodes can reference it.

Typed inputs and outputs

The Code node isn’t free-form scripting — you declare its input fields and output fields at design time, and the platform enforces that contract at run time.

Input fields each have a name, a type, and a source (an upstream value, a template, or a default). Types are string, number, integer, boolean, array, object, or file.
Output fields each have a name and a type from the same set. Your code’s return value is validated against them before it flows downstream, so a malformed result fails the node with a clear per-field error instead of quietly passing bad data on.

A declared file input is downloaded into the sandbox and handed to your code as a local path string; a declared file output is a path your code writes, which the platform uploads and replaces with a downloadable file reference. Every other type maps to its natural Python type.

Writing code

Your script defines a single function, run(inputs) -> Outputs. The platform synthesizes typed Inputs and Outputs classes from your declared fields and prepends them automatically — you don’t import or define them. Read inputs as attributes (inputs.records) and return a dict (or an Outputs instance) whose keys match your declared output fields:

# input field:  records (array)
# output fields: records (array), total_revenue (number), record_count (integer)
def run(inputs: Inputs) -> Outputs:
    cleaned = []
    for row in inputs.records:
        cleaned.append({
            "name": row["name"].strip().title(),
            "email": row["email"].lower(),
            "total": round(row["price"] * row["quantity"], 2),
        })

    total_revenue = sum(item["total"] for item in cleaned)

    return {
        "records": cleaned,
        "total_revenue": total_revenue,
        "record_count": len(cleaned),
    }

The returned value is validated against your output fields, then written to the variable store where downstream nodes reference it as code-<id>.<field>.

There’s a size cap on the code you submit (50,000 characters), and captured console output is truncated if it gets very large (30,000 characters). Keep code focused and avoid printing huge payloads.

The sandbox

Code nodes run in a strict sandbox so that custom code stays safe and contained.

No network access

Code can’t make outbound network calls. Use a Tool or API node to reach external services, then pass the results in.

Least privilege

Code runs as a non-root user with CPU, memory, and process limits.

Full isolation

Each run gets its own throwaway environment. Code can’t see other executions or the platform itself.

Wall-clock timeout

A per-run time limit (default 30 seconds, maximum 120 seconds) stops runaway code so a single step can’t run forever.

Two node settings control how a run is judged:

Timeout — the wall-clock cap for one execution. Default 30 seconds, hard ceiling 120 seconds.
Fail on stderr — when on, any output to stderr fails the node. Off by default, because Python routinely writes non-fatal warnings to stderr; turn it on only when you want the node to be strict about clean output.

Because the sandbox has no network access, you cannot call external APIs from inside a Code node. To bring in external data, use a Tool node (MCP) or an API node earlier in the workflow, then pass the results into the Code node.

Working with files

The Code node gets a working directory you can read from and write to. Declare a file-typed input field to receive a file, and a file-typed output field to hand one back.

Input files — A file input is downloaded into the sandbox and passed to your code as a local path string. Input files are limited to the current project.
Output files — Return the path to a file your code writes in a file output field; the platform uploads it and registers it as a downloadable workflow file. This means a Code node can produce a CSV, report, or image that later nodes — or you — can download.

# input field: source_file (file)  ->  a local path string
# output fields: summary (file), rows_processed (integer)
import csv

def run(inputs: Inputs) -> Outputs:
    with open(inputs.source_file, newline="") as f:
        rows = list(csv.DictReader(f))

    with open("summary.csv", "w", newline="") as out:
        writer = csv.writer(out)
        writer.writerow(["category", "count"])
        # ... write summarized rows ...

    return {"summary": "summary.csv", "rows_processed": len(rows)}

The summary.csv your code writes is captured as a downloadable workflow file.

Operator note: Each run executes in its own throwaway sandbox spun up by one of two backends: Docker (a per-execution container, typical for self-hosted and development) or Kubernetes (a per-execution pod, typical for production). The backend is chosen by the operator’s deployment configuration and is transparent to workflow builders — the authoring experience and limits are the same either way.

Best practices

Keep external calls out of Code nodes

The sandbox has no network. Fetch data with a Tool or API node first, then transform it in the Code node.

Return structured output

Return a dictionary with clearly named fields so downstream nodes can reference exactly what they need from the variable store.

Watch your output size

Console output is truncated when very large. Print only what you need for debugging, and pass real results through the return value.

Use files for large artifacts

For reports, exports, or images, write a file rather than returning a giant string. Output files become downloadable workflow files.

Stay within the time limit

A wall-clock timeout (default 30 seconds, maximum 120 seconds) stops runaway code. Keep loops bounded and avoid heavy work that won’t finish in time.

Next steps

Workflow overview

See how nodes connect and how data flows through a workflow

Tool node

Reach external systems via MCP, then pass results into Code

Agent node

Add LLM reasoning when a step needs interpretation or decisions

Memory system

Understand the variable store that feeds your Code node

Getting Started

Platform Guide

Agents

Workflow Builder

Tools & Integrations

Models & Providers

Cookbooks

Security & Administration

Purpose

When to use Code vs other nodes

How it works

Typed inputs and outputs

Writing code

The sandbox

No network access

Least privilege

Full isolation

Wall-clock timeout

Working with files

Best practices

Next steps

Workflow overview

Tool node

Agent node

Memory system

​Purpose

​When to use Code vs other nodes

​How it works

​Typed inputs and outputs

​Writing code

​The sandbox

No network access

Least privilege

Full isolation

Wall-clock timeout

​Working with files

​Best practices

​Next steps

Workflow overview

Tool node

Agent node

Memory system

Purpose

When to use Code vs other nodes

How it works

Typed inputs and outputs

Writing code

The sandbox

Working with files

Best practices

Next steps