How To Self-host N8n: Complete Setup Guide

Zapier charges per task. n8n charges nothing for execution volume. That single difference can save a growing SME a meaningful amount once workflow volume crosses tens of thousands of executions monthly — and the savings tend to widen as you scale. Learning how to self-host n8n gives you control over your automation infrastructure while eliminating these per-task fees entirely.

Self-hosting n8n means deploying the open-source workflow automation tool on your own infrastructure so you avoid per-task fees, execution limits, and data leaving your hardware. Unlike Zapier or Make, self-hosting n8n means no per-task fees, no execution caps, and your credentials never leave your own servers, as Localtonet’s self-hosting guide notes. In practice, founders who escape the “Zapier tax” tend to reinvest those savings into actual product development.

This pillar guide walks through every method to self-host n8n — npm, Docker, and Docker Compose — plus security hardening, webhook configuration, backups, and AI agent integration. No fluff. No hand-waving. It explains which method fits which situation and where the common landmines hide.

Quick Summary: Key Takeaways on How To Self-host n8n

• Three installation methods exist: npm (fastest for testing), Docker (clean and isolated), and Docker Compose (production best practice). Docker Compose is recommended for any business-critical deployment.
• Cost savings come from the pricing model: Self-hosted n8n eliminates per-task billing entirely — at high monthly execution volumes the flat server cost can be a fraction of equivalent Zapier or Make plans.
• Two environment variables are non-negotiable: N8N_ENCRYPTION_KEY protects stored credentials, and WEBHOOK_URL makes external triggers (Stripe, GitHub) actually work.
• Without a license key, n8n runs as the free Community edition, according to n8n’s official hosting documentation — sufficient for the vast majority of SME automation needs.
• Security hardening is mandatory: HTTPS via reverse proxy, firewall rules, basic auth, and encryption key rotation separate a hobby project from a production system.
• AI integration is the multiplier: Self-hosted n8n connects directly to LLMs and custom agents, turning passive workflows into intelligent automation that reasons, not just routes.

Published: June 20, 2025. Last updated: June 2025. This guide is maintained against the current n8n hosting documentation; verify commands and version numbers against the official docs before deploying, as the project updates frequently.

About This Guide and Its Sourcing

This article is written from a hands-on, infrastructure-engineering perspective rather than a marketing one. Where it states a fact about n8n’s behaviour, licensing, or recommended deployment method, that claim is linked to a primary source — n8n’s own documentation, the n8n community forum, or DigitalOcean’s published tutorial — so you can verify it independently. Where it offers cost figures, those are presented as illustrative calculations based on published Zapier/Make pricing tiers and typical VPS pricing, not as guaranteed outcomes. Your actual savings depend on your task volume, workflow complexity, and how you value your own maintenance time. We flag the assumptions throughout so you can substitute your own numbers.

What Is n8n and Why Self-host It?

Applying how to self-host n8n delivers measurable results over time.

n8n is an open-source, node-based workflow automation platform that connects apps, APIs, databases, and AI models into automated pipelines — no full application code required. A node is a single reusable building block in a workflow (a trigger, an action, or a transformation), and workflows are chains of nodes that pass data from one to the next.

Self-hosting n8n means running the platform on infrastructure you control. Common options include:

• A VPS (entry-level droplets typically start around $4–$6/month on providers like Hetzner or DigitalOcean)
• A home server or NAS
• A Raspberry Pi 4 (4GB RAM or higher recommended)

Self-hosting delivers three key benefits:

1. Data privacy: Your workflow data never leaves your servers.
2. Cost control: Avoid per-execution fees charged by cloud automation tools.
3. Unlimited workflows: Run as many automations as your hardware allows.

n8n uses a “fair-code” license, which permits free self-hosting for internal business use. For teams running large volumes of monthly automations, self-hosting decouples cost from usage entirely compared to per-task SaaS platforms like Zapier.

