How to Run Claude Code and n8n Together for Your Business

How do you run Claude Code and n8n together?

You run Claude Code and n8n together by letting each do the job it is built for: Claude Code builds the custom logic - the script, the tool, the piece that has to make a decision or transform data in a way no off-the-shelf node covers - and n8n runs that logic on a schedule and wires it into your other apps. In practice, you build a small script or tool with Claude Code from the desktop app, then set up an n8n workflow that calls it whenever a trigger fires. The trigger can be a new email, a submitted form, a row added to a sheet, or simply a time of day.

The reason this pairing works is that the two tools are strong exactly where the other is weak. n8n is excellent at connecting apps, waiting for events, and running the same flow reliably a thousand times, but it is not the place to write complex, one-off business logic. Claude Code is excellent at writing that logic and building custom tools fast, but it is not a scheduler that sits running in the background. Put the thinking in Claude Code and the running in n8n, and the whole automation gets simpler.

Why use both instead of just one?

You use both because a single tool always ends up doing something it is bad at. If you try to run everything in n8n, you hit a wall the moment a step needs real logic - parsing a messy email, deciding which of five paths a lead should take, rewriting content to a specific format. You can force it with a chain of nodes, but it becomes brittle and hard to change. If you try to run everything in Claude Code, you end up with a smart script that only works when you are sitting there to run it, because it was never meant to wait for events or run on a timer.

Split the work along that table and each tool does only what it is good at. That is not a compromise - it is the setup that stays maintainable. When the logic needs to change, you edit the Claude Code side without touching the plumbing. When the schedule or the apps change, you edit the n8n side without rewriting the logic. [How to automate your business with n8n](/blog/how-to-automate-your-business-with-n8n) covers the n8n half in depth.

What is the Build vs Run Split?

The Build vs Run Split is our rule for dividing any automation into two halves: the build half, which is the custom logic and tools, goes to Claude Code, and the run half, which is the schedule and the app connections, goes to n8n. Before you touch either tool, you draw the line down the middle of the workflow. Everything that requires a decision, a transformation, or a custom piece of code sits on the build side. Everything that requires waiting, triggering, or moving data between apps sits on the run side.

1. Write down the workflow in plain English, start to finish, as a list of steps.
2. Mark each step build or run. A step is build if it needs a decision or custom logic; it is run if it just waits, triggers, or moves data.
3. Give every build step to Claude Code - have it write the script or tool for that step, and test it on its own first.
4. Give every run step to n8n - set the trigger, the schedule, and the app connections, and have n8n call the Claude Code piece where a build step sits in the chain.
5. Run the whole thing end to end read-only once, so you confirm the handoff works before it touches anything live.

The Split does one job well: it stops you from asking a tool to be something it is not. Most automation frustration traces back to a wiring tool being asked to think or a thinking tool being asked to wait. Draw the line first and the tool choice for each step becomes obvious, which is the whole point.

How do you connect the two in practice?

You connect them by having n8n call the tool Claude Code built. The most common pattern is simple: Claude Code builds a small script or a lightweight endpoint that takes some input and returns a result, and n8n runs that on a trigger, passing in the data and using what comes back in the next step. You describe the handoff to Claude Code in plain English from the desktop app - what input the script will receive and what it should return - and it writes the piece that fits that shape.

You do not need to be technical to wire this up. The desktop app means you are not managing a terminal setup, and n8n's interface is visual. The one thing to get right is the contract between them: n8n needs to know exactly what to send and what it will get back. Define that in one sentence before you build, and the connection is the easy part. [How to use Claude Code for your business](/blog/how-to-use-claude-code-for-your-business) walks through getting started from the desktop app.

What should you build first?

Build the smallest automation that saves you a real, repeated task - one trigger, one logic step, one action - before you attempt anything larger. A good first project is something you already do by hand every day or every week: sorting incoming email, turning a form submission into a formatted record, or producing a short daily summary from data you already have. Pick one, apply the Build vs Run Split, and ship it end to end.

The value of starting small is that you learn the handoff on something low-stakes. Once you have run one automation where Claude Code did the thinking and n8n did the running, the pattern is yours - every future workflow is a variation on it. Trying to build a sprawling multi-branch automation as your first project is how people end up with something fragile they are afraid to touch. One clean handoff first, then scale.