Three reasons, and any one of them can decide it.<\/p>\n
Data residency.<\/strong> If customer data cannot leave your network, a cloud automation tool is not an option. This settles it outright for some businesses.<\/p>\n Internal systems.<\/strong> If your workflows connect to a database or an application not exposed to the internet, self-hosting is far simpler \u2014 the tool runs inside your network and reaches them directly.<\/p>\n Cost at volume.<\/strong> Cloud automation is typically priced per task or operation. A workflow processing every order every day adds up. Self-hosted, you pay for a server and the cost does not rise with usage.<\/p>\n Against that:<\/strong> somebody has to run it. That is the whole trade-off.<\/p>\n Not a one-time setup. An ongoing job.<\/p>\n The server.<\/strong> Keeping it up, and sized appropriately.<\/p>\n Updates.<\/strong> N8N releases regularly, including security fixes.<\/p>\n Backups.<\/strong> The database holding your workflows and credentials. And testing that they restore<\/strong> \u2014 an untested backup is not a backup.<\/p>\n Monitoring.<\/strong> Knowing when the service stops. Not “somebody will notice”.<\/p>\n Debugging.<\/strong> When something breaks at an inconvenient time.<\/p>\n If nobody in your company does this today<\/strong>, the licence saving is not a saving. You are trading a predictable subscription for an unpredictable cost that arrives as an incident.<\/p>\n If you already run servers<\/strong>, the marginal cost is small and self-hosting makes obvious sense.<\/p>\n FIGURE 1: WHAT SELF-HOSTING COMMITS YOU TO<\/p>\n The server<\/p>\n Updates<\/p>\n Backups you have tested<\/p>\n Monitoring<\/p>\n Most self-hosted N8N runs in Docker<\/strong> \u2014 a container holding the application and everything it needs.<\/p>\n Why that is the sensible default:<\/strong><\/p>\n Consistent.<\/strong> The same container behaves the same way on any machine.<\/p>\n Clean upgrades.<\/strong> Pull a new image, restart. No dependency conflicts.<\/p>\n Easy rollback.<\/strong> If a new version misbehaves, run the previous image.<\/p>\n Portable.<\/strong> Moving to a different server is straightforward.<\/p>\n What you need alongside it:<\/strong><\/p>\n A database.<\/strong> N8N stores workflows, credentials and execution history. PostgreSQL for anything beyond experimentation.<\/p>\n Persistent storage.<\/strong> So data survives a container restart.<\/p>\n A reverse proxy<\/strong> with HTTPS in front of it.<\/p>\n A backup routine<\/strong> covering the database.<\/p>\n If your workflows receive webhooks \u2014 and most useful ones do \u2014 the instance needs to be reachable from the internet.<\/p>\n Which means:<\/strong><\/p>\n A domain name<\/strong> pointing at it.<\/p>\n HTTPS<\/strong>, with a certificate that stays valid.<\/p>\n A reverse proxy<\/strong> handling the traffic.<\/p>\n And this is where care is needed.<\/strong> An automation platform holding credentials to your ERP, your e-commerce store and your messaging accounts is a valuable target.<\/p>\n Four things that matter:<\/strong><\/p>\n Strong authentication<\/strong> on the N8N interface itself.<\/p>\n Only the webhook path exposed<\/strong> where possible, rather than the whole interface.<\/p>\n Updates applied promptly<\/strong>, particularly security ones.<\/p>\n Credentials scoped narrowly<\/strong> \u2014 each integration account with the minimum access it needs.<\/p>\n FIGURE 2: A SELF-HOSTED INSTANCE THAT IS LOOKED AFTER<\/p>\n Well run<\/p>\n A liability<\/p>\n Once workflows matter, you want more than one instance.<\/p>\n Production.<\/strong> The live one your business depends on.<\/p>\n Staging or test.<\/strong> Where you build and test changes.<\/p>\n Why it matters:<\/strong> a workflow being built will fail, loop, and send test messages. You do not want that happening against live systems<\/strong> \u2014 real customers receiving test notifications, or test records appearing in your ERP.<\/p>\n Two practices:<\/strong><\/p>\n Build in test first.<\/strong> Move to production when it works.<\/p>\n Point test workflows at test systems.<\/strong> Not your live ERP.<\/p>\n N8N stores credentials encrypted, separately from workflows.<\/p>\n Four habits:<\/strong><\/p>\n A dedicated account per integration.<\/strong> Not a real person’s login \u2014 when they leave, the workflow should not break.<\/p>\n Minimum permissions.<\/strong> A workflow that only reads orders should not be able to delete them.<\/p>\n API keys rather than passwords<\/strong> where the target system supports them. Revocable individually, and they survive two-factor authentication being enabled.<\/p>\n Documented.<\/strong> Which workflow uses which account, and who owns it.<\/p>\n Worth being specific, because this is the thing people get wrong.<\/p>\n What to back up:<\/strong> the database. It holds your workflows, credentials and execution history.<\/p>\n How often:<\/strong> at least daily if workflows change regularly.<\/p>\n Where:<\/strong> somewhere other than the server running N8N. A backup on the same machine does not survive the machine.<\/p>\n And test a restore.<\/strong> Quarterly. Restore into a separate instance, open it, check the workflows are there and the credentials work.<\/p>\n FIGURE 3: SETTING IT UP PROPERLY<\/p>\n Docker plus a database<\/p>\n HTTPS and strong auth<\/p>\n Backups, tested<\/p>\n Monitoring and an owner<\/p>\n Be honest about this.<\/p>\n No server operations today.<\/strong> If nobody runs servers, the maintenance burden outweighs the licence saving.<\/p>\n Low volume.<\/strong> Per-task pricing is cheap at low volume, and you get reliability somebody else maintains.<\/p>\n No data residency requirement.<\/strong> If the data can leave, one reason to self-host disappears.<\/p>\n A reasonable path for most businesses:<\/strong> start on cloud, run real workflows for two or three months, then decide with actual numbers rather than a guess.<\/p>\n Self-hosting gives you data control, internal system access, and cost that does not rise with usage.<\/strong><\/p>\n It costs you a real ongoing job<\/strong> \u2014 server, updates, backups, monitoring, and somebody available when it breaks.<\/p>\n Docker with a proper database is the sensible setup.<\/strong> HTTPS, strong authentication, narrowly scoped credentials, and backups you have actually restored.<\/p>\n And keep a separate instance for building, so half-finished workflows never touch live systems.<\/p>\n Considering self-hosting your automation platform?<\/p>\n Get in touch. We run self-hosted n8n in production \u2014 and we will tell you honestly whether the maintenance burden outweighs the saving for your size.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":" Why self-host Three reasons, and any one of them can decide it. Data residency. If customer data cannot leave your network, a cloud automation tool is not an option. This settles it outright for some businesses. Internal systems. If your workflows connect to a database or an application not exposed to the internet, self-hosting is […]<\/p>\n","protected":false},"author":3,"featured_media":9269,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[28],"tags":[],"class_list":["post-9268","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-n8n"],"yoast_head":"\nWhat running it involves<\/h2>\n
\n
\n
\n
\n
Docker<\/h2>\n
Making it reachable<\/h2>\n
\n
\n
Environments<\/h2>\n
Credentials<\/h2>\n
Backups<\/h2>\n
\n
\n
\n
\n
When cloud is the better answer<\/h2>\n
The short version<\/h2>\n