Self-hosting n8n on a VPS is attractive because the application can run continuously, receive webhooks, connect to private services, and keep automation data under your control. The server does not need to be large for a small workflow library, but memory, database design, execution volume, and backups become more important as automations grow.
The right VPS is therefore based on workload rather than the number of workflows shown in the interface. A few scheduled tasks are very different from many concurrent webhook executions, file-processing jobs, AI calls, or worker-based queues.
Key takeaways
- 2 GB RAM is a practical starting point for a small n8n VPS; 4 GB gives more flexibility.
- Docker Compose makes deployment simple, but persistent data and the database still need backups.
- PostgreSQL is a better long-term choice than treating the local application directory as disposable state.
- Webhook-heavy workflows benefit from a region close to users and external services.
- Monitor execution concurrency, memory, disk growth, and database size before upgrading.
How much RAM does n8n need?
A small personal installation can run on modest resources, but the Node.js runtime, database, reverse proxy, Docker engine, and concurrent executions all consume memory. Two gigabytes is a sensible entry point when n8n shares the VPS with a small database and proxy. Four gigabytes is more comfortable when workflows process larger payloads, use several integrations at once, or run frequently.
Memory requirements are workload-dependent. A workflow that waits for an API response uses resources differently from one that transforms large JSON documents or binary files. Watch actual memory during busy periods rather than sizing only from idle usage.
Docker, PostgreSQL and persistent data
Docker Compose is a common way to deploy n8n because the application, reverse proxy, and database can be described together. The containers themselves should be replaceable; workflow data, credentials, configuration, and the database are the parts that need deliberate persistence.
Use named volumes or mounted directories and back them up. If PostgreSQL runs on the same VPS, include database dumps or another consistent backup method rather than depending only on a disk snapshot. Test restoring the stack before it becomes business-critical.
Webhooks, workers and server location
Webhook-driven workflows introduce external latency. A VPS near the systems calling those webhooks can reduce round-trip time, although n8n often spends more time waiting on external APIs than on local network latency. Location matters more when automations connect repeatedly to services in one region or receive many interactive requests.
As execution volume grows, worker or queue-based designs can separate workload processing from the main web process. At that point the architecture may need more CPU, memory, and a dedicated Redis or database service. Start simple and add complexity only after measurements show a need.
Backups and operational reliability
Automation systems often become infrastructure quietly. A personal workflow for email can turn into business processes that create invoices, synchronize orders, or update customer data. Once that happens, backup frequency, monitoring, and recovery time matter more than saving a few dollars on the VM.
Keep configuration in version control where possible, export important workflows, protect credentials, and monitor disk space. Execution history can grow over time, so retention settings and database maintenance should be part of the operating plan.
Frequently asked questions
Is 2 GB RAM enough for n8n?
For a small self-hosted deployment, usually yes. Four gigabytes provides more headroom for PostgreSQL, Docker, larger executions, and additional services.
Should I run n8n with Docker?
Docker Compose is a convenient deployment method because it makes the application and dependencies easier to reproduce. Persistent data still needs a backup strategy.
Do I need PostgreSQL for n8n?
For a long-lived deployment, PostgreSQL is a common choice because it separates durable application data from the n8n container and scales better operationally than treating local files as disposable state.
What makes an n8n VPS slow?
Common causes include insufficient RAM, too many concurrent executions, heavy data transformations, database growth, disk pressure, and external APIs that respond slowly.