Most n8n problems are not the workflow. They are the server nobody owns, the upgrade nobody planned, and the execution that failed at three in the morning with nobody watching. We build the workflows and take the instance off your hands.
Built against the tools you already pay for
The billing model is what pulls most people over. n8n counts one execution per workflow run, no matter how many nodes are in it or how much data goes through. A twelve step workflow costs exactly what a two step one costs. On a per-task tool the same job is billed twelve times, so the gap widens precisely as your workflows get more useful, which is the opposite of what you want from a pricing page.
What the pricing page cannot show you is the second bill. A self-hosted instance is a server somebody has to patch, a Postgres database that fills with execution history unless pruning is configured, and an encryption key that makes every stored credential permanently unreadable if it is ever lost. n8n ships a minor release most weeks. Version 2.0 changed how Code nodes are executed and turned the Execute Command and Local File Trigger nodes off by default, which is the sort of change that breaks a working instance on a Tuesday morning.
The tool is not the hard part. Somebody has to decide whether you self-host or pay for cloud, build workflows so a failed run is visible instead of silent, and be there the week an upgrade changes behaviour. That is the work we do, and it is the half most people underestimate.
We work out which you actually need before building anything, because self-hosting only pays off once the maintenance is somebody’s job. If your volume is modest and nobody on your team wants a server to look after, n8n Cloud is the cheaper answer once your own time is priced in.
n8n passes arrays of items between nodes and runs most nodes once per item, which is where workflows quietly duplicate or drop records. We build with that in mind and keep item linking intact, so a node at the end can still trace a value back to the row it came from.
The default setup runs the editor, the triggers and every execution in one process, which holds up until a long job starts blocking everything behind it. We move you to queue mode with Redis, Postgres and separate worker containers, sized to your real concurrency rather than a guess.
Every production run writes its data into the n8n database, and an instance nobody has configured will eventually fill its disk. We set retention deliberately, choose what is kept on success versus on error, and leave enough history to debug a failure without hoarding everything forever.
Where the visual nodes get ugly, one JavaScript Code node is usually cleaner and cheaper to maintain than eight chained Set and IF nodes. We use them sparingly and document them, and we will say early if your idea needs Python, because the Code node runs Python through Pyodide and cannot simply pip install an arbitrary library.
n8n has no node for plenty of the systems small businesses actually run, so a niche or regional tool usually means an HTTP Request node written against the raw API. We build those with pagination, retries, rate limits and token refresh handled properly, so they behave like a real node instead of a demo.
It depends on whether anybody is going to own the server, not on the sticker price. Self-hosting removes the per-execution bill, and at high volume that gap gets large, but you inherit patching, backups, Postgres and an encryption key that has to live somewhere other than the same disk as the database. n8n Cloud removes all of that and handles upgrades for you, in exchange for a monthly execution quota, a cap on how many runs can happen at once, and a fixed window before execution history is deleted. Our rule of thumb: if your volume is modest and your workflows are not touching sensitive records, start on cloud and move later. If you are running real volume, or handling client data you would rather keep inside your own boundary, self-host and let us maintain it.
For almost every business the answer is: use it freely, including commercially, inside your own company. n8n is not open source in the strict sense. It is published under the Sustainable Use License, which permits use and modification for your own internal business purposes, and permits firms like us to charge for building and supporting it. What it does not permit is reselling n8n itself, so hosting it for your own customers as a paid service or white-labelling it into a product you sell needs a separate commercial agreement with n8n. If that is your plan we will tell you before quoting rather than after.
Most small businesses do not need it, and we will not sell it to you if you do not. The default setup runs everything in one process, which is fine for a few hundred short runs a day. You need queue mode when executions start overlapping and blocking each other: slow third-party APIs, large file handling, or a webhook that arrives in bursts. That means Redis for the queue, Postgres instead of SQLite, and separate worker containers, which is a genuine step up in operational complexity rather than a setting you flip. One thing worth knowing before you get there: once you are in queue mode, community nodes have to be installed manually rather than through the editor.
Because of how n8n counts, and it catches almost everybody once. A Schedule Trigger burns an execution every time it fires, whether or not there was anything to process, so a workflow polling every minute costs the same on a quiet Sunday as on a busy Monday. A Webhook Trigger counts every inbound request that reaches it, including empty ones. Polling trigger nodes are gentler and only count when they find new data. The usual fixes are to move from schedules to webhooks where the source supports them, widen the interval on anything that is checking rather than doing, and pull small workflows into a parent, since sub-workflows called by another workflow do not add to the count.
Three things, and you should hear them before you commit. Its node library is far smaller than Zapier’s, so a niche or regional tool often has no native node and becomes an HTTP Request node that we write and then have to maintain whenever that vendor changes their API. Its data model takes real effort to learn, because nodes pass arrays of items and run once per item, and item linking breaks quietly inside Code nodes and some sub-workflow calls, which produces workflows that look correct while pairing the wrong records. And on the free community edition everyone who can log in shares one workspace, with git-based version control, role permissions and separate development and production environments all sitting behind the paid tiers, so you are editing live workflows in place. None of that makes n8n the wrong choice. It does mean it rewards being set up properly and punishes being left alone.
Yes, and it is a common way clients start with us. We begin with an audit: what is actually active, what is duplicated, which workflows have no error handling, and whether the credentials and the encryption key are backed up anywhere other than the server itself. Inherited instances tend to have the same faults, which are retention never configured so the database is bloated, no error workflow set so failures go unnoticed, and a version old enough that upgrading is no longer a single step. We will tell you honestly whether a workflow is worth repairing or rebuilding. We do not need to have built something to maintain it.
Minor releases arrive most weeks and are usually uneventful. Major versions are the ones that need planning, and 2.0 is the fair example: task runners became the default way Code nodes execute and moved out of the main Docker image for external mode, and the Execute Command and Local File Trigger nodes were disabled by default. Most of that is a sensible security improvement, but an instance that pulls the latest image unattended can come back with workflows that no longer run. We pin versions rather than tracking latest, test an upgrade against a copy of your instance first, and read the release notes so you do not have to.
Send us your n8n instance, or just the list of jobs your team still does by hand. We will tell you what is worth building, whether self-hosting is right for you, and what maintaining it actually involves.
Book a Free Demo