The economics drive the decision. Zapier’s pricing scales with task volume, so a workflow firing 10,000 times a day becomes expensive quickly. Make (formerly Integromat) follows a similar operations-based model. Self-hosted n8n breaks that link: you pay for a server, and the server runs as many executions as its hardware allows. A modest cloud droplet can comfortably handle tens of thousands of executions monthly.

Data sovereignty matters just as much for many SMEs. When you self-host n8n, customer records, API keys, and proprietary logic stay on hardware you own. For businesses in regulated sectors — healthcare, finance, or EU operations bound by GDPR — that control isn’t a luxury. It’s a compliance lever.

The “Zapier Tax” in Concrete Numbers

The “Zapier tax” is the cost premium businesses pay for SaaS automation pricing versus self-hosted alternatives, which can be substantial at scale. Consider a worked example: an e-commerce startup syncing orders, sending receipts, and updating inventory at roughly 150,000 monthly operations.

Methodology for this example: Zapier and Make bill on task/operation volume, so a 150,000-operation workload lands on a mid-to-upper tier plan that, based on their published pricing pages, commonly exceeds several hundred dollars per month. The self-hosted equivalent runs on a small cloud server — for instance a 2-vCPU, 4GB droplet in the ~$20/month range — handling the same volume at a flat infrastructure cost. The gap between those two figures is the “tax.” Because Zapier’s cost scales roughly linearly with usage while infrastructure cost stays near-fixed, the delta grows as volume grows.

The important caveat: these are illustrative figures, not a promise. Validate the current Zapier or Make tier for your exact operation count against their live pricing pages, and add a realistic estimate of your own maintenance time (see the TCO section below) before concluding. A useful sanity check from the community is the recurring r/n8n thread where a beginner sought the cheapest way to run n8n locally without cloud or server costs — for the smallest workloads, the practical saving can be near-total because a local machine costs nothing extra to run.

Across sales, marketing, HR, and finance automations combined, the annual delta can reach five figures for mid-sized teams — but only after you offset it against operational responsibility, which is the honest other half of the equation.

Community Edition vs Business and Enterprise

n8n runs as the free Community edition by default, and adding a Business or Enterprise license key enables the paid editions, according to n8n’s official hosting documentation. The Community edition includes the full node library of integrations, unlimited workflows, and unlimited executions at no cost. Paid tiers add collaboration and governance features rather than removing core automation capability.

The key distinction is access control and scale. Business and Enterprise editions add features such as role-based access control (RBAC), Single Sign-On (SSO), environment management, and external secrets storage; Enterprise further enables log streaming, Git-based version control, and multiple isolated instances. As the documentation frames it, license keys enable the advanced editions rather than restricting the underlying engine.

For most self-hosting users, this means a single Community instance can run production-grade automation indefinitely without licensing fees. Teams typically upgrade when they need multi-user governance, audit logging, or compliance controls — not when they hit a workflow or execution limit, because those limits do not exist in the Community edition.

How To Self-host n8n: Which Installation Method Fits You?

Choosing the right installation method up front saves hours of rework later. There are three primary ways to self-host n8n: npm for quick local testing, Docker for clean isolated deployments, and Docker Compose for production-grade setups with a persistent database. Docker Compose is the best-practice choice for any business that depends on its automations, because it bundles n8n with PostgreSQL and persistent storage in a single reproducible configuration.

Choosing wrong wastes time. A founder who installs via npm on a laptop to “just try it” often discovers their workflows vanish on reboot. A team that jumps straight to a Kubernetes cluster for three simple automations has over-engineered a problem a single droplet solves. Match the method to the mission.

Here’s a practical decision framework.

DigitalOcean’s tutorial on setting up n8n walks through installing and configuring n8n on a self-hosted Ubuntu server using Docker Compose, precisely because that approach separates concerns cleanly and survives reboots, restarts, and updates without losing data. For anything you’d be upset to lose, Docker Compose is the safe default.

How Do You Self-host n8n With npm (The Fastest Start)?

how to self-host n8n is one of the most relevant trends shaping 2026.

