Can You Run n8n and WordPress on the Same VPS?

Yes, you can run n8n and WordPress on the same VPS, and thousands of people already do it without drama. The real requirement is memory and separation: give the server at least 4 GB of RAM and 2 vCPU, run each app in its own container (or at least its own stack and database), and put one reverse proxy in front so WordPress answers on yourdomain.com while n8n answers on something like n8n.yourdomain.com. n8n listens on port 5678 by default, so there's no fight over ports 80 and 443 once Nginx, Caddy, or Traefik is handling the routing and the SSL certificates. The setup only falls apart in specific cases: a busy WooCommerce store sharing 2 GB of RAM with workflows that spin up headless Chrome will thrash, and at that point you want either a bigger VPS or two smaller ones.

Yes, both fit on one VPS, but the memory ceiling decides everything

Neither app is huge on its own. The problem is that both of them want RAM at unpredictable moments, and a VPS doesn't magically produce more when they ask at the same time.

Here's the honest breakdown of what each side actually consumes on a small server.

What n8n needs from the machine

n8n is a Node.js application. Self-hosted, it runs either as a bare Node process or as a Docker container from the official n8nio/n8n image, which is what most people use.

At idle, n8n sits fairly quiet, often in the 150 MB to 400 MB range of RAM. The spikes come from executions. Every workflow run loads data into memory, and if you're pulling a 20 MB JSON payload from an API or looping over 5,000 rows from a Google Sheet, that whole dataset lives in RAM while the workflow runs.

Community nodes that launch a browser, run FFmpeg, or process images can add hundreds of megabytes per execution.

By default, n8n stores everything in a SQLite file inside its data directory. That's fine for personal use. Once you're running dozens of workflows with retained execution history, SQLite gets slow and you'll want PostgreSQL instead, which is another 100 MB or so of resident memory. n8n's self-hosting documentation is the place to confirm the current supported database versions and environment variables, since those do change between releases.

One more thing worth knowing early: n8n's default single-process mode handles one execution at a time reasonably well but doesn't scale across CPU cores. Queue mode fixes that using Redis plus separate worker processes, and each worker is another full n8n process in memory. If you plan on queue mode, budget for it now rather than after your server starts falling over.

What WordPress needs on the same box

WordPress itself is light. PHP-FPM workers plus a MySQL or MariaDB database is the whole story, and the official WordPress requirements page lists PHP 7.4 or greater and MySQL 5.7+ (or MariaDB 10.4+) as the baseline, with PHP 8.x recommended.

In practice, a small WordPress site with a caching plugin and a handful of plugins runs happily in 512 MB to 1 GB, MySQL included. The variables that push it higher are plugin count, WooCommerce, page builders like Elementor, and traffic. Each PHP-FPM child process can hold 40 MB to 120 MB depending on the theme and plugin load, and MySQL's buffer pool wants breathing room of its own.

A bloated install with 45 plugins and no object cache will chew through memory the way a poorly tuned stack always does, which is the same root cause behind most sluggish WordPress load times people blame on their host.

A sizing table you can plan around

These are working numbers based on typical single-site setups, not vendor minimums.

Note: RAM is the constraint you'll hit first, but disk I/O matters more than people expect. n8n writes an execution record for every run, and if you keep full execution data with a high volume of workflows, the database grows fast. Set EXECUTIONS_DATA_MAX_AGE and prune, or you'll wake up to a full disk that takes WordPress down along with n8n.

If you're currently on shared hosting and reading this to work out whether a VPS is the right move at all, the signals that genuinely justify moving off shared hosting are worth checking first. n8n on shared hosting isn't an option in almost every case, which pushes the decision for you.

The architecture that keeps the two apps out of each other's way

There's one pattern that works reliably, and it's not complicated: one reverse proxy on ports 80 and 443, everything else on internal ports, each app in its own container with its own database.

One proxy, two hostnames

WordPress and n8n both want to be reachable over HTTPS on port 443. Only one process can bind that port, so that process is your proxy. It reads the incoming hostname and forwards to the right backend.

• yourdomain.com and www.yourdomain.com go to WordPress (PHP-FPM behind Nginx, or a WordPress container).
• n8n.yourdomain.com goes to 127.0.0.1:5678.

Your options for the proxy layer: plain Nginx with two server blocks and Certbot, Caddy (which fetches certificates automatically), Traefik (nice with Docker labels), or Nginx Proxy Manager if you want a web UI. Control panels like CloudPanel, CyberPanel, or Coolify give you the same thing with less typing.

