How to self host n8n, and what it costs you in hours

Your n8n container fills its disk at 02:40 and stops answering. Shopify keeps sending order webhooks. It retries each failed delivery up to eight times inside a four hour window, then removes the subscription if the failures persist. By 09:00 those orders sit in Shopify and nowhere else, and nothing in your stack knows which ones are missing.

A webhook is a message one system sends another the second something happens, such as an order being paid. Self host n8n and you own the machine that has to be awake to catch it. That is the real decision, and it is not a decision about software.

This guide is for the operator who owns the orders, not the person shopping for a tool

n8n is a workflow automation tool. You draw a sequence of steps in a browser, and a server runs that sequence whenever a trigger fires. n8n Cloud is that server, run by n8n. Self-hosted n8n is the same software on a machine you rent or own.

You are the reader here if orders leave Shopify and get re-keyed into an ERP by hand. An ERP is the system that holds your stock, purchasing and accounting records. The same applies if stock counts drift between two systems. Or if pricing rules sit in three different apps. You already own the problem. The open question is who owns the fix at 02:40 on a Saturday.

Two readers should stop here. If nobody on your team has restarted a Linux server before, stay on n8n Cloud. n8n’s own comparison is blunt: self-hosting requires technical expertise for installation and configuration, and maintenance becomes your responsibility (n8n docs, Choose how to use n8n, checked 21 September 2026). The second reader is anyone planning to host n8n for clients and bill them for access. The licence blocks that, and the next section explains why.

Deciding who owns the box after go-live is the same handover question that sits under every ecommerce operations engagement. The software is the cheap part. The ownership is not.

The Community edition really is free, and the licence is the limit

Self-hosted n8n runs as the free Community edition when no licence key is present. Registering your email unlocks a little more at no cost: folders, debug in editor, and custom execution data. A Business or Enterprise key unlocks the paid set, which includes single sign-on, environments, projects, external secrets, log streaming and Git version control.

Queue mode is not in that paid set. That matters, because queue mode is how a self-hosted instance scales, and you get it for free.

The limit is legal, not technical. n8n ships under the Sustainable Use License, Version 1.0. It reads: “You may use or modify the software only for your own internal business purposes or for non-commercial or personal use” (LICENSE.md, read 21 September 2026). The licence FAQ names the two things it refuses: white-labelling n8n, and hosting n8n and charging people for access. Syncing your own company data is allowed, and so is charging clients to build their workflows.

One more thing to know before a procurement conversation. n8n does not call itself open source, because the Open Source Initiative definition does not allow limitations on use.

Four gigabytes of RAM starts n8n; Postgres and Redis are what keep it running

n8n’s Docker Compose guide asks for at least 4 GB of RAM and 2 vCPUs. That is the floor, not the target. The editor answers on port 5678, and the default database is SQLite, a single file on disk.

SQLite is fine while you are trying things. n8n says to use Postgres instead for a production instance handling more than a handful of users or workflows running around the clock. Postgres is a separate database service that runs alongside n8n.

Queue mode is the next step up. One main instance catches triggers, Redis holds the queue, and separate worker containers run the executions. Redis is an in-memory message broker: it is the list of jobs waiting to be picked up. n8n does not recommend queue mode on SQLite, so Postgres comes first.

Sources: n8n, Install using Docker Compose, n8n, Measure performance and n8n, Manage execution data, all fetched 21 September 2026.

Read the last two rows again. Pruning deletes finished executions on a schedule, and it is on by default. If you turn it off to keep an audit trail, the database grows until the disk fills. On SQLite, pruned space is reused rather than returned, so the file does not shrink on its own.

Setup takes one evening; upkeep is the part nobody prices

Installing n8n is genuinely quick. There is a one-line installer, and Docker Compose is the documented path for production. That evening is not the cost you should be budgeting.

n8n’s release notes list 43 releases dated in 2026, from version 2.3 on 5 January to 2.40 on 15 September. That is close to one a week. You do not have to take every one, but you cannot ignore the stream either.

A major version is already scheduled. n8n 3.0 is due in October 2026, and self-hosted n8n will then require a Docker-based deployment: installs run with npm or npx n8n stop being supported. Legacy Function and Function Item nodes are removed in the same release.

Backups are where most self-hosters find out they were not backed up. The CLI export with --backup writes workflows and credentials only. It does not include users and their roles, execution history, variables, or instance settings, and that includes the encryption key. Without the encryption key, a restored database cannot decrypt a single credential.

Source: n8n, Release notes, n8n, v3.0 Breaking changes and n8n, Back up and restore, all fetched 21 September 2026.

What breaks first is the thing nobody is watching

A self-hosted instance rarely fails loudly. It fails quietly, and Shopify’s retry policy decides how much that silence costs.

Shopify retries a failed webhook delivery up to eight times inside a four hour period, and removes the subscription if failures persist. After repeated failures inside a 24 hour period, that subscription is gone. Your endpoint also has five seconds to answer, or the delivery counts as failed (Shopify developer docs, Troubleshoot webhooks, fetched 21 September 2026).

Put those numbers together and the ownership question answers itself. A four hour outage is recoverable. A removed subscription is not self-healing: somebody has to notice, recreate it, and then backfill the orders that never arrived. Nobody gets an alert for orders that were never delivered.

We have paid this bill on our own systems, not a client’s. On our SafaiKaro site, a deploy hung on 6 August 2026 and nothing flagged it.

The fix was not a bigger server. It was a weekly routine that compares the live site against the repository and reports deployment health, which is the pattern described in the SafaiKaro growth routine. Apply the same idea to n8n: a scheduled workflow that pings a health endpoint, and a separate alert that fires when a Shopify webhook subscription disappears.

Ownership splits cleanly once you write it down. You own the server, the disk, the upgrade window and the restore drill. n8n owns the software and its release cadence. Shopify owns the retry policy, and it will not wait for you.

Autonomous is a Shopify systems and operations agency. We build the integrations behind Shopify and Shopify Plus stores, then run them: order and inventory syncs, ERP handoffs, and the monitoring that says when one has stopped. The people we work with are founders and operators accountable for the store after launch, not the team that shipped it. That is why the handover document matters here more than the install command.

Coverage is not your constraint. The n8n documentation sitemap listed 311 built-in app nodes and 105 trigger nodes on 21 September 2026, Shopify among them. Attention is the constraint.