Self-hosting n8n under ten dollars per month is realistic for personal automations and small business workflows when execution volume is modest. The server needs enough memory for n8n, Docker, PostgreSQL, a reverse proxy, and occasional execution spikes.
The budget works best when workflows spend most of their time waiting on external APIs rather than processing large files or running many tasks concurrently.
Key takeaways
- 2 GB is a practical target for small n8n deployments under $10.
- 4 GB gives more headroom when available within budget.
- PostgreSQL and Docker should be included in memory planning.
- Execution history can grow the database over time.
- Backups become important as workflows become business infrastructure.
What fits under $10
A 2 GB VPS can handle scheduled workflows, webhooks, API integrations, and light data transformations. Four gigabytes is more comfortable when many workflows run concurrently.
The number of workflows is less important than execution frequency and payload size.
Docker and PostgreSQL
A common stack includes n8n, PostgreSQL, and a reverse proxy in Docker Compose. The containers are easy to recreate, but database and configuration state must be persisted.
Keep backups outside the live VPS.
Where the budget breaks down
Large binary files, AI workflows, heavy transformations, many simultaneous webhooks, and queue workers can exceed small-server resources.
Upgrade based on observed memory, CPU, and execution latency rather than arbitrary workflow count.
Operational value vs cloud n8n
Self-hosting saves subscription cost and gives control, but transfers upgrades, security, backups, and monitoring to you.
A low-cost VPS is a good fit when that operational responsibility is acceptable.
Frequently asked questions
Can n8n run under $10 per month?
Yes for many small self-hosted deployments.
Is 2 GB enough for n8n?
Yes for light automation; 4 GB is more comfortable as execution volume grows.
Does n8n need PostgreSQL?
PostgreSQL is a common durable database choice for long-lived deployments.
When should I upgrade?
Upgrade when concurrency, large payloads, database growth, or workers create sustained memory or CPU pressure.