n8n VPS Setup for a Lean Automation Stack

If you want an n8n vps setup that is cheap, durable, and not overbuilt, the current best practice is a small Linux VPS running Docker Compose, PostgreSQL, and a reverse proxy that terminates HTTPS.¹² In 2026, the lean-stack version of this usually means one VPS, one database, one proxy, and no public exposure of n8n’s internal port.³⁴

What is the best n8n vps setup for a lean automation stack?

The best n8n vps setup is a Docker Compose deployment on a Linux VPS with n8n and PostgreSQL on a private network, fronted by Nginx, Caddy, or Traefik for HTTPS.¹² That architecture is the most consistent recommendation across current guides because it keeps the workflow engine stable, the database persistent, and the public surface area small.¹²⁴

For professionals and solopreneurs, the practical goal is not “run n8n somewhere” but “run it predictably enough that automations do not break at odd hours.” Current 2026 tutorials frame self-hosting as a way to avoid SaaS pricing while keeping control of workflows, credentials, and updates.³⁴ The lean-stack thesis is simple: if the automation layer is essential, it should live on infrastructure you can inspect, back up, and restart without waiting for a vendor ticket.³⁴

A useful way to think about the stack is:

Layer	Recommended choice	Why it matters
Compute	Small Linux VPS	Low cost, full control
Runtime	Docker	Repeatable deployment
Orchestration	Docker Compose	Easy multi-container management
Database	PostgreSQL	Durable persistence
Public access	Nginx, Caddy, or Traefik	HTTPS and routing
Network	Private Docker network	Keeps services isolated

That table reflects the pattern repeated in recent VPS tutorials: n8n in a container, PostgreSQL in a container, and a proxy in front of both.¹²⁷ It is also the cleanest structure if you want one automation layer that can survive a VPS reboot, a proxy restart, or a routine update without drifting into fragile manual configuration.¹³

How much server do you need for n8n vps setup?

A safer low-cost baseline is 2 vCPU and 4 GB RAM, while 2 GB RAM can work for lighter workloads if you avoid queue-heavy or AI-heavy nodes.⁵⁶⁷ One 2026 guide states the minimum as “2 vCPUs and 4GB of RAM,” while another says “2GB RAM minimum (4GB if you run queue mode, Puppeteer or heavy AI nodes).”⁵⁶

That difference is not a contradiction so much as a workload split. If you only need a few scheduled workflows, simple API syncs, and webhook handling, 2 GB may be enough to start.⁶⁷ If you expect browser automation, larger payloads, or multiple concurrent executions, 4 GB is the more reliable floor.⁵⁶

A practical sizing guide looks like this:

• 2 vCPU / 4 GB RAM: best default for most small production stacks.⁵⁶
• 2 vCPU / 2 GB RAM: acceptable for light use and careful tuning.⁶⁷
• More than 4 GB RAM: useful if you add heavy AI nodes, queue mode, or more workflows over time.⁶⁷

Recent guides also describe the setup as fast to complete once the VPS, Docker, DNS, and proxy pieces are ready; one 2026 tutorial says the process can be finished in 15–30 minutes.⁸ Cost framing is similarly restrained: one guide estimates roughly $4–12/month for the server and $0 for n8n itself.⁹

What should you install first on the VPS?

You should start with SSH access, a non-root user, firewall rules, Docker, and Docker Compose before you touch n8n itself.⁷¹⁰¹⁵ The broader tutorial pattern is consistent: harden the server first, then deploy the app, then add DNS and HTTPS, then back it up.⁷¹⁰¹⁵

A clean setup sequence is:

1. Log in over SSH.
2. Update the OS.
3. Create a non-root user and enable sudo.
4. Lock down the firewall with UFW.
5. Install Docker and Docker Compose.
6. Create a project directory for n8n.
7. Add the Compose file and environment variables.
8. Bring up the stack.
9. Put the proxy and SSL in front of it.⁷¹⁰¹⁵

That order matters because it reduces the chance of exposing n8n too early. Current guidance is to keep port 5678 off the public internet and expose only 80 and 443 through the proxy and firewall.³⁴⁷ In other words, n8n should listen locally or on a private network, while the reverse proxy handles the public-facing traffic.³⁴

How do DNS, HTTPS, and the reverse proxy fit together?

DNS and TLS are required, not optional, in a real n8n vps setup.²³¹⁰ The standard pattern is to create an A record such as n8n.example.com pointing to the VPS public IP, then issue a free Let’s Encrypt certificate through the reverse proxy.²³¹⁰