Use a subdomain rather than a subfolder. Running n8n at yourdomain.com/n8n is possible but the WebSocket connections the editor uses make path-based proxying fussy, and you'll spend an evening debugging a broken UI for no benefit. Creating the DNS record takes a minute, and if your domain sits with the same provider as your hosting, pointing a subdomain at the same account is a two-field job in the DNS panel.

Separate databases, always

Give WordPress MariaDB or MySQL. Give n8n PostgreSQL (or leave it on SQLite for light use). Don't try to share one database server between them to save 100 MB.

When you have to restore one app from backup, or upgrade one database engine, you'll be glad they're independent. The 100 MB you'd save costs you a maintenance headache later.

Docker or native install?

Docker, for n8n. The official image is how n8n publishes releases, upgrades are a pull and restart, and container memory limits stop a runaway workflow from starving PHP. n8n updates frequently, and Docker makes staying current painless.

WordPress can go either way. A native LEMP or LAMP stack (or a panel-managed site) is the familiar route and slightly lighter on RAM. Containerised WordPress is tidier if you already run Docker.

Both are fine. What matters is that they're separate stacks on the same host.

The one setting people forget

If n8n sits behind a proxy, tell it its public address. Set N8N_HOST, N8N_PROTOCOL=https, N8N_PORT, and WEBHOOK_URL in the environment. Skip WEBHOOK_URL and n8n will hand out webhook addresses pointing at localhost:5678, which no external service can reach.

That single missing variable is behind a huge share of "my webhook doesn't fire" posts in the community forum.

Step by step: putting WordPress and n8n on one VPS

Time needed: 45 to 90 minutes for the first run, less if you've done it before.

Difficulty: intermediate. You need SSH comfort and basic DNS knowledge. No Node.js experience required.

1. Provision a VPS with at least 2 vCPU and 4 GB of RAM, running a current Ubuntu LTS release. Pick the datacentre closest to your site's visitors, because that choice is baked in once the server is created and moving later means a full migration.

2. Log in over SSH as root, create a non-root user with sudo access, and copy your SSH key across. Then disable password authentication in /etc/ssh/sshd_config and restart the SSH service. A fresh VPS with a public IP starts getting brute-forced within hours, so treat this as part of the install and not a later task.

3. Update the system with apt update && apt upgrade, then set up a firewall. Allow SSH, 80, and 443 only. Leave 5678 closed to the outside world; n8n gets reached through the proxy, not directly. Warning: open 5678 to the internet and you've published your automation editor, which holds credentials for every service you've connected.

4. Install Docker Engine and the Compose plugin from Docker's official repository rather than the distro package, which is often several versions behind.

5. Add two DNS records at your registrar: an A record for the root domain pointing at the VPS IP, and an A record for n8n pointing at the same IP. Timing note: propagation is usually minutes with a low TTL, but allow up to a few hours before assuming something is wrong. Certificate issuance will fail until DNS resolves, so don't rush the next steps.

6. Install your WordPress stack. Either set up Nginx, PHP-FPM, and MariaDB manually, install a panel like CloudPanel that does it for you, or run WordPress in Docker. Create the database and user, then download WordPress and run through the browser installer.

7. Write a docker-compose.yml for n8n with three things in it: the n8nio/n8n image, a Postgres service, and a named volume mapped to /home/node/.n8n so your workflows and encryption key survive container rebuilds. Bind n8n to 127.0.0.1:5678 rather than 0.0.0.0.

8. Set the environment variables in that Compose file: N8N_HOST=n8n.yourdomain.com, N8N_PROTOCOL=https, WEBHOOK_URL=https://n8n.yourdomain.com/, GENERIC_TIMEZONE for your region, the Postgres connection details, and N8N_ENCRYPTION_KEY. Save that encryption key somewhere safe. Lose it and every stored credential in n8n becomes unreadable.

9. Bring the stack up with docker compose up -d and confirm it's alive locally using curl http://127.0.0.1:5678/healthz. Fix problems here before involving the proxy.

10. Add a server block (or Caddy site block, or Traefik router) for n8n.yourdomain.com that proxies to 127.0.0.1:5678. Include the WebSocket upgrade headers, Upgrade and Connection, or the editor will load and then hang while trying to connect.

