n8n is the answer people reach for when they want workflow automation without a SaaS bill and without their data leaving their infrastructure. It is a good answer to that question.
It is a different question from the one Spinrun answers. We build Spinrun, so read accordingly — but the distinction below is structural rather than competitive, and it will decide this for you faster than any feature comparison.
Drawing the path vs delegating it
n8n is a workflow engine. You build a graph of nodes and it executes that graph. The value is that the path is explicit, inspectable and yours — you can read it, version it, and run the whole thing on your own hardware.
Spinrun is an MCP gateway. There is no graph. An agent gets a set of tools and decides at runtime what to call, and the gateway's job is to make sure that whatever it decides stays inside rules you set.
If you know the path, draw it in n8n. If you cannot draw it — because it depends on what a support email says, or on what the last lookup returned — then you want an agent, and the question becomes what stops that agent doing something you did not intend.
Self-hosting is n8n's real advantage
Worth stating clearly, because it is the thing that actually wins them deployments: n8n runs on your infrastructure. Credentials never leave it, data never transits a third party, and there is no vendor who can be down on your behalf.
Spinrun is hosted. If that is disqualifying for you — a compliance requirement, a data residency rule, an air-gapped environment — then this comparison is over and n8n is your answer. We are not going to argue you out of a constraint.
What you get for accepting a hosted gateway
Permissions that are enforced rather than drawn. Every tool is classified read, write or destructive from the verb in its name, and you set a rule per app — two states, allow or block. The check runs at the gateway on every call, before anything reaches the vendor, and blocked tools are never even offered to the agent.
In a workflow engine, safety comes from the fact that you drew the graph. With an agent there is no graph, so safety has to come from somewhere else, and a prompt is not somewhere else — it is an input competing with every other input.
Credentials you never handle. Connect an app through its own consent screen and the authorisation goes into an encrypted vault. No token in an environment variable, no refresh loop to write, no rotation to remember. That work does not disappear when you self-host; it just becomes yours.
Per-person attribution. Clients that can open a browser authorise as you, so every logged call carries a name, and membership is re-checked on every call — remove a person and their agent stops on its next request.
An audit trail of decisions, not runs. Which tool, which arguments, which outcome, which connection, which client, as whom. That is what you need when an agent did something surprising, and it is a different artefact from a workflow run history.
Tool-list economics. Many connected apps means many tool definitions, and every one costs context on every request. Compact mode stops sending the list and gives the agent free search instead. That problem does not exist in a workflow engine, which is exactly why a workflow engine has no answer for it.
Side by side
| n8n | Spinrun | |
|---|---|---|
| Model | Workflow graph you draw | Tools an agent chooses from |
| Hosting | Self-hosted or cloud | Hosted |
| Data path | Your infrastructure, if self-hosted | Through the gateway |
| Credentials | Yours to store and rotate | Encrypted vault, refreshed for you |
| Safety comes from | The graph being explicit | Rules enforced on every call |
| Blocked actions | Not applicable — you drew it | Hidden from the agent and refused |
| Attribution | Per credential | Per person, re-checked per call |
| Unstructured input | Needs an AI node | The default case |
| Cost shape | Infrastructure you run | Metered by what agents actually do |
The combination that actually works
These compose, and the composition is better than either alone.
Let n8n own the deterministic spine — the trigger, the routing, the steps that must run identically every time and must be auditable as a drawing. Let an agent own the one step in the middle that needs judgement, reaching your apps through a gateway that enforces what it may do.
New ticket arrives (n8n), agent reads it and decides category and severity (Spinrun tools), route and notify accordingly (n8n). You pay for inference only on the step that needed it, and the risky part of the agent's reach is bounded by rules rather than by hope.
Next
- MCP vs workflow automation — the general form of this line
- Managed MCP gateway vs running your own MCP servers
- Agent permissions belong at the gateway