How to Self-Host n8n: VPS Sizing, Docker Setup, and Scaling Checklist

Overview

If you want to self host n8n, the core decision is not just where to run the container. It is how much operational responsibility you want to keep. n8n is approachable for small deployments, but it still depends on the same basics as any open-source app: stable compute, persistent storage, secure access, backups, logs, and a plan for updates.

For most readers, a VPS with Docker is the right starting point. It offers enough control for environment variables, reverse proxy configuration, and backups without forcing you into a full orchestration stack too early. If you are still deciding on infrastructure, it helps to compare developer-friendly hosts and small-team cloud options before you commit to a provider. Our guides to best VPS hosting for developers and DigitalOcean vs Linode vs Vultr vs Hetzner are useful starting points.

At a high level, your n8n hosting checklist should answer six questions:

• How many workflows will run, and how often?
• Will workflows wait on external APIs, large payloads, or long execution times?
• Do you need high availability, or is short maintenance downtime acceptable?
• Will one person manage the server, or will multiple teammates touch it?
• How important are logs, alerting, and rollback during updates?
• What happens if the server fails today?

If you cannot answer those yet, start small but leave room to grow. That means using Docker, mounting persistent volumes, placing n8n behind a reverse proxy with HTTPS, and documenting the environment variables and backup routine from day one.

Checklist by scenario

Use these scenarios as planning templates rather than fixed rules. Exact n8n VPS requirements depend on workflow complexity, concurrency, and the behavior of the services you connect to.

Scenario 1: Personal automations or light internal use

This is the common starting point: a few workflows, low concurrency, and mostly lightweight API calls or notifications.

• VPS profile: Start with a small VPS running a recent Linux distribution such as Ubuntu.
• CPU and memory: A modest instance is usually enough if workflows are short and infrequent.
• Storage: Use SSD-backed storage and mount persistent volumes for n8n data.
• Database: You may begin with the default simple setup, but many teams still prefer a separate database early for cleaner upgrades and easier recovery planning.
• Docker setup: Use Docker Compose or an equivalent multi-container definition so the deployment is easy to recreate.
• Reverse proxy: Put n8n behind Nginx, Caddy, Traefik, or another reverse proxy with TLS.
• Backups: Back up both the database and any mounted volumes on a schedule.

This setup is enough when convenience matters more than redundancy. It is similar in spirit to other small open-source app deployments. If you have hosted applications like Plausible or Ghost before, the same operational patterns apply: keep persistence explicit, updates predictable, and recovery documented. Related reads: How to Host Plausible Analytics Yourself and How to Host a Ghost CMS Site on a VPS.

Scenario 2: Team automation with moderate usage

Once multiple people depend on n8n, the acceptable margin for failure gets smaller. A single underpowered instance can still work, but you should expect to add more discipline around monitoring and updates.

• VPS profile: Move to a medium VPS with more headroom for simultaneous workflow execution.
• CPU and memory: Plan for spikes, not just averages. Workflows that call slow APIs can tie up resources longer than expected.
• Database: Prefer a dedicated database service or at least a separate managed or self-hosted database container with clear backup procedures.
• Queue or worker model: Review whether your usage pattern benefits from separating execution from the main web process.
• Logging: Centralize logs or at minimum ensure container logs are rotated and retained long enough for troubleshooting.
• Backups and restore tests: Do not stop at creating backups. Test a restore to confirm they are actually usable.
• Access control: Tighten SSH access, rotate secrets, and document who can deploy changes.

This is also the point where the hosting choice matters more. Some low-cost VPS plans are fine for experiments but less comfortable for sustained production workloads. If you are weighing Docker-friendly platforms and VPS tradeoffs, see Best Hosting for Docker Projects.

Scenario 3: Business-critical workflows or customer-facing automation

If n8n handles lead routing, transactional integrations, internal approvals, or workflows tied directly to revenue, the question changes from “Can I host this?” to “How much downtime and operational risk is acceptable?”

• Compute: Use a larger VPS or move toward cloud instances with stronger operational tooling.
• Database: Use a dedicated production-grade database setup with backups, versioning awareness, and access controls.
• Separation of roles: Avoid running every component on one box if uptime matters. Separate the reverse proxy, app execution, and database where practical.
• Monitoring: Track CPU, memory, disk, process restarts, certificate expiry, and failed requests.
• Alerting: Set alerts for service downtime, disk pressure, and backup failures.
• Update process: Use a staging or test environment before changing n8n versions or infrastructure.
• Disaster recovery: Document your recovery time target and the exact restore steps.

Not every deployment needs Kubernetes or a complex cluster. In many cases, a well-managed VPS stack with disciplined backups and monitoring is more reliable than an overbuilt platform no one on the team wants to maintain. The best choice is the one your team can operate consistently.

Scenario 4: Heavy workflows, large payloads, or integration sprawl

Some n8n environments grow difficult because of what the workflows do, not because the user count is high. Long-running jobs, large file handling, many webhooks, or chains of API calls can create memory pressure and uneven performance.

