n8n AI Assistant on a self-hosted server

What is it?

n8n's AI Assistant runs untrusted, model-generated code, so it will not execute that code inside your main n8n container. It delegates execution to a sandbox — an isolated container runtime that can be created and destroyed per request. n8n's documentation points self-hosters at Daytona, a commercial sandbox provider, which is why many people assume the Assistant is Cloud-only or paid-only. It is not: n8n also ships an official sandbox service you can run yourself with Docker, provided the host can create nested containers safely. That is what sysbox is for — a container runtime that lets a container act like a lightweight VM, so Docker-in-Docker works without giving the inner container privileged access to your host. The guide walks through installing sysbox on the host, running the official sandbox image, wiring n8n to it with a handful of environment variables, and verifying the Assistant end to end from the n8n editor.

Why this guide matters for self-hosters

Self-hosting n8n has always involved a quiet trade-off: you get full data control and unlimited executions, but a few Cloud conveniences arrive late or require extra plumbing. The AI Assistant was the most visible example — the button exists in your editor, and clicking it tells you the feature is unavailable.

What made this frustrating is that the missing piece was never the model or a licence. It was the execution sandbox. Because the official documentation demonstrated the integration with Daytona, the community reasonably concluded that a paid third-party account was mandatory. Oli Morris's write-up is valuable precisely because it disproves that: n8n publishes a sandbox service image, and with the right host runtime you can point the Assistant at your own instance of it.

For anyone running n8n on a VPS, a homelab box or inside a company network where sending workflow content to another SaaS vendor is not acceptable, this closes a real gap. You keep the isolation guarantees that motivated the sandbox in the first place, without adding a new external dependency to your architecture.

• The Assistant is not a paid add-on — the blocker is sandboxing, not licensing.
• Daytona is one supported provider, not the only possible one.
• The official sandbox service can run on hardware you already pay for.
• Nothing about your existing workflows or credentials has to change.

The architecture in plain terms

Three components talk to each other. First, your n8n container: it hosts the editor, holds credentials and decides when the Assistant is invoked. Second, the sandbox service: a long-running container that accepts 'run this code' requests and answers with output. Third, the ephemeral workspaces the sandbox service creates internally — one short-lived container per execution, destroyed afterwards.

The third component is the reason a plain Docker host is not enough. Creating containers from inside a container is normally either impossible or unsafe. sysbox solves it at the runtime layer: containers started with the sysbox-runc runtime get their own user namespace, their own procfs view and their own container engine, so nested Docker behaves normally while the host kernel stays protected.

Once that foundation exists, the integration itself is unremarkable — an internal Docker network, a service name, a port and two or three environment variables on the n8n side. Most people who fail at this setup fail on the host runtime step, not the n8n step.

Before you start: is your host suitable?

sysbox needs a real Linux kernel it can install a runtime against — Ubuntu and Debian hosts are the smoothest path. It works on bare metal, on most KVM-based VPS products (Hetzner, DigitalOcean, Contabo and similar), and inside full virtual machines. It does not work on container-based hosting where you never touch the kernel: OpenVZ or LXC VPS plans, shared PaaS runtimes and most managed 'deploy a container' platforms.

Give the machine some headroom. n8n itself is happy on 1–2 GB of RAM, but each sandbox workspace wants its own slice, so 4 GB and two vCPUs is a comfortable floor if you intend to use the Assistant regularly. Disk matters too — nested container images accumulate.

If your host cannot run sysbox, you are not stuck. Keep the Assistant disabled and use the standard route instead: an AI chat model of your choice called from workflows, or a separate machine that runs the sandbox service and is reachable over a private network.

Sandbox options compared

How to use it — step by step

1. 1Confirm your host runs a supported Linux distribution on a real kernel (KVM VPS or bare metal), and that you have root access.
2. 2Update your n8n instance to a recent version — the Assistant and its sandbox settings are only present in current releases.
3. 3Install the sysbox runtime on the host and restart the Docker daemon so it registers the new runtime.
4. 4Verify sysbox by starting a throwaway container with the sysbox-runc runtime and running Docker inside it.
5. 5Pull and start the official n8n sandbox service container, attached to a dedicated internal Docker network and using the sysbox runtime.
6. 6Do not publish the sandbox port to the host — leave it reachable only by service name on the internal network.
7. 7Add the sandbox provider and endpoint environment variables to your n8n container and recreate it so the settings take effect.
8. 8Open the n8n editor, trigger a node error on purpose, and click the Assistant to confirm it responds with a real explanation.
9. 9Ask it to generate an expression and a small Code node snippet to confirm code execution reaches the sandbox.
10. 10Apply resource limits and an idle timeout to the sandbox service, then add both containers to your usual backup and update routine.

Quick checklist

• Linux host with root access and a real kernel
• Recent n8n release installed
• sysbox runtime installed and verified
• Sandbox service running on an internal Docker network
• Sandbox port not published to the host or the internet
• n8n environment variables set and container recreated
• Assistant tested on a failing node and a Code node
• CPU, memory limits and idle timeout configured

Pro tips

• Snapshot your VPS before installing a new container runtime — rolling back is then a one-minute operation.
• Keep the sandbox service on its own Docker network so no other container can reach it by accident.
• Watch container count and disk usage for the first week; stale workspaces are the usual cause of surprise disk pressure.
• Pin image tags instead of using latest, so an unattended pull cannot change the runtime under you.
• The Assistant is best at explaining errors and drafting expressions — treat generated Code node output as a first draft, not as reviewed code.