11. Issue TLS certificates for both hostnames. Certbot with the Nginx plugin covers it in one command; Caddy does it on first request without being asked. Confirm both https://yourdomain.com and https://n8n.yourdomain.com load clean, with no mixed-content warnings.

12. Create your n8n owner account the moment the editor is reachable, because a fresh instance is unclaimed until someone registers. Then build one throwaway workflow with a webhook trigger and fire it with curl to prove the public URL works end to end.

13. Add swap if you're on 4 GB or less: 2 GB of swap on SSD storage costs you nothing and stops the kernel from killing MySQL when memory spikes. Then set up backups covering three things: the WordPress files and database, the n8n volume, and your Compose files.

Backups deserve a specific plan rather than a vague intention. Provider-level snapshots are the fastest recovery path, though the retention window matters more than the schedule, so check how long daily snapshots are kept on whatever plan you buy before relying on it as your only copy.

When you should not put them on the same server

Sharing a box is the right default for personal sites, small businesses, and anyone learning automation. There are real cases where it's the wrong call.

A revenue-generating store. If WordPress runs a WooCommerce shop that takes orders all day, a workflow that eats memory and triggers the kernel's OOM killer can take checkout down with it. That's lost money, not an inconvenience. Container memory limits reduce the risk but don't remove it.

Heavy automation work. Workflows using Puppeteer, headless Chrome, video processing, or large file transformations behave like a completely different class of application. One of those running every 15 minutes will noticeably slow the site sharing its CPU.

Client sites. If you host other people's websites, keep your internal automation elsewhere. The blast radius of a bad n8n upgrade shouldn't include somebody's business.

Compliance boundaries. If n8n touches health, financial, or regulated personal data, running it beside a public web server complicates your security story. Separate hosts are cleaner to justify in an audit.

Note: self-hosted n8n is published under the Sustainable Use License, which permits internal business use but restricts reselling n8n as a hosted service to your own customers. If your plan involves offering n8n access to clients, read the licence terms on n8n's site first rather than assuming open source means unrestricted.

Larger operations that need staging pipelines, per-site isolation, and centralised monitoring usually outgrow the one-server setup anyway. The tooling around bigger managed WordPress stacks is built for that scale, and it's a different conversation from a single VPS.

Things people get wrong about running the two together

Mix-up: n8n can be installed on shared hosting or a cPanel account alongside WordPress.

Reality: almost never. n8n needs a long-running Node.js process, and shared hosting either blocks that outright or kills anything running past a short time limit. A VPS, a dedicated server, or n8n Cloud are the realistic options. If your reason for asking is that you want automation without paying for a server, the alternative is n8n Cloud rather than a hosting workaround.

And if you're at the earlier stage of wondering whether a WordPress site with no server at all is possible, that's a separate question worth settling first.

Mix-up: the n8n WordPress node needs n8n and WordPress on the same machine to work.

Reality: no connection between the two. n8n talks to WordPress through the REST API over HTTPS using an application password, so it works whether n8n is in the same container network or on another continent. Same server, different server, n8n Cloud: the node behaves identically. Co-hosting is a cost and convenience decision, nothing more.

Mix-up: 1 GB of RAM is fine because both apps are "small".

Reality: 1 GB will boot both and then fall over under any real load. MySQL alone wants a few hundred megabytes, PHP-FPM the same, and one n8n execution pulling a large API response can push the box past its limit. The OOM killer typically takes MySQL first, which means WordPress throws a database connection error while n8n looks fine. 2 GB with swap is survivable for testing. 4 GB is where it stops being a science experiment.

Mix-up: upload and payload limits are handled automatically once you're on a VPS.

Reality: PHP still has upload_max_filesize and post_max_size caps, and your proxy has client_max_body_size. A workflow pushing a 50 MB media file into WordPress will get rejected until you raise all of them. It's worth knowing the upload size limits in play before you build a workflow that depends on large files moving between the two.

Fixing the problems that actually come up

Problem: n8n webhooks return a URL containing localhost and external services can't reach them.

Fix: set WEBHOOK_URL=https://n8n.yourdomain.com/ along with N8N_HOST and N8N_PROTOCOL=https, then restart the container. Existing workflows will show corrected URLs straight away.

Problem: the n8n editor loads but shows a connection lost banner, or nodes never finish.

Fix: your proxy isn't passing WebSocket headers. Add proxy_set_header Upgrade $http_upgrade; and proxy_set_header Connection "upgrade"; to the Nginx location block and reload. Caddy handles this by default.