• Profile the real bottleneck: Check whether CPU, RAM, disk I/O, network, or database latency is the limiting factor.
• Avoid guessing: Measure resource usage during peak workflow windows.
• Separate workloads: Consider splitting high-load automation from general-purpose workflows.
• Review timeout behavior: External services may cause retries, backlog, or hung runs.
• Inspect storage growth: Execution data, logs, and temporary artifacts can accumulate quietly.

This is often where people conclude they need “more server” when the actual fix is workflow cleanup, lower retention, fewer synchronous waits, or better separation between test and production automations.

Baseline Docker deployment checklist

No matter which scenario fits you today, a sound n8n Docker setup should include the following:

• A dedicated Linux host with Docker and your compose tool of choice installed
• A non-root operational workflow for routine administration where possible
• A pinned or intentionally selected image tag rather than blind latest-only updates
• Persistent volumes for application data
• Environment variables stored and documented carefully
• A reverse proxy with HTTPS and the correct external URL configuration
• Firewall rules allowing only required ports
• Automated backups for data and database
• Basic monitoring for service health and disk capacity
• A written update and rollback routine

What to double-check

Before you call the deployment finished, review the details that most often cause trouble later.

Persistence and backup scope

Many first-time self-hosted app setups work until the first container recreation. Make sure your n8n data is not living only inside the container filesystem. Know exactly what must be backed up: database contents, environment configuration, and any mounted persistent data. Keep a simple restore checklist in the same documentation repo or runbook you use for deployment.

External URL and reverse proxy settings

n8n depends on correct external access settings, especially when webhooks are involved. If the app thinks it is running at one URL while the reverse proxy exposes another, callback failures can be hard to diagnose. Double-check your domain, TLS certificates, proxy headers, and any base URL settings before you connect real services.

Secrets management

Do not leave credentials scattered across shell history, ad hoc notes, or old compose files. Even for a small deployment, centralize environment variables and limit who can read them. If you later migrate hosts, this becomes one of the main failure points.

Update path

Plan how you will upgrade n8n before the first production workflow depends on it. That includes container image updates, database compatibility awareness, and a rollback process. A practical rule: never update without a recent backup and a quick way back to the previous working version.

Observability

If a workflow fails overnight, how will you know? At minimum, capture logs and watch for container restarts. If the deployment matters to your team, add basic uptime monitoring and alerts. This is also where anomaly detection habits help. You do not need a complex system, but you do need to notice when memory usage, execution time, or failures begin drifting from normal. For a broader view of why this matters operationally, see Why Anomaly Detection Is Becoming a Core Hosting Skill.

Common mistakes

The most expensive n8n hosting mistakes are usually simple ones repeated for too long.

• Choosing the smallest possible VPS with no headroom. Cheap infrastructure is fine for testing, but production automation needs margin for retries, peaks, and growth.
• Running without backups you have actually tested. A backup job that runs is not the same as a verified restore plan.
• Using Docker without documenting the deployment. If only one person knows the environment variables, ports, and volumes, recovery becomes slower than it needs to be.
• Exposing the app carelessly. Public access without proper proxying, HTTPS, firewall rules, and credential hygiene is an avoidable risk.
• Upgrading reactively. Updating in a hurry after a problem appears can create a second problem. Schedule updates, note changes, and keep rollback options ready.
• Ignoring data growth. Logs, execution records, and attached data can consume storage over time.
• Treating all workflows as equal. Test jobs, internal utilities, and critical production automations should not always share the same assumptions or resource budget.

If your stack already includes other self-hosted apps, resist the urge to put everything on one server just because it fits today. Consolidation lowers cost, but it can also mix failure domains. The right balance depends on the impact of downtime and how comfortable your team is maintaining Linux, Docker, and networking. Readers planning a broader stack may also want to compare hosting approaches for application frameworks and containers in Best Hosting for Laravel Applications.

When to revisit

Your first n8n hosting decision should not be permanent. Revisit it whenever the workload or the consequences of failure change.

Use this short review checklist before seasonal planning cycles, before major workflow changes, or when new tools are added:

• Workflow count changed: Are you running significantly more automations than when the server was sized?
• Execution pattern changed: Are jobs running longer, more frequently, or with larger payloads?
• Business impact changed: Would a few hours of downtime now interrupt sales, support, or operations?
• Team size changed: Do more people need safe access, logs, and deployment clarity?
• Compliance or security expectations changed: Are you now expected to retain logs differently or tighten access controls?
• Hosting economics changed: Would moving to a different VPS or cloud provider simplify operations or improve reliability?

A practical action plan is simple:

1. Document your current n8n deployment in one place.
2. Record actual resource usage over a normal and a busy week.
3. Test backup restoration on a separate host or temporary environment.
4. Review whether a larger VPS, separate database, or split workload would remove the next likely bottleneck.
5. Schedule the next review date now, not after the next incident.

If you are still evaluating providers, compare the infrastructure itself first, then the app setup second. A stable, developer-friendly host usually matters more than minor stack preferences. For that broader buying step, our guides to best VPS hosting for developers and best hosting for Docker projects can help narrow the field.

The best self-hosted n8n setup is rarely the most elaborate one. It is the one sized for your actual workload, deployed in a way the team can maintain, and reviewed before growth turns a small inconvenience into a reliability problem.