To self-host n8n with npm, install Node.js version 18 or higher, then run a single global install command and launch n8n from your terminal. The npm method is the simplest way to self-host n8n and is ideal for beginners who want hands-on experience without server costs, but it stores data in local SQLite and isn’t suited for production.

A beginner thread in r/n8n from November 2024 captured the appeal: a new user running n8n locally on a Windows 11 machine to learn the tool while keeping costs at zero. That’s exactly what npm is for — learning, prototyping, and breaking things safely.

Step-by-Step npm Installation

The full npm install takes under five minutes on most systems.

1. Install Node.js (v18 or newer): Download the LTS release from nodejs.org. n8n requires Node.js 18+; older versions will fail to install. If you’re unsure which LTS line to pick, choose the current Active LTS release.
2. Verify the install: Run node -v and npm -v to confirm both are present and return version numbers. If either command errors with something like command not found, Node.js is not on your PATH and the install didn’t complete.
3. Install n8n globally: Run npm install n8n -g. The download includes the full node library and editor UI.
4. Launch n8n: Type n8n start in your terminal. A common first-run error here is EADDRINUSE: address already in use :::5678, which means another process already holds port 5678 — stop it or start n8n on a different port.
5. Open the editor: Visit http://localhost:5678 in your browser. You’ll land on the n8n canvas, ready to build.

npm gets you running fast. The catch is durability. SQLite stored in your home directory means a misconfigured path, an OS reinstall, or a clumsy delete can wipe every workflow. Treat npm installs as disposable sandboxes, never as the system your payroll depends on.

If you keep npm for light use, set the N8N_ENCRYPTION_KEY environment variable before your first launch. Skip it, and n8n auto-generates a key that, if lost, locks you out of every stored credential permanently — you’ll see decryption errors on every credential the next time the key changes. Our workflow automation playbook covers this exact gotcha in depth.

How Do You Self-host n8n With Docker and Docker Compose?

how to self-host n8n plays a pivotal role in this context.

To self-host n8n with Docker Compose, you define n8n and a PostgreSQL database in a single YAML file, mount persistent volumes for data, and bring the whole stack up with one command. Separating the n8n database from the application container is the recommended pattern for production, as the official n8n community Docker guide describes — it isolates the application, persists data reliably, and makes upgrades trivial.

Docker solves npm’s fragility. Containers package n8n with everything it needs, named volumes survive restarts, and PostgreSQL handles concurrent executions far better than SQLite. When your workflows handle real money and real customers, this is the floor — not a nice-to-have.

Prerequisites

• A server running Docker Engine 20.10+ and Docker Compose v2, with Ubuntu 22.04 LTS or newer as the most widely used host OS.
• At least 1GB RAM for light use; 2GB+ for production with AI nodes, since AI-heavy executions can otherwise trigger out-of-memory (OOMKilled) container restarts.
• A registered domain name if you plan to receive webhooks from external services like Stripe, GitHub, or Slack, since webhook callbacks require a publicly resolvable HTTPS URL.
• Basic terminal access via SSH to deploy and manage containers.
• Roughly 5GB of free disk space for the image, database, and execution logs.

Single-Container Docker Setup

For a quick isolated instance, Docker alone works. Run this command, substituting a strong encryption key:

docker run -it --rm --name n8n -p 5678:5678 -v n8n_data:/home/node/.n8n -e N8N_ENCRYPTION_KEY=your_secure_key docker.n8n.io/n8nio/n8n

The -v n8n_data:/home/node/.n8n flag creates a named volume so your workflows survive container restarts. That single flag is the difference between durable and disposable.

Production Docker Compose Setup

For business deployments, Docker Compose with PostgreSQL is the standard. Create a docker-compose.yml defining two services — a Postgres database and the n8n application — plus named volumes for each.

