Direct answer. Keep a workflow in n8n while it's mostly glue: triggers, schedules and calls between apps. Move the logic into code when a mistake would cost real money, when you need tests and code review, or when the canvas grows past what one person can read. Most teams end up with both: n8n calls a small service.
This is for ops and engineering leads on teams of 3 to 20 and 20 to 100 that already run n8n, self-hosted or Cloud. One workflow has started to feel fragile. Should it stay on the canvas, or become code?
Our answer: usually neither extreme. Most teams should split, not migrate. Below is the checklist we run on one workflow at a time, what we'd never move, and how to move the part that needs it.
Where n8n is the right tool
n8n is good at the work around the logic. We keep it, and recommend it, for:
- Connecting apps. Ready-made nodes and stored credentials for the tools you already use.
- Webhooks and schedules. Triggers are configuration, not code.
- Prototypes. You learn what the workflow should do before anyone writes a spec.
- Workflows non-developers edit. An ops lead can change a Slack message without a deploy.
- Visibility. Past executions are listed with their data, and an error workflow can alert you when one fails.
Still choosing a tool? Start with n8n vs Zapier or n8n vs Make. Want to run it yourself? See our n8n self-hosted guide. Coming from Zapier instead? That's a different question, covered in Zapier vs custom automation.
The 7-signal checklist
Pick one workflow. Read the seven signals. Count the ones that are true today, not the ones that might be true next year.
1. You can't test the logic that matters
In n8n, testing logic mostly means running the workflow, often with pinned or mocked data. That works for glue. It's thin for a pricing rule, an approval limit, or anything that moves money.
What it looks like: someone changes a condition, runs it once by hand, and publishes.
2. Changes aren't reviewed
Git-backed source control and environments are on n8n's Business and Enterprise plans. Workflow reviews, with a visual diff and an approver, are Enterprise only and still in Preview. On other setups, a change can be published straight from the editor.
What it looks like: nobody can say who changed the routing rule, or why.
3. The Code node is doing the real work
A few lines of mapping in a Code node is fine. Long JavaScript or Python blocks are an app without tests, hiding inside a workflow. They're also hard to diff and hard to reuse.
What it looks like: the canvas is short, but one node holds most of the business rules.
4. You need libraries the runner won't give you
On n8n Cloud, the JavaScript Code node can't import external npm modules. You get crypto and moment. Native Python on Cloud can't import any libraries, not even the standard library. Self-hosted can, but you extend the n8nio/runners image and allowlist each package (Code node docs, task runners).
What it looks like: you maintain a custom Docker image to get one parsing library into one node.
5. The logic needs memory or locks
Some rules depend on earlier runs: has this lead already been routed? Others break when two runs touch the same record at once. You can patch this with lookups and flags. A service with its own database handles it directly.
What it looks like: duplicates appear when two webhooks arrive close together.
6. You're scaling n8n for one workflow
Queue mode, with Redis, Postgres and workers, is the right way to scale n8n. But if you're tuning all of that to keep a single workflow fast, that workflow probably wants to be a service.
What it looks like: the infrastructure work is about one workflow, not the whole instance.
7. Your customers would build or configure the workflows
The free self-hosted Community license lets you run automations you built behind your product. Your users can trigger them and even connect their own accounts. It doesn't let external users build or configure workflow logic, whether through a custom UI, the API, MCP or an AI agent. That needs a commercial license (n8n license FAQ).
What it looks like: the roadmap has a "customers create their own rules" feature, built on n8n.
Score it. 0–1 signals: keep it in n8n. 2–3: split the logic out. 4 or more, or signal 7 on its own: plan a move.
The split that works for most teams
Most workflows that fail the checklist don't need a rewrite. They need one piece moved.
n8n keeps the trigger, the SaaS credentials and the alerting. One HTTP Request node calls your service. The service holds the business rules. It has tests, lives in Git and goes through code review like any other code.
Two details make this hold up. First, set an error workflow. It starts with the Error Trigger and can post failures to Slack. One error workflow can cover many workflows. Second, protect the endpoint n8n calls. Authenticate every request, as in our webhook security guide.
For an example of routing rules living in code, see how to build a Slack bot that routes Jira tickets.
What we would not move out of n8n
We'd tell you to keep these on the canvas:
- One-step syncs between two apps.
- Notifications and alerts.
- Schedules that just call an API.
- Anything a non-developer edits every week.
- Prototypes still proving they're worth keeping.
Moving these adds a deploy pipeline and buys you nothing.
How to move one workflow safely
- List the inputs and outputs. Take a week of executions. Write down what came in and what went out.
- Write tests from those real examples. They become the definition of "works".
- Build the service and run it in shadow mode. n8n stays live. The service gets the same inputs, and you compare outputs.
- Switch the node. Point the HTTP Request node at the service. Triggers and alerts don't change.
- Unpublish the old workflow, don't delete it. Keep it for a couple of weeks. Rolling back is one click.
n8n workflow vs custom service
| n8n workflow | Custom service | |
|---|---|---|
| Setup speed | Fast for connecting apps. Mostly configuration | Slower to start. You write, host and deploy it |
| Ready-made connectors | Built-in nodes and stored credentials | You call each API yourself |
| Testing | Run the workflow, with pinned or mocked data | Unit and integration tests in CI |
| Review and rollback | Source control on Business and Enterprise. Reviews on Enterprise (Preview). Versions from the last 24 hours on every plan | Pull requests and full Git history |
| Libraries | Cloud: crypto and moment in JavaScript, no Python imports. Self-hosted: extend the runners image and allowlist |
Any library your language supports |
| Scaling | Queue mode with Redis, Postgres and workers, for the whole instance | Scales on its own, like your other services |
| Who can edit | Anyone with editor access, including non-developers | Developers, through review |
| Licensing limits | Self-hosted Community license: external users can't build or configure workflows | Your code, your terms |
FAQ
Is n8n good enough for production?
Yes, for integration and orchestration work. Self-host it with task runners in external mode and, at volume, queue mode. The risk isn't n8n itself. It's logic that matters but has no tests and no review. Keep that logic in code, and let n8n handle triggers, connectors and alerts around it.
Can n8n run Python?
Yes. Native Python in the Code node runs through task runners and is stable as of n8n 2. On n8n Cloud it can't import libraries, not even the standard library. Self-hosted can, if you add the packages to the n8nio/runners image and allowlist them in the runner config.
Should we rewrite everything in Python?
Usually no. Move the logic that needs tests and review into a small service, and keep n8n for triggers and connectors. Rewrite fully only when most of the workflow is logic, or when the license or scaling pushes you out. A full rewrite also means rebuilding every connector n8n gave you.
Can we put n8n inside our SaaS product?
You can run automations you built behind your product, and your users can trigger them and connect their own accounts. Letting customers build or configure workflows, through any UI, API or AI agent, needs a commercial license from n8n. This is the self-hosted Community license. n8n Cloud has its own terms.
How do we version-control n8n workflows?
Git-backed source control and environments are on n8n's Business and Enterprise plans. On other plans, teams export workflow JSON, from the editor, the CLI or the n8n API, and commit it to Git with a script. Exports include credential names, so check them before the files go anywhere shared.
Is n8n or custom code cheaper?
It depends on your volume, your team and how often the logic changes, so we won't give a number here. Work it out for one workflow with the method in our automation ROI guide. For build-versus-maintain costs, see the TCO section of no-code vs custom development.
Sources
- Using the Code node, for Cloud vs self-hosted imports and native Python
- Set up task runners
- Use source control and environments
- Review workflows and View change history
- Pin and mock data
- Handle errors gracefully
- Enable queue mode
- Export and import
- License FAQ
- n8n's own view: n8n vs Python
