n8n

The CreateOS community node for n8n puts a sandbox inside a workflow. Every other integration on this page attaches a sandbox to a coding agent; this one attaches it to an automation. A workflow step runs a shell command on a disposable Linux microVM and returns stdout, stderr, and the exit code as regular n8n data the next node can branch on.

That makes it the integration to reach for when the untrusted thing is not a build but an input: a command assembled from a form submission, a webhook body, or a row someone else controls.

At a glance

Package: @nodeops-createos/n8n-nodes-sandbox
Resources: Code, Sandbox, File, Template, Network, Disk, System
Auth: a CreateOS API credential, sent as X-Api-Key
Sandbox: created for the run and destroyed afterwards, by default
Usable as an AI agent tool: yes

Build it with a prompt. n8n can assemble the whole workflow for you. Once the node is installed, open the AI workflow builder and paste this:

Build a workflow that runs a shell command in a CreateOS sandbox.
Trigger it with an n8n Form that has one field named "command".
Then add the CreateOS node, resource Code, operation Run Command.
Set Sandbox to Create On Demand and leave Destroy Sandbox After Run on.
Map the node's Command field to the form's "command" value.
End with a node that returns stdout, stderr and exitCode.

That produces the workflow in the video below. The rest of this page explains what it is doing.

A form submission runs a command in a fresh sandbox, which posts the result out

Prerequisites

You need a self-hosted n8n. Community nodes install into your own instance, so this does not apply to n8n Cloud's managed node set.

You also need a CreateOS API key. Get one at createos.sh/app/profile.

Unlike the agent integrations, this node does not use the createos CLI. It calls the control-plane API directly, so createos login does nothing for it and the CLI is not a prerequisite.

Install

In n8n, open Settings → Community nodes, choose Install, and enter:

@nodeops-createos/n8n-nodes-sandbox

Then add a CreateOS API credential. It has two fields:

Field	Value
API Token	Your key from the profile page
API Base URL	`https://api.sb.createos.sh`

Saving the credential tests it against GET /v1/whoami, so a bad key fails immediately rather than on first use.

Running a command

The Code → Run Command operation is the one most workflows need. Point it at a sandbox, give it a command, and it returns the result.

The Sandbox field decides where the command lands:

Create On Demand provisions a fresh microVM for this run. This is the default.
Use Existing runs in a sandbox you already have, by ID.

When creating on demand, Create Sandbox Options controls the box:

Option	Default
Shape	`s-1vcpu-256mb`
Rootfs	`devbox:1`
Disk Size MiB	10 GB
Ingress Enabled	Off
Auto Pause After Seconds	0, meaning no auto-pause
Egress, Networks, Disks	Empty

Destroy Sandbox After Run is on by default and applies only to boxes the node created. It runs whether the command succeeded or failed, so a non-zero exit does not leave a VM behind. A sandbox you passed in by ID is never destroyed for you.

The command runs through /bin/sh -lc, so shell syntax, pipes, and redirects work as written. Environment Variables takes a JSON object, Stdin is fed to the process, and Timeout caps the request at 30 seconds by default. Raise it for anything slow, because the timeout covers the whole API call, not just the command.

What you get back

One item per input item, with these fields:

Field	Meaning
`success`	`true` when `exitCode` is 0
`exitCode`, `stdout`, `stderr`	The command's result
`sandboxId`	The box it ran on
`createdSandbox`	Whether this run provisioned it
`destroyedAfterRun`	Whether cleanup succeeded
`destroyError`	Present only when cleanup failed
`execMs`, `executionTimeMs`	Command time, and total time including provisioning

Branch on success rather than parsing stderr. A command can write to stderr and still exit 0.

Because the node takes one command per item, a workflow that fans out over a list gets one sandbox per item by default. That is usually what you want for isolation, and it is worth knowing before you point it at a thousand rows.

Moving files

File → Upload and File → Download move binary data between n8n and a sandbox. Both take a sandbox ID, a remote path, and the name of the binary field on the item, which is data unless you changed it.

Download names the file from the last segment of the remote path and attaches it as binary, with sizeBytes on the JSON alongside. Upload reads the binary field and sends it to the path you give.

Both need a sandbox that outlives the call, so pair them with Use Existing rather than a box that is destroyed after its run.

The other resources

Everything the node can do beyond running commands maps onto the REST API:

Resource	Operations
Sandbox	Create, Get, Get By IP, Get Many, Destroy, Pause, Resume, Fork, Patch, Metrics, Bandwidth, Recharge Bandwidth, Resize
Template	Create, Get, Get Many, Delete, Get Logs
Network	Create, Get, Get Many, Delete, Attach, Detach
Disk	Create, Get, Get Many, Delete, List Attachments, Attach, Detach
System	Whoami, List Shapes, List Rootfs

System → List Shapes and List Rootfs are the quickest way to find valid values for the Shape and Rootfs fields without leaving n8n.

Pause does not finish immediately. It returns while the sandbox is still pausing, so a Resume wired straight after it fails with sandbox is pausing, expected paused or error. Put a Wait node between the two, or poll Sandbox → Get until the status reads paused. The same applies to Destroy, which returns destroying.

Use Sandbox → Create rather than Run Command's on-demand option when a box has to outlive a single step: create it, keep the ID in the workflow, run several commands against it, and destroy it at the end.

As an agent tool

The node sets usableAsTool, so it can be attached to an n8n AI Agent node as a tool. The agent then gets a sandbox it can run commands in, which is the same shape as the coding-agent integrations but driven from inside a workflow.

Give the agent a sandbox and it will use it for whatever it decides needs running. Restrict egress on the sandbox if that matters, because the default is unrestricted.

Egress

A sandbox created by this node can reach the whole internet unless you say otherwise. The Egress field takes the same rules as the rest of the platform, and it is worth setting whenever the command is built from input you do not control.

Prefer IP and CIDR rules over domain rules when the goal is genuinely to stop exfiltration. Domain allowlists are a strong control for HTTPS and a weak one for cleartext HTTP.

n8n