1. Create a project directory: mkdir n8n-prod && cd n8n-prod.
2. Write a .env file holding your database credentials, N8N_ENCRYPTION_KEY, and WEBHOOK_URL. Never hardcode secrets into the YAML.
3. Define the Postgres service with a persistent volume so your data outlives any container rebuild.
4. Define the n8n service, pointing it at Postgres via DB_TYPE=postgresdb and the matching connection variables.
5. Bring the stack up: Run docker compose up -d. The -d flag runs it detached in the background.
6. Verify: Run docker compose ps to confirm both containers are healthy, then visit your instance. If n8n logs ECONNREFUSED against the database, the app container usually started before Postgres finished initialising — a depends_on with a health check resolves it.

Upgrades become a two-command ritual: docker compose pull followed by docker compose up -d. No reinstalls, no lost workflows. That reproducibility is why production systems generally ship on Docker Compose. If you’d rather skip the YAML wrestling entirely, our team handles custom automation deployment end to end.

Which Environment Variables Are Critical When You Self-host n8n?

The two most critical environment variables for self-hosting n8n are N8N_ENCRYPTION_KEY, which encrypts stored credentials, and WEBHOOK_URL, which tells external services where to send triggers. Misconfigure either and you get one of two failures: locked-out credentials or webhooks that silently never fire.

N8N_ENCRYPTION_KEY is the master key for every API token, OAuth credential, and password n8n stores. Set it once, back it up securely, and never change it casually — rotating it without re-entering credentials renders all stored secrets unreadable. Treat this key like a database root password: stored in a secrets manager, never in Git, never in a screenshot.

WEBHOOK_URL is what makes Stripe, GitHub, Typeform, and every other webhook-driven integration actually reach your instance. When n8n sits behind a reverse proxy or tunnel, the internal address (localhost:5678) means nothing to an external service. WEBHOOK_URL overrides the generated webhook address with your real public domain.

The Essential Variables Table

Get the timezone wrong and your “9 AM” report fires at 4 AM — a small variable with a real consequence, and one of the more common support tickets in scheduled workflows.

How Do You Secure a Self-hosted n8n Instance for Production?

Integrating how to self-host n8n into your strategy ensures a competitive edge.

Securing a self-hosted n8n instance requires HTTPS via a reverse proxy, a configured firewall, authentication enabled, and a backed-up encryption key. An exposed n8n instance without these is a credential vault sitting open on the public internet — and automated bots scan for exactly that within hours of deployment.

Security isn’t a phase you add later. A self-hosted n8n instance holds the keys to your Stripe account, your CRM, your email, and your database. The threat model is real: misconfigured automation tools are a known attack surface, and broken access control and security misconfiguration are perennial entries in the OWASP Top 10. Treat your n8n instance like the privileged system it is.

The Production Security Hardening Checklist

1. Enable HTTPS with a reverse proxy: Put Nginx, Caddy, or Traefik in front of n8n. Caddy auto-provisions free Let’s Encrypt certificates, making SSL a one-line config. Never run a production instance over plain HTTP.
2. Lock down the firewall: Use UFW on Ubuntu to allow only ports 80, 443, and your SSH port. Block 5678 from the public internet — traffic should flow only through the proxy.
3. Enable authentication: Set N8N_BASIC_AUTH_ACTIVE=true with a strong username and password, or front the instance with proxy-level auth. No instance should be reachable without a login.
4. Secure SSH: Disable password login, use key-based authentication, and change the default port. Fail2Ban adds brute-force protection.
5. Back up the encryption key: Store N8N_ENCRYPTION_KEY in a password manager or secrets vault. Lose it and every credential becomes permanently unrecoverable.
6. Keep the system patched: Run docker compose pull regularly and apply OS security updates. Outdated containers carry known vulnerabilities.
7. Restrict CORS and webhook exposure: Only expose the webhook endpoints you actually need publicly.

Encryption Key Rotation Done Right

Rotating the encryption key is the most misunderstood security task in n8n. You cannot simply swap the key — doing so orphans every encrypted credential. The correct rotation process involves exporting credentials, decrypting with the old key, re-importing under the new key, and verifying each connection before retiring the old key. A sensible cadence for high-security environments is annual rotation, with every step documented, because transparency about what changed and why is part of operating a trustworthy system.

