n8n self-hosted, and run like the service it actually is
Workflow design and self-hosting on n8n, with the Code node used sparingly, credentials kept in the credential store, and the hosting, upgrade and restore work that self-hosting actually entails.
n8n sits closest to code of the mainstream workflow platforms. Nodes pass arrays of items, the HTTP Request node authenticates against stored credentials so a missing integration is rarely a wall, and where the visual nodes run out you drop into a Code node and work against the data directly. Self-hosted, execution is not metered, which is the whole argument at volume, and a genuinely large one when per-operation or per-task pricing has stopped tracking the value of the work.
The part that gets skipped is that you are now running a service. It needs a database, a backup that has been restored at least once, an upgrade path, a reverse proxy with the webhook URL set correctly, and somewhere to put the encryption key that every credential depends on. None of that is difficult. All of it is work, and it recurs.
It is also worth knowing what you are adopting: n8n ships under a sustainable-use licence rather than an open-source one, and some governance features sit in the paid tiers. Self-hosting the community edition is legitimate and common, and the licence is worth reading before it becomes load-bearing.
What we build on n8n
Workflows where the nodes carry the logic
Items in, items out, with Set nodes shaping the data so the next node's expressions stay short, Split In Batches for paging a large source, and Merge where two branches have to come back together. The Code node is used where it earns its place and carries a comment saying why, because every Code node is a piece of untested software living in a place with no review.
Credentials in the credential store, and a key that is backed up
Credentials belong in n8n's own store, never in a node's parameters, with separate credentials per environment so a test workflow cannot write to production. They are encrypted with a key held outside the database: lose it and every credential in the instance becomes unreadable and has to be re-entered by hand, which is the self-hosting failure people discover at the worst moment.
Executions you can read, and a database that stays small
An error workflow set globally so every failure lands somewhere a human sees, execution data pruned on a schedule, and successful executions saved only where they are genuinely diagnostic. Left at the defaults, execution history is the thing that fills the disk and slows the interface, and it does it quietly.
Hosting it so the upgrade is not an event
A container image pinned to a version rather than a moving tag, Postgres instead of the default SQLite for anything real, queue mode with workers where concurrency matters, and the webhook URL configured to the public address so triggers resolve correctly behind a proxy. Workflow JSON goes into version control, which is what makes rolling back an upgrade possible at all.
What goes wrong on n8n
The patterns that turn up on this platform specifically, and what we do about each one.
- 01
An upgrade that arrives on its own
Running the moving tag means the next restart can pull a version with a changed node and a workflow that no longer behaves the same. Pin the image, read the release notes for the nodes you use, upgrade deliberately in a staging instance first, and keep the workflow JSON committed so the previous version is recoverable rather than a memory.
- 02
SQLite quietly becoming the bottleneck
The default image is convenient and fine for evaluating. Under real traffic, execution records accumulate, the database grows, the editor gets slow, and a restore takes longer than anyone expects. We move to Postgres, turn on pruning with a retention period the business has actually agreed to, and stop saving successful executions where nobody has ever read one.
- 03
A backup that has never been restored
Backing up the database without the encryption key leaves credentials unrecoverable, which means the backup restores an instance that cannot run anything. Both get backed up, stored separately, and a restore is performed once into a scratch instance so the procedure is known rather than assumed. This is the single most common gap we find on an inherited self-hosted instance.
- 04
A workflow that has become a codebase
Code nodes accumulate until a workflow holds hundreds of lines of one person's JavaScript with no tests, no review and no way to run it locally. At that point it is software pretending to be configuration. Either the logic moves into a small service with tests and a deploy path, or the Code nodes get cut back to transformations and the workflow JSON is treated as source that gets reviewed like any other.
Where n8n is the wrong answer
n8n is the wrong answer for a business with no engineering capacity. Self-hosting trades a licence for an operational burden (patching, upgrades, backups, the encryption key, and being the only person on call when a webhook stops responding at two in the morning), and that is a fair trade for a technical team and a poor one without. If the appeal is the cost model rather than the control, n8n Cloud reintroduces metering on executions rather than steps, which is often still cheaper, and Make remains the better answer where the work needs branching and transformation but nobody wants to run a server. We would also say plainly that if the real driver is one expensive scenario, moving that scenario is a smaller project than adopting a platform.
Projects that did not use n8n
Here for the argument rather than as evidence of n8n work. Each one bears on a decision above, and the note says which.
- Blueprint RunnerBlueprint Runner: a self-hosted engine that speaks Make nativelyNot an n8n build. It reaches the same destination from the other direction, keeping Make's logic and dropping the per-operation meter (Make now bills in credits) by executing the blueprint on infrastructure you control.Case study
- FlowForgeFlowForge: a workflow builder with cron, webhooks and run historyNot an n8n build. It is our own workflow runner on serverless infrastructure, and it is where the practical constraints of self-hosting (scheduling, background execution, a secrets store the scheduler can reach) were worked out in detail.Case study
The disciplines behind it
Related reading
n8n, specifically
Self-host if you have someone who already runs services and the volume makes metered execution painful. Use the cloud version if you want the platform without the operational work; it still bills per execution rather than per step, which is usually the saving people are actually after. The deciding question is not the licence fee, it is who patches it.
Three things, only one of which is money: a small server and a managed Postgres instance, backup storage, and recurring hours for upgrades, monitoring and the occasional restore. The hours are the variable that surprises people, because they are not spent evenly: they arrive as an afternoon when an upgrade changes a node's behaviour. We would rather scope those in than pretend the hosting is free because the software is.
Not in the strict sense. It ships under a sustainable-use licence, which permits self-hosting and internal use but restricts offering it as a competing hosted service, and some governance features sit in the paid tiers. For most businesses that distinction changes nothing practical, but it is worth knowing before the platform becomes load-bearing.
Technically, for most workloads, yes, particularly self-hosted, where execution is not metered. The trade-offs are connector breadth and operational burden. In practice we most often see it take the high-volume workloads while simpler automations stay where non-technical staff can maintain them, which is a reasonable place to land rather than a compromise.
Nobody else is on call, which is the honest difference from a hosted platform. The mitigations are a container restart policy, an uptime check against the health endpoint that alerts a person rather than a dashboard, an error workflow catching failures inside n8n itself, and a documented restore. Those are cheap to set up and are the difference between an outage and a week of missing records.
Page copy drafted with AI assistance. Skofi is accountable for it. Editorial policy
Tell us about the process that keeps costing you.
A 15-minute call is usually enough to say whether this is an automation, an integration, or something that should be built, and whether we are the right people for it.
What happens on the call
- 15 minutes, no deck
- We map the process on the call
- A written scope, or an honest no