The proxy layer is what makes the stack feel production-ready. It terminates HTTPS, forwards traffic to n8n on the private side, and keeps the application port from being directly reachable.¹³⁴ Guides using Nginx, Caddy, or Traefik all converge on the same outcome: a clean public URL with encrypted traffic and no exposed internal service port.¹²³

The operational implication is straightforward:

• Open 80/443 for the proxy.
• Keep 5678 private.
• Point the subdomain at the VPS IP.
• Let the proxy handle certificates.²³⁴

That arrangement is especially useful if you expect webhooks, because n8n’s callback URLs must match the public address users and services can reach. If the proxy or hostname is wrong, webhooks break even when the container is otherwise healthy.⁴⁷

Which environment variables matter most in n8n?

The most important variables are WEBHOOK_URL, N8N_HOST, N8N_PROTOCOL=https, and N8N_ENCRYPTION_KEY.⁴⁷¹⁰ Current guides call these out because they affect webhook routing, public URL generation, and credential protection in self-hosted deployments.⁴⁷¹⁰

A simple way to think about them:

• N8N_HOST tells n8n the hostname it should consider canonical.
• N8N_PROTOCOL=https ensures generated URLs match your TLS setup.
• WEBHOOK_URL helps external services hit the correct callback address.
• N8N_ENCRYPTION_KEY protects stored credentials and should be persistent.⁴⁷¹⁰

If you change domains later without updating these values, you can end up with mismatched webhook endpoints or stale links in nodes and credentials.⁴¹⁰ That is why most current tutorials treat the .env file as part of the deployment, not an optional convenience.⁷¹⁰

What does the practical build look like end to end?

The practical build is a small set of moving parts: Docker, Docker Compose, PostgreSQL, a reverse proxy, TLS, and backups.¹²⁷¹⁰ This is the version that aligns with the “one VPS, one database, one reverse proxy” approach used in current 2026 self-hosting guides.³⁹

A realistic implementation flow is:

• Provision Ubuntu 22.04 or 24.04 on a low-cost VPS.
• SSH in and harden access.
• Install Docker and Docker Compose.
• Create a private network for n8n and PostgreSQL.
• Define the Compose file with persistent volumes.
• Add the environment variables.
• Configure DNS for your subdomain.
• Put Nginx, Caddy, or Traefik in front.
• Issue a Let’s Encrypt certificate.
• Verify webhook access and log output.
• Set up backups and update discipline.^1271015

The reason PostgreSQL keeps appearing in 2026 guides is stability. Multiple tutorials recommend PostgreSQL over SQLite for self-hosted production-style use because it is the standard persistence layer in these deployments.²⁷¹⁰ SQLite may boot a simple install, but the current production baseline is PostgreSQL on a private Docker network.²⁷¹⁰

What are the main trade-offs between quick and durable setups?

The trade-off is speed versus resilience: a quick demo can be up fast, but a durable n8n vps setup is worth the extra few steps.⁵⁸⁹ The current guides are not really advocating complexity; they are advocating avoiding avoidable failure points, especially around storage, network exposure, and webhook routing.¹³⁴

Approach	Speed	Cost	Reliability	Best for
Bare n8n on public port	Fastest	Lowest	Weak	Throwaway testing
n8n + SQLite	Fast	Low	Moderate	Very light use
n8n + PostgreSQL + proxy	Slightly slower	Low	Strong	Real workloads
n8n + queue mode + larger VPS	Slower	Higher	Strongest	Heavy automation

The “tiny VPS always works” assumption is where many setups become brittle. Recent 2026 guidance repeatedly recommends 2–4 GB RAM for reliability, especially if you use queue mode or heavier nodes.⁵⁶ For a lean automation stack, that is still inexpensive compared with paying for a premium hosted automation plan that you may not fully use.³⁹

What should you do after the first deployment?

You should test webhooks, confirm HTTPS, verify backups, and plan updates before you call the setup finished.⁷¹⁰¹⁵ The best self-hosted stack is not the one that starts once; it is the one that survives the first update and the first restore test.¹⁰¹⁵

After the initial launch, check these items:

• Visit the subdomain over HTTPS.
• Confirm n8n generates the correct public URLs.
• Trigger a test webhook from an external service.
• Inspect Docker logs for database or proxy errors.
• Back up the PostgreSQL data volume.
• Document how to update the containers safely.⁷¹⁰¹⁵

That final step matters because self-hosting is an operations habit, not a one-time install. The 2026 tutorials that are getting the most traction all cover the same extra pieces beyond “docker compose up -d”: firewall, proxy, SSL, persistence, and backup strategy.⁷¹⁰¹⁵ If you want lean rather than fragile, those are the parts to keep.