Remote access deserves a note. If you don’t want to open ports at all, tools like Cloudflare Tunnel or Tailscale expose n8n securely without port forwarding — a pattern that Localtonet’s guide on self-hosting n8n covers for webhook handling and remote access. For SMEs without a dedicated ops team, a tunnel is often safer than a manually managed firewall.

How Do You Handle Webhooks From Stripe and GitHub on Self-hosted n8n?

how to self-host n8n is a core pillar of sustained growth.

To handle external webhooks on self-hosted n8n, set the WEBHOOK_URL environment variable to your public HTTPS domain, expose the webhook path through your reverse proxy, and register that URL in the external service’s webhook settings. Without a correct public WEBHOOK_URL, services like Stripe and GitHub generate signatures and deliveries that never reach your instance.

Webhooks are where self-hosted n8n earns its keep. Stripe payment events, GitHub pull requests, Typeform submissions, and WhatsApp messages all push data to your workflows in real time. The architecture is straightforward once you understand the flow: the external service hits your public domain over HTTPS, your reverse proxy routes it to n8n’s internal port, and the matching Webhook node triggers the workflow.

Webhook Setup Walkthrough

1. Confirm WEBHOOK_URL is set to your real domain, e.g. https://n8n.yourdomain.com/. n8n generates webhook URLs from this value.
2. Create a Webhook node in your workflow and copy its production URL.
3. Register the URL in the external service — for Stripe, that’s Developers → Webhooks; for GitHub, Settings → Webhooks.
4. Verify the signature: For Stripe, validate the stripe-signature header inside n8n to reject forged requests. Never trust an unverified webhook payload.
5. Test the delivery using the service’s built-in test event, then check n8n’s executions log to confirm receipt.

A common failure: the webhook works in n8n’s “test” mode but dies in production. The fix is almost always activating the workflow — test URLs only listen while the editor is open, while production URLs require an active workflow. That single distinction resolves a large share of webhook support tickets.

For WhatsApp and Telegram automations especially, self-hosted webhooks unlock intelligent AI chatbot workflows that respond to customers around the clock without per-message platform fees.

What’s the Total Cost of Ownership: Self-hosted n8n vs Zapier and Make?

The total cost of ownership for self-hosted n8n is typically lower than Zapier or Make at scale, because n8n has no per-task fees — you pay a flat server cost regardless of execution volume. An SME running high monthly operation counts generally pays a modest flat VPS bill for self-hosted n8n versus a usage-scaled Zapier or Make plan, and the gap compounds as automation usage grows.

The pricing models diverge fundamentally. Zapier and Make bill on task or operation volume — every step of every workflow consumes from your quota. Self-hosted n8n decouples cost from usage entirely. A small droplet doesn’t care whether it runs 1,000 or 100,000 executions a month, as long as the hardware keeps up.

Honest TCO Comparison

The honest tradeoff: self-hosting trades cash cost for operational responsibility. You own patching, backups, and uptime. For a solo founder testing one automation, Zapier’s zero-maintenance convenience may genuinely be worth the premium. But once automation becomes core infrastructure — and for most growing SMEs it does — the math tends to favour self-hosting.

Build your own estimate honestly: take the live Zapier or Make tier that fits your operation count, then add a realistic maintenance estimate of two to four hours monthly for the self-hosted side and value that time at your own blended rate. Even with maintenance time priced in, the self-hosted total commonly undercuts usage-based plans at high volume — but you should confirm the break-even point against your real numbers rather than assuming it. An ROI model that takes your specific task count and compares it against current Zapier and Make pricing will show you that crossover precisely.

How Do You Back Up and Recover a Self-hosted n8n Instance?

Applying how to self-host n8n delivers measurable results over time.

To back up self-hosted n8n, you must capture three things: the PostgreSQL database, the N8N_ENCRYPTION_KEY, and your workflow JSON exports. Miss any one and recovery fails — the database without the encryption key is a vault you can’t open, and the key without the database is a key to nothing.

