How to Self-Host n8n

n8n is one of the few workflow platforms people often choose specifically because they want more ownership.

Self-hosting is where that ownership becomes real.

It can be a great fit when you want more control over the environment, deployment model, and supporting stack. It can also become a source of downtime and risk if the team treats it like a one-time install instead of an operating system.

Why this lesson matters

As of May 6, 2026, n8n's docs still recommend Docker for most self-hosting needs and explicitly say self-hosting is best suited to expert users.

That is a useful framing.

Self-hosting matters because the moment you move beyond n8n Cloud, you own:

• uptime
• persistence
• TLS and network exposure
• secrets handling
• upgrades
• backups
• security controls
• support for everyone using the instance

Those are not side topics. They are the actual platform.

The short answer

The safest official starting point is Docker or Docker Compose.

n8n's docs recommend Docker because it gives a cleaner, more isolated environment and simplifies dependency management.

If the instance is going to matter in production, think beyond the first container launch and design for:

• persistent storage
• a stable hostname and webhook URL
• TLS or reverse-proxy setup
• database choice
• update and backup routines
• security controls around requests, users, and risky nodes

That is what turns a self-hosted instance into a usable platform instead of a fragile side project.

Start with Docker or Docker Compose unless you have a strong reason not to

This is the clearest official guidance.

n8n's Docker docs recommend:

• a persistent volume for .n8n
• timezone settings
• secure file permissions
• task runners enabled

The Docker Compose guide also shows a more production-minded pattern with:

• a dedicated subdomain
• Traefik as a reverse proxy
• HTTPS
• a bind mount for shared local files

That is usually a much better mental model than "just run docker run and hope."

Persistence is not optional

The docs are explicit that .n8n contains important data, including:

• the SQLite database in default setups
• the encryption key
• instance logs
• source-control feature assets

Even if you move the main database to PostgreSQL, the docs still recommend persisting .n8n.

That means volume design is one of the first real production decisions.

SQLite can work, but production-minded teams often plan for PostgreSQL

n8n's docs say self-hosted installations use SQLite by default and optionally support PostgreSQL.

SQLite is fine for simpler or earlier-stage use cases.

As the instance becomes more important, teams often prefer PostgreSQL because they want a more conventional production database story.

That does not mean everyone must start there. It does mean database choice should be deliberate rather than accidental.

Secure webhook exposure matters

If you want external services to trigger workflows, n8n needs to be reachable.

That means:

• a domain or subdomain
• proper TLS
• a webhook URL that reflects your real public endpoint

The Docker Compose guide uses Traefik and HTTPS for exactly this reason.

A reachable webhook endpoint without a real security model is not a production deployment.

Security hardening is part of self-hosting, not a later add-on

n8n's security docs highlight controls like:

• SSL
• SSO
• 2FA
• execution-data redaction
• public API disablement
• node restrictions
• SSRF protection

The SSRF docs are especially relevant because many workflow systems can make outbound HTTP requests on behalf of users.

As of May 6, 2026, n8n documents N8N_SSRF_PROTECTION_ENABLED=true and recommends network-level protections as the primary defense, with SSRF controls as defense-in-depth.

That is exactly the right mindset for a self-hosted automation platform.

Community nodes and code execution increase the blast radius

Self-hosting makes more flexibility possible. It also makes more risk possible.

n8n's docs warn that community nodes have full access to the machine n8n runs on.

That means features like:

• community nodes
• HTTP requests to internal systems
• code execution
• local file access

should be treated as infrastructure-level risk decisions, not just workflow-builder convenience.

Upgrades and testing need a routine

n8n's update docs recommend staying current, checking release notes, and testing before upgrading production.

That matters because self-hosting is not static:

• new features arrive often
• breaking changes can happen
• templates and workflows can depend on newer behavior

If the team cannot update with confidence, the instance will eventually become harder to trust.

A strong self-hosting pattern is narrow and intentional

A healthy setup usually looks like:

• Docker or Docker Compose
• persistent storage
• HTTPS
• a controlled database story
• backup and update discipline
• limited node and network blast radius
• clear ownership for support and monitoring

This is what makes self-hosting sustainable.

Common mistakes

Mistake 1: Treating self-hosting as just "run the container"

That ignores upgrades, backups, TLS, permissions, and recovery.

Mistake 2: Exposing the instance publicly without a real security model

Webhooks and browser access need deliberate protection.

Mistake 3: Ignoring persistence details

Encryption keys and workflow data should not depend on luck.

Mistake 4: Enabling risky flexibility without guardrails

Community nodes, unrestricted HTTP access, and code execution all raise the platform's risk profile.

Mistake 5: Choosing self-hosting for cost alone

Operations responsibility can erase simple cost assumptions quickly.

Final checklist

Before self-hosting n8n, ask:

1. Does the team actually want to own upgrades, backups, security, and support?
2. Will Docker or Docker Compose cover the environment cleanly?
3. How will .n8n data and the encryption key be persisted safely?
4. Do you need PostgreSQL yet, or is SQLite still acceptable for the current stage?
5. How will webhook exposure, TLS, and domain routing be handled?
6. Which security controls around SSRF, risky nodes, and community nodes need to be enabled from day one?

If those answers are clear, self-hosting n8n can be a strong advantage instead of an operational surprise.

FAQ

What is the easiest way to self-host n8n?

The easiest official starting point is Docker, because n8n recommends it for most self-hosting needs and provides both Docker and Docker Compose guides.

When should a team use PostgreSQL with self-hosted n8n?

Teams often move to PostgreSQL when the instance becomes more operationally important, especially when they want a stronger production database setup than the default SQLite path.

Is self-hosting n8n mainly about saving money?

Usually no. The stronger reasons are control, hosting preference, privacy requirements, and workflow ownership. Cost matters, but operations responsibility often matters more.

What is the biggest mistake when self-hosting n8n?

The biggest mistake is treating hosting as a one-time install instead of an ongoing operations job. Security, upgrades, backups, and environment hardening all become part of the system.

Final thoughts

Self-hosting n8n is most valuable when the team wants real control and is ready to operate the platform responsibly.

That control can be a huge advantage. It only stays an advantage if the environment itself is treated like part of the product.