Problem: WordPress randomly shows "Error establishing a database connection" after you install n8n.

Fix: you're out of memory and MySQL is being killed. Check dmesg | grep -i kill to confirm. Add swap, lower MySQL's innodb_buffer_pool_size, reduce PHP-FPM pm.max_children, and set a memory limit on the n8n container so it can't take the whole server.

If it keeps happening, the VPS is too small.

Problem: the docker container won't start because port 5678 is already allocated, or the proxy fails to start because 80 is taken.

Fix: run ss -tulpn | grep -E ':(80|443|5678)' to find the process holding the port. Usually it's Apache from a default install competing with Nginx, or a second n8n container you forgot about. Stop one of them, don't move the other.

Problem: disk usage climbs steadily and you can't work out why.

Fix: n8n execution data plus Docker image layers. Prune executions with EXECUTIONS_DATA_MAX_AGE and EXECUTIONS_DATA_PRUNE=true, then run docker system prune to clear dangling images from past upgrades.

What this means for your setup, and what to buy

If you're running one WordPress site and want automation for form submissions, content pipelines, CRM syncing, or scheduled reports, one VPS handling both is the sensible answer. You pay for a single server, you administer a single server, and n8n's private URL sits neatly beside your public site. A 2 vCPU / 4 GB plan handles that combination without you thinking about it much.

Buy the RAM tier above whatever you think you need. Going from 4 GB to 8 GB costs a few dollars a month; discovering you're short after you've configured everything costs you an evening. Most reputable VPS providers let you scale RAM and CPU without rebuilding, so check that before you commit rather than assuming it.

Hostinger's KVM VPS range is a reasonable fit here because the plans run from a single vCPU up through eight, all on NVMe storage with full root access, and it publishes an n8n template alongside its other one-click options, so you can skip a chunk of the Docker setup if you'd rather not do it by hand. Check the current specs and template list on the VPS plan page, since both get updated. You'll also want HTTPS on the WordPress side sorted from day one, and the free Let's Encrypt route covers most sites, though certificate options for the WordPress side differ if you need something with a warranty or organisation validation.

One habit that pays off later: write down what you installed, which ports go where, and what your environment variables are set to. Six months from now, when an upgrade breaks something at 11pm, that file is the difference between a ten-minute fix and a rebuild. There's no wrong format for it, though some ways of keeping server notes hold up better than a scattering of text files.

Ready to set it up? Grab a KVM plan through this Hostinger VPS link and apply coupon code hHostCouponHub at checkout for up to 85% off your first term.

Frequently asked questions

Is 2 GB of RAM enough for n8n and WordPress together?

For testing or a very small cached site with a handful of light workflows, yes, provided you add 2 GB of swap and put n8n on SQLite instead of PostgreSQL. For anything with real traffic or workflows moving large payloads, 2 GB will trigger out-of-memory kills, and MySQL is usually the first casualty. 4 GB is the practical floor.

Do I need a separate VPS for n8n if I already host WordPress?

No, as long as your existing server has spare memory and CPU and you can install Docker on it. Split them onto separate servers when the WordPress site earns money and downtime is expensive, when your workflows use headless browsers or heavy media processing, or when you're hosting sites for clients.

Does self-hosting n8n on my own VPS cost anything?

The community edition is free to self-host, so your only cost is the server itself. Some capabilities, including SSO, log streaming, and multi-environment setups, sit in the paid enterprise tier, and the Sustainable Use License restricts reselling n8n as a service to third parties. Check n8n's pricing and licence pages for the current split, since they've changed more than once.

Will running n8n slow down my WordPress site?

Only when the two compete for the same resources at the same moment. An idle n8n instance costs you a few hundred megabytes of RAM and essentially no CPU, so visitors notice nothing. A workflow processing 10,000 records at midday on a 2 GB server will absolutely make pages crawl, which is why container memory limits and scheduling heavy jobs for off-peak hours are worth setting up early.

Set the server up once with enough headroom and separate stacks, and running n8n and WordPress on the same VPS stops being something you think about. If you're starting from scratch, claim the discounted VPS pricing here with code hHostCouponHub, pick a 4 GB plan or larger, and you'll have both running before the afternoon's out.

This page contains affiliate links. If you purchase through the links on this page, we may earn a commission, at no extra cost to you.