Disaster recovery is the discipline that separates resilient systems from fragile ones. A self-hosted n8n instance running payroll, invoicing, or customer onboarding can’t tolerate “the server died and we lost everything.” Yet that’s exactly what happens to teams who never tested a restore. A backup you haven’t restored is a hope, not a plan.

The Three-Layer Backup Strategy

• Database dumps: Schedule automated pg_dump exports of your PostgreSQL database, the single source of truth for workflows, credentials, and execution history. Daily is a sensible baseline; hourly for high-stakes systems.
• Encryption key vault storage: Keep N8N_ENCRYPTION_KEY in a secrets manager separate from the server. The database is encrypted with this key — without it, restored credentials are useless ciphertext.
• Workflow JSON exports: Export workflows as JSON into a version-controlled Git repository. This gives you human-readable history and lets you roll back a broken workflow change in seconds.

Automating Backups With n8n Itself

The elegant move is using n8n to back up n8n. A scheduled workflow can trigger a pg_dump, compress the result, and push it to S3, Backblaze, or a Google Drive folder nightly — an off-site, encrypted, automated backup that needs zero human attention until the day it saves the business. Off-site storage matters: a backup sitting on the same droplet that just failed protects you from nothing.

Test your restore quarterly. Spin up a fresh instance, restore the database, inject the encryption key, and confirm a credential actually authenticates. Until you’ve done that, you don’t have a recovery plan — you have an untested theory.

How Do You Connect Self-hosted n8n to AI Agents and LLMs?

how to self-host n8n is one of the most relevant trends shaping 2026.

Self-hosted n8n connects to AI agents and LLMs through dedicated AI nodes that call models like OpenAI’s GPT, Anthropic’s Claude, or self-hosted models via Ollama, letting workflows reason over data rather than just route it. Combining self-hosted n8n with LLMs turns deterministic automation into intelligent automation — workflows that classify, summarize, decide, and respond.

This is where self-hosting compounds its value. Because your data never leaves your server, you can pipe sensitive customer records through a locally hosted model with Ollama and keep everything on-premise — a genuine advantage for privacy-conscious SMEs that cloud automation platforms can’t match. Connect a WhatsApp webhook to an LLM node to an n8n decision tree, and you’ve built an intelligent support agent without a single line of application code.

Avoiding the AI Sycophancy Trap

A contrarian but practical stance: a lot of “AI automation” fails because it bolts a probabilistic “yes-machine” onto a process that needs determinism. An LLM that hallucinates an order status or invents a refund amount isn’t automation — it’s a liability with a chat interface. The fix is architecture: wrap LLM calls in deterministic guardrails such as validated outputs, structured schemas, and human-in-the-loop approval for high-stakes actions.

Self-hosted n8n is an ideal substrate for this because every node is inspectable and every execution is logged. You can see precisely what the AI received, what it returned, and what action followed. That transparency is what makes AI trustworthy enough for real business processes — not a vague promise that “the model is smart.”

Practical AI Workflow Patterns

• Intelligent email triage: An LLM node classifies incoming support emails by urgency and routes them, while a deterministic rule guarantees billing issues always escalate to a human.
• Document extraction: Parse invoices and contracts into structured JSON, then validate the output against a schema before it touches your ERP.
• Multilingual marketing: Generate localized email and marketing copy directly inside a workflow, with human review before send.
• RAG-powered chatbots: Connect a vector database to an LLM node so your WhatsApp bot answers from your actual knowledge base, not from the model’s imagination.

Actionable Takeaways: Your Self-hosted n8n Launch Plan

To launch a production self-hosted n8n instance, deploy via Docker Compose on a VPS, set the encryption and webhook variables, harden security with HTTPS and a firewall, then automate backups before building business-critical workflows. Follow the sequence and you’ll have a durable, secure, cost-saving automation engine in an afternoon.

A reliable deployment order looks like this:

