Running n8n on a VPS? Here’s what you need to know: the right setup depends on your workflows’ complexity, team size, and resource needs. This guide breaks down everything – from choosing CPU, RAM, and disk storage to scaling options for solo users, small teams, or full-scale production.
Key Points:
- CPU: Start with 2 vCPUs for light use, scale to 8+ for production.
- RAM: 2–4 GB for personal projects, 16–32 GB for high-demand setups.
- Storage: NVMe is a must for faster workflow execution and database performance.
- Database: SQLite works for solo use; Postgres is better for teams or concurrent workflows.
- Scaling: Vertical scaling (upgrading VPS specs) works initially; horizontal scaling (adding worker nodes) is better for heavy workloads.
What Affects n8n Performance
n8n is efficient but requires the right resources to keep up as your automation workload increases. The key factors influencing its performance are the number of workflows running simultaneously, how well your database manages read and write operations, and the speed of your disk. Together, these elements – CPU, database, and storage – determine how well n8n performs under pressure.
Workflow Concurrency and Execution Bursts
When multiple workflows run at the same time, they compete for CPU resources. A single workflow might perform fine on a 1‑vCPU virtual private server (VPS), but things change when several workflows are triggered at once. Tasks like API calls, data transformations, or AI processing can quickly overwhelm a single CPU core, creating delays.
Scheduled workflows often result in predictable spikes in activity, such as when multiple jobs are set to run at the start of each hour. This can cause a surge in CPU usage, delaying other workflows in the queue. Similarly, unscheduled events like sudden bursts of webhook requests can overwhelm a single vCPU, leading to timeouts or failed executions. To handle both these scenarios – predictable bursts and unexpected surges – having 2–4 vCPUs is a good idea.
The strain becomes obvious when workflows frequently wait to execute, even if they aren’t overly complex. This is a common limitation on a 1‑vCPU setup under concurrent loads.
Database Load: SQLite vs Postgres
n8n relies on a database to store workflow definitions, execution logs, credentials, and other critical data. Choosing between SQLite and Postgres can significantly impact performance, especially under concurrent operations.
SQLite is a file-based database that works well in environments where only one process writes at a time. However, concurrent writes can cause delays and increase the risk of corruption if the system crashes. For individuals running workflows sequentially, SQLite is usually sufficient and requires minimal configuration.
Postgres, on the other hand, is built to handle concurrent reads and writes efficiently without locking issues. This makes it the better choice for setups involving multiple workflows, team collaboration, or queue mode with workers. Postgres also offers advanced features like better backup options, replication, and the ability to scale independently from your n8n instance.
Storage IOPS and Disk Speed
Disk performance is often overlooked but plays a crucial role in how quickly workflows run and how stable your system remains.
NVMe storage offers significantly higher input/output operations per second (IOPS) – often 10× or more compared to SATA SSDs. This difference can be critical for workflows that generate large logs, process extensive datasets, or require frequent database updates.
For workflows handling heavy data payloads or detailed logging, slower disks can noticeably delay operations. Database tasks, such as updating transaction logs and indexes, also benefit from faster storage. If you’re running a production environment, NVMe storage should be your go-to. If you notice slowdowns, growing queues, or timeout errors despite having enough CPU and RAM, slow disk I/O could be the culprit.
VPS Specifications by Use Case
Selecting the right VPS size depends on the complexity of your workflows, the number of users, and whether you need real-time webhook processing or scheduled batch jobs. The tiers below are based on common usage scenarios to help you match your needs. After determining your VPS tier, consider which database setup will ensure smooth performance.
Tier 1: Solo Users and Light Automation
Specs: 2 vCPU, 2–4 GB RAM, 20–40 GB NVMe storage
This setup is perfect for individual developers working on personal projects, connecting a few APIs, or creating internal dashboards. It supports 15–30 active workflows triggered occasionally throughout the day. Typical tasks might include syncing data between Google Sheets and a CRM, sending Slack notifications from form submissions, or generating daily analytics reports.
With 2 vCPUs, you can handle several workflows running at the same time without delays. While 2 GB of RAM is sufficient for smaller tasks, opting for 4 GB is wise if you’re processing larger JSON payloads or image data. Storage needs are modest, as workflow data grows gradually, and NVMe storage ensures fast database writes, even with SQLite’s file-locking behavior.
This tier works well for sequential or lightly overlapping workflows. It can handle 3–5 workflows triggering simultaneously during peak times without major slowdowns. Beyond that, you may notice slower response times and queued tasks.
Database choice: SQLite is suitable here since workflows rarely execute simultaneously. Just make sure to set up automated backups, as SQLite can corrupt during write operations.
Tier 2: Small Teams and Moderate Workloads
Specs: 4 vCPU, 8 GB RAM, 40–80 GB NVMe storage
Designed for small teams of 2–5 members, this tier can handle 50–100 active workflows managing real operational tasks. Examples include processing webhook bursts from customer forms, running AI-powered data enrichment, orchestrating multi-step approval workflows, or managing data pipelines across 5–10 services.
With 4 vCPUs, you can manage multiple workflows firing at once. For instance, if 20 form submissions arrive within two minutes – each triggering a workflow that validates data, calls APIs, and updates a database – this setup can process 3–4 workflows concurrently without timing out. The 8 GB of RAM allows for handling large CSV files, nested JSON responses, or temporary image storage for S3 uploads without performance dips.
Storage demands increase significantly at this level due to more workflow versions, execution logs, and stored credentials. AI-related workflows, in particular, generate detailed logs, so allocating 30–50 GB for workflow data is a smart move.
Database choice: Postgres becomes essential at this stage. SQLite struggles with simultaneous edits, whereas Postgres handles concurrent reads and writes effortlessly. If you plan to enable queue mode, Postgres is a must.
You’ll also need a reverse proxy like Nginx or Caddy to manage SSL certificates and provide a clean domain-based URL for your team. These additional services (Postgres, reverse proxy) use 500 MB to 1 GB of RAM, which is why 8 GB is the practical minimum for this tier.
This configuration prepares your system for more demanding workloads and production-level reliability.
Tier 3: High Concurrency and Production Use
Specs: 8+ vCPU, 16–32 GB RAM, 80–160 GB NVMe storage
This tier is built for production environments where downtime can disrupt operations. It supports 200+ active workflows, processes hundreds of webhook requests per hour, and handles complex data transformations involving multiple API calls, database queries, and conditional logic.
At this level, queue mode becomes standard. The main n8n process handles triggers and the user interface, while worker processes execute workflow tasks. This separation ensures that heavy workflows don’t block others and allows you to scale execution capacity independently.
With 8 vCPUs, you can run one main process and 2–3 worker processes on the same VPS, each handling different workflows simultaneously. Need more capacity? Deploy additional worker-only VPS instances connected to the same Postgres database. This horizontal scaling approach ensures smooth performance during traffic spikes without resizing your entire infrastructure.
The 16–32 GB RAM range supports workflows that process large files, handle extensive API responses, or manage long-running executions. Some workflows may hold megabytes of data in memory while waiting for API rate limits to reset or while processing data in chunks.
Storage needs grow significantly in production. Detailed execution logs for debugging and compliance can accumulate quickly. An 80–160 GB range provides enough room for 12–18 months of data before implementing log rotation or archival.
Additional infrastructure: Add Redis for efficient queue management and session handling. Redis uses minimal resources (200–400 MB RAM) but greatly improves queue performance. You’ll also want automated database backups (e.g., to S3-compatible storage), monitoring tools like Prometheus or Grafana, and structured logging for troubleshooting.
Cost considerations: An 8 vCPU, 16 GB RAM VPS typically costs $40–80 per month, depending on the provider and region. If you scale horizontally with additional worker nodes, each 4 vCPU, 8 GB worker adds about $20–40 per month. Even with these costs, this setup remains far cheaper than managed automation platforms for comparable workloads.
The jump from Tier 2 to Tier 3 isn’t just about better specs – it’s about architectural changes. Queue mode, worker separation, and Redis integration transform n8n into a distributed system capable of handling unpredictable loads with ease. This configuration lays the foundation for advanced scaling techniques covered in later sections.
SQLite vs Postgres: Which Database to Use
Your choice of database plays a major role in determining how well n8n performs. While SQLite is fine for testing or solo use, Postgres is essential as soon as you add team members, enable queue mode, or run simultaneous workflows. Knowing when to switch can save you from performance bottlenecks and potential data issues. Let’s break down the strengths and limitations of each option.
SQLite: Best for Solo Use or Testing
SQLite is simple – it stores all data in a single file and doesn’t require any setup. When you launch n8n, it automatically creates the database, making it an appealing choice for developers who want to get started quickly or run a few personal workflows.
But here’s the catch: SQLite struggles when multiple workflows need to write data simultaneously. It uses file-level locking, meaning only one process can write at a time. This creates delays during busy periods and can result in workflows queuing unexpectedly.
Another drawback? SQLite is prone to corruption if there’s an unexpected power loss. Without recent external backups, you risk losing everything – workflow history, credentials, and configurations.
For solo developers managing 10–20 workflows that rarely overlap, SQLite can work just fine. It avoids the complexity of setting up Postgres and has a lower memory footprint. However, if you start noticing webhook delays, database lock errors, or workflows piling up in queues, it’s time to consider Postgres.
Note: If you’re running SQLite in WAL (Write-Ahead Logging) mode on slower disks, you might see even longer lock times.
Postgres: The Go-To for Production
Postgres is built for handling multiple users and high-concurrency situations. Unlike SQLite, it uses row-level locking, which allows multiple workflows to write data at the same time without creating bottlenecks.
If you enable queue mode – where worker processes handle workflow execution separately – Postgres becomes a must. This mode requires seamless coordination across multiple processes, something SQLite simply can’t manage reliably.
Setting up Postgres is straightforward, even though it adds another service to your stack. A basic Postgres container typically uses 300–500 MB of RAM but can scale depending on the number of connections and query complexity. For teams or heavier workflows, connection pooling is essential. Configuring max_connections = 200 in Postgres and setting n8n’s DB_POSTGRESDB_POOL_SIZE to 5–10 per worker ensures you don’t run into connection errors.
One of Postgres’s biggest advantages is its robust backup and recovery options. You can use tools like pg_dump to create consistent snapshots without taking the database offline. Scheduling automated backups to S3-compatible storage and enabling point-in-time recovery ensures your data is safe, even in the event of an issue. These features are crucial when workflows handle business-critical tasks.
For teams of two or more, Postgres prevents data conflicts. For example, if two team members save changes to different workflows at the same time, Postgres processes both updates without any issues. In contrast, SQLite could struggle in such scenarios.
The performance difference between the two databases becomes clear under load. A Tier 2 setup running 50 workflows might see average execution times of 800ms with SQLite compared to 400ms with Postgres. For webhook-triggered workflows where speed matters, this improvement is hard to ignore.
Migrating from SQLite to Postgres involves exporting your workflows and credentials, setting up the new database, and importing everything back. Since n8n doesn’t offer an automated migration tool, plan for 1–2 hours of downtime during the switch. This is why starting with Postgres from the outset makes sense if you anticipate scaling beyond solo use.
For a minimal Postgres configuration in n8n, you’ll want to:
- Set
shared_buffersto 25% of your available RAM (e.g., 2 GB for an 8 GB server). - Enable
log_statement = 'all'during initial setup to help with debugging. - Configure automated vacuuming to prevent table bloat.
These settings ensure smooth performance without requiring deep database expertise. Postgres’s ability to handle complexity, along with its advanced locking and recovery features, makes it the clear choice for production environments and growing teams.
How to Scale n8n Deployments
As your automation efforts grow, your VPS might start to struggle under the load. Knowing when to expand resources or spread out workloads is essential. Let’s break down the key strategies for scaling your n8n deployments effectively.
When to Scale: Spotting Resource Limitations
If tasks are taking longer to complete or CPU usage is consistently high, it’s a clear sign that your VPS is reaching its limits. Other red flags include database backlogs or workflows running slower than usual, which often indicate that Postgres is under strain.
Keep an eye on metrics like CPU, memory, and disk IOPS. For instance, memory pressure may cause the operating system to swap to disk, slowing everything down. Similarly, delays in processing webhooks could mean your worker threads are maxed out. Even if you have plenty of free storage, hitting the disk’s I/O capacity can cause performance issues. In such cases, upgrading to faster storage like NVMe can make a big difference.
Network latency is another factor to watch, particularly if your workflows rely heavily on external API calls. Long round-trip times can add delays to your processes. Instead of reacting to short-term spikes, monitor these metrics consistently over time to determine when your setup needs an upgrade.
Vertical Scaling: Boosting VPS Resources
Vertical scaling means upgrading your existing VPS by adding more CPU power, RAM, or faster storage. This is often the first step for deployments that are beginning to feel constrained by their current resources.
For example, if CPU usage is consistently high or memory swapping is slowing things down, adding more vCPUs or RAM can help. More RAM also allows for more concurrent workflows, reducing the risk of performance dips. Upgrading to faster storage, such as NVMe, can significantly enhance disk I/O performance, especially during heavy workflow activity.
However, vertical scaling has its limits. At some point, you might hit hardware or budget constraints, making further upgrades impractical. When that happens, it’s time to consider spreading the workload.
Horizontal Scaling: Adding Worker Nodes
Horizontal scaling involves distributing the workload across multiple VPS instances. This approach is ideal when a single server, no matter how powerful, can’t keep up with your needs.
A common setup is to use one main n8n instance for the web interface and webhook handling, while separate worker nodes handle workflow execution. In queue mode, Redis acts as the message broker, forwarding tasks from the main instance to available workers. This separation ensures that user interactions and incoming requests aren’t delayed by heavy background processing.
That said, adding worker nodes only helps if other resources, like API limits or database performance, aren’t already bottlenecks. If external factors like API rate limits are slowing things down, more workers will just shift the problem elsewhere.
Horizontal scaling can also include deploying worker nodes in different regions. Placing them closer to the services they interact with can reduce network latency, but this adds complexity. You’ll need to manage multiple servers, ensure reliable database connections, and maintain message brokering across regions.
For most teams, the best approach is to start by upgrading your VPS (vertical scaling). Then, when needed, add worker nodes (horizontal scaling) to handle growing demands.
Summary and Next Steps
Selecting the right VPS involves aligning its specifications with your current workload and future growth plans:
- Solo Users: 2 vCPU, 2–4 GB RAM, 20–40 GB NVMe
- Small Teams: 4 vCPU, 8 GB RAM, 40–80 GB NVMe
- Production: 8+ vCPU, 16–32 GB RAM, 80–160 GB NVMe
While SQLite works fine for testing or individual use, it falls short for team deployments or queue mode. Postgres is the better option here, as it eliminates issues like file locking and data corruption that can derail your automation processes.
Storage speed is another critical factor. Tasks like heavy API logging or managing extensive workflow histories can overwhelm slower storage, leading to timeouts and execution delays. NVMe storage, with its higher IOPS, is essential for handling these demands efficiently and avoiding performance bottlenecks.
If your VPS starts struggling, scale up by upgrading its hardware (vertical scaling) or expand by adding worker nodes (horizontal scaling). For most teams, vertical scaling is a good starting point, with horizontal scaling as the next step when a single server, even with improved specs, can no longer keep up.
To streamline your operations, consider deploying n8n with Docker Compose. This simplifies updates, ensures portability, and makes it easy to integrate additional services like Redis or Postgres. Always use persistent volumes to protect your data during updates.
Pick a VPS tier that suits your current needs while leaving room to grow. A well-sized VPS with Postgres and NVMe storage provides a strong foundation for scaling without the hassle of rebuilding your setup. Regularly monitor CPU, memory, and disk I/O to identify and address bottlenecks before they disrupt your workflows. With these steps, your n8n deployment is set up to grow smoothly and efficiently.