1. Provision a VPS — an entry-level DigitalOcean or Hetzner droplet running Ubuntu 22.04 is plenty for most SMEs.
2. Install Docker and Docker Compose and write a Compose file pairing n8n with PostgreSQL.
3. Set critical environment variables — N8N_ENCRYPTION_KEY, WEBHOOK_URL, N8N_HOST, and your timezone.
4. Add a reverse proxy (Caddy is fastest) for automatic HTTPS, then lock the firewall to ports 80, 443, and SSH.
5. Enable authentication and secure SSH with key-based login.
6. Automate backups — schedule pg_dump to off-site storage and vault your encryption key.
7. Test a restore before you trust the system with anything important.
8. Build, then add AI — start with deterministic workflows, layer in LLM nodes with guardrails once the foundation is solid.

Skip none of these. The teams that regret self-hosting are invariably the ones who skipped security or backups to “move fast.” The teams that love it are the ones who did the boring foundational work once and then forgot about it for a year.

If your team lacks the bandwidth to manage infrastructure, that’s precisely the gap J. SERVO fills — we deploy, harden, and maintain self-hosted n8n so you get the cost savings without the ops burden.

Frequently Asked Questions

how to self-host n8n plays a pivotal role in this context.

Is self-hosting n8n free?

Yes — the n8n Community edition is free and open-source, with no per-task fees or execution limits. Without a license key, n8n runs as the free Community edition, according to n8n’s official hosting documentation. Your only cost is the server itself, typically a modest monthly VPS bill for a server that handles tens of thousands of executions.

What’s the easiest way to self-host n8n for beginners?

The easiest way to self-host n8n for beginners is the npm method: install Node.js 18+, run npm install n8n -g, then launch with n8n start. It takes under five minutes but stores data in fragile local SQLite. For anything you’d be upset to lose, graduate to Docker Compose with PostgreSQL for production durability.

Do I need a domain name to self-host n8n?

You only need a domain name if external services must send webhooks to your instance — Stripe, GitHub, Typeform, and similar integrations require a public HTTPS URL set via WEBHOOK_URL. For purely internal automations or local testing, an IP address or localhost works fine, though a domain plus HTTPS is strongly recommended for any production deployment.

How much can self-hosting n8n save versus Zapier?

Because n8n has no per-task fees, savings grow with volume: a flat VPS cost replaces a usage-scaled Zapier or Make plan. At high monthly operation counts the difference can be substantial, but the exact figure depends on your task volume and the current vendor pricing tier — so calculate it against your real numbers and factor in your own maintenance time rather than relying on a headline figure.

Is self-hosted n8n secure enough for business use?

Self-hosted n8n is secure enough for business use when properly hardened with HTTPS, a firewall, authentication, and a backed-up encryption key. Self-hosting actually improves data control because credentials never leave your hardware. The risk lies in misconfiguration — an exposed instance without these protections is a target, so security hardening is mandatory, not optional.

Can self-hosted n8n connect to AI models like ChatGPT and Claude?

Yes — self-hosted n8n includes dedicated AI nodes that connect to OpenAI’s GPT, Anthropic’s Claude, and self-hosted models via Ollama. Because data stays on your server, you can run sensitive records through a local LLM and keep everything on-premise, enabling intelligent automation that classifies, summarizes, and responds while preserving full data privacy.

Sources & References

• n8n Hosting Documentation and Guides — n8n Docs (Community vs Business/Enterprise editions; recommended hosting methods)
• How to self-host n8n using Docker — n8n Community (best-practice Docker setup separating database and application)
• How to Set Up n8n: A Step-by-Step Guide — DigitalOcean (Docker Compose on an Ubuntu server)
• Beginner seeking advice: best setup for self-hosting n8n locally — r/n8n, Nov 2024 (community perspective on low-cost local setups)
• How to Self-Host n8n: Complete Guide — Localtonet Blog (installation, security, webhooks, and remote-access patterns)
• OWASP Top 10 (broken access control and security misconfiguration risk categories)

Note: This article is for general informational purposes; verify specifics against your own context.