Why n8n and WooCommerce Clash on the Same KVM Plan

Yes, you can run n8n and WooCommerce on the same KVM plan, but the resource conflict between them is real, and it almost always shows up as memory starvation before anything else. On a 4 GB VPS, a WooCommerce store with actual orders plus a self-hosted n8n container will compete for RAM until the Linux OOM killer picks off the largest process, which is usually MariaDB, and your shop starts serving "Error establishing a database connection" while n8n keeps happily running. A 2 vCPU / 8 GB plan like Hostinger's KVM 2 is the realistic floor for a small store plus light automation, and 4 vCPU / 16 GB gives you enough headroom that the pairing stops being a gamble.

The fixes that actually work are hard memory and CPU caps on the n8n container, aggressive pruning of n8n execution data, keeping the two databases separate, and making sure your workflows never hammer the WooCommerce REST API on the same machine they're hosted on.

Both apps fit on one KVM plan, but 4 GB of RAM is where the trouble starts

Here's the thing about these two workloads: individually, neither is heavy. Self-hosted n8n is a Node.js process that idles at a few hundred megabytes. A small WooCommerce store with 200 products and 30 orders a week runs fine on modest hardware.

Put them together and the problem isn't the average load, it's what happens when both spike at the same moment.

WooCommerce spikes are traffic-driven and unpredictable. n8n spikes are data-driven and often scheduled. When a scheduled workflow pulling 2,000 orders into memory fires at 9:00 a.m. and that's also when your email campaign lands, both spikes overlap on the same vCPUs and the same RAM pool.

Rough sizing, based on how these two behave in practice:

Hostinger sells KVM VPS plans in roughly those tiers and offers one-click templates for both n8n and WordPress, which is why so many people end up putting both on one box in the first place. Specs and pricing shift with promotions, so check the current VPS page before you commit to a tier.

Note: these numbers assume a Linux VPS you administer yourself. Managed WordPress hosting won't let you install n8n at all, so if that's your setup, none of this applies and you'd need a separate server for the automation side.

RAM is what breaks first, and MariaDB is usually the process that dies

Memory is the resource these two genuinely fight over, and the failure mode is nastier than a slowdown. It's an outage.

n8n holds workflow data in memory during execution. Every item passing through a node exists as a JavaScript object, and n8n keeps input and output data for each node so you can inspect runs afterwards. Pull 5,000 WooCommerce orders with line items into a single node and you're not looking at 5,000 small records, you're looking at deeply nested JSON that can balloon to well over a gigabyte in the Node heap.

The official n8n documentation covers memory-related environment variables for exactly this reason.

Meanwhile MariaDB has reserved its InnoDB buffer pool, PHP-FPM has forked however many child processes your pool config allows, and each of those children can grow toward WooCommerce's recommended 256 MB PHP memory limit during checkout or a bulk product edit.

When the kernel runs out of memory, it doesn't ask politely. It scores processes and kills the one using the most, which on a WooCommerce box is the database. Your automation survives.

Your store doesn't.

CPU: n8n loops and PHP-FPM want the same vCPUs

On a 2 vCPU plan there isn't much to go around. A workflow with a loop over 1,000 items, a Code node doing string work, or an HTTP Request node fanning out requests will happily consume a full core for minutes at a time.

WooCommerce checkout, cart, and My Account pages can't be page-cached. They're uncached PHP, executed fresh on every request, and they need CPU right now. A single-core-saturating workflow doesn't stop checkout, but it does add seconds to time-to-first-byte, and that's the part where people abandon carts.

Disk I/O and the execution log nobody prunes

n8n writes a record of every execution to its database, including the full data for each node. Leave pruning off and that table grows without limit. Enabling EXECUTIONS_DATA_PRUNE with a sane EXECUTIONS_DATA_MAX_AGE is the single easiest win on a shared box.

Storage is the second half of it. NVMe is fast, but it's one device. n8n write bursts, MariaDB flushing, and a nightly backup all queue behind the same disk. If you've ever wondered why a WordPress site crawls at 3 a.m., overlapping I/O is often the answer, and it's the same class of problem behind most cases of sluggish WordPress performance on a VPS.

One database server, two very different workloads

Plenty of people point n8n at the MariaDB instance WordPress already uses because it's already there. That's where connection limits bite. max_connections is finite, PHP-FPM children each grab a connection under load, and if n8n is holding several while writing execution data, WooCommerce requests start getting refused.

The two workloads also want opposite things from the database. WooCommerce is read-heavy with short queries. n8n is write-heavy with large blobs. Tuning one config file for both is a compromise where neither wins.

The feedback loop that actually takes stores offline

This is the failure most people don't see coming, and it has nothing to do with plan size.

You build a workflow triggered by a WooCommerce webhook, say order.created. The workflow calls back into the WooCommerce REST API to fetch full order details, look up the customer, maybe update a meta field. Each of those API calls is a full WordPress bootstrap: PHP loads, plugins load, MySQL queries run.

Now a flash sale hits and 40 orders come in inside two minutes. That's 40 webhooks, each firing a workflow, each making three or four API calls back to the same server. n8n is now generating 160 uncached PHP requests against the machine it lives on, while real shoppers are also trying to check out.

PHP-FPM's process pool fills. Requests queue. The API calls start timing out. n8n sees a timeout and retries, because that's what you configured.

More load. More timeouts. More retries.

The store didn't fall over from lack of RAM. It fell over because your automation DDoSed it from the inside.

Three things stop this cold: set a workflow concurrency limit in n8n so only a couple of executions run at once, use the WooCommerce webhook payload instead of calling the API again for data you already have, and cap retries at one attempt with a real delay behind it.

Both apps want ports 80 and 443, so one has to sit behind the other

Before you get anywhere near resource tuning, there's a plain collision to sort out. WooCommerce serves on 443. n8n also wants 443 for its editor UI and webhook endpoints. Only one process can bind a port.

The standard arrangement is a single web server, usually Nginx or Apache, terminating TLS for both and reverse-proxying n8n on an internal port such as 5678. n8n goes on its own hostname, something like automation.yourstore.com, and WooCommerce keeps the root domain.

Two details trip people up here. n8n needs N8N_HOST, N8N_PROTOCOL and WEBHOOK_URL set correctly, otherwise the webhook URLs it hands you point at localhost and WooCommerce can't reach them. And the proxy needs WebSocket upgrade headers passed through, or the editor UI keeps disconnecting mid-workflow.

You'll also want a certificate covering the automation hostname. If you're on Hostinger and unsure how certificates work across a hostname like that, their SSL options for subdomains are worth a look before you point DNS anywhere. Same goes for how the DNS record itself gets created; the mechanics of adding a subdomain on the same account are a five-minute job once you know where the setting lives.

How to run n8n and WooCommerce on the same KVM plan without them fighting

Time needed: 60 to 90 minutes if both apps are already installed. Difficulty: intermediate. You'll need root SSH access and basic comfort with Docker Compose and a text editor.

1. Check what you're working with before changing anything. Run free -m and nproc to confirm real available memory and core count, then docker stats and top during a normal-traffic hour. Write the idle and peak numbers down; you can't tell whether a change helped without a baseline.

2. Cap the n8n container's memory and CPU. In your docker-compose.yml, set a hard memory limit and a fractional CPU limit on the n8n service, for example 1.5 GB and 1.0 CPU on an 8 GB / 2 vCPU box. A capped container that gets restarted is a far better outcome than a kernel that kills your database.

3. Set the Node heap ceiling to sit under that cap. Add NODE_OPTIONS=--max-old-space-size=1024 to n8n's environment so Node garbage-collects before Docker hard-kills the process. Without it, the container gets terminated mid-workflow with no useful error.

4. Turn on execution data pruning immediately. Set EXECUTIONS_DATA_PRUNE=true and EXECUTIONS_DATA_MAX_AGE to the number of hours of history you actually review, often 168 (a week). Also set EXECUTIONS_DATA_SAVE_ON_SUCCESS=none for high-volume workflows so only failures get stored.

5. Limit how many workflows run at once. n8n's production concurrency setting stops twenty simultaneous executions from stacking up during an order rush. Two or three concurrent executions is plenty on a shared 2 vCPU box.

6. Keep the databases apart. Give n8n its own Postgres container with its own memory limit, or leave it on SQLite if your workflow volume is modest. Do not point it at the WordPress MariaDB instance and share connections.

7. Disable WP-Cron and move it to a real system cron. Add define('DISABLE_WP_CRON', true); to wp-config.php, then schedule wp cron event run --due-now via crontab every five minutes. On a store with WooCommerce's Action Scheduler running, this alone cuts a meaningful chunk of surprise CPU spikes.

8. Offset every schedule so nothing overlaps. Put n8n's scheduled triggers on odd minutes, the WordPress cron on the five-minute mark, and backups in a window when neither runs. Overlapping cron jobs are the most common cause of a nightly slowdown that nobody can reproduce during the day.

9. Add an object cache and enable HPOS on the store side. Redis object caching cuts repeated database queries, and WooCommerce's High-Performance Order Storage puts orders in dedicated tables instead of the wp_posts table, which reduces query weight on order-heavy sites. Never page-cache cart, checkout, or account pages.

10. Add swap as a safety net, not a solution. A 2 GB swap file buys the kernel room to breathe during a spike instead of killing MariaDB outright. If swap is being used constantly rather than occasionally, you've outgrown the plan.

Warning: apply steps 2 through 6 during a quiet period, because changing container limits requires recreating the n8n container, and any workflow running at that moment gets cut off mid-execution. Confirm you have a working snapshot first; how many days of restore points you actually get depends on your plan, and Hostinger's daily backup retention is worth confirming before you touch production.

How to tell which app is actually eating the server

When the store gets slow, guessing wastes hours. Three commands settle it in about two minutes.

docker stats shows live memory and CPU per container. If n8n's memory is climbing steadily rather than spiking and returning, a workflow is holding data it shouldn't.

dmesg | grep -i "killed process" tells you whether the OOM killer has been active and which process it took. If MariaDB shows up in that output, this is a memory conflict and no amount of caching will fix it.

top -o %CPU during the slowdown, sorted by CPU, shows whether the load sits in php-fpm (store traffic or a plugin), mariadbd (query problem), or node (n8n). MySQL's slow query log answers the middle case.

Also check whether the workflow you suspect is actually the culprit. n8n's execution list shows run duration, and a workflow whose average jumps from 4 seconds to 90 seconds is competing for resources rather than causing the problem on its own.

Problem: the store returns "Error establishing a database connection" a few times a day, always briefly.

Fix: almost certainly the OOM killer taking MariaDB. Confirm with dmesg, then cap the n8n container's memory and add swap. Set MariaDB's systemd unit to restart automatically so a kill doesn't leave the store down until you notice.

Problem: n8n workflows fail with no error message, or the container restarts on its own.

Fix: the container hit its memory ceiling. Lower the batch size in the node pulling WooCommerce data, use pagination or the Loop Over Items node instead of fetching everything at once, and set --max-old-space-size below the container limit.

Problem: checkout got slow only after you added automation, and RAM looks fine.

Fix: your workflows are calling the WooCommerce REST API too aggressively. Cut concurrency, use webhook payload data instead of re-fetching, and stop any workflow that polls the store on a one-minute schedule.

Things people get wrong about this setup

Mix-up: a KVM VPS gives you dedicated resources, so two apps can't interfere with each other.

Reality: KVM dedicates your slice of the host's CPU and RAM to you, which stops noisy neighbours from other customers. Inside your own slice, your apps still compete with each other exactly like they would anywhere else.

Mix-up: more RAM in the plan fixes it.

Reality: more RAM raises the ceiling, and it does help. A workflow loading unbounded data will still eventually fill whatever you give it, and an unthrottled API loop will saturate PHP-FPM on 32 GB just as it does on 8 GB.

Mix-up: Docker containers isolate resources by default.

Reality: containers isolate filesystems and networking, not memory or CPU, unless you explicitly set limits. An n8n container with no mem_limit can consume every free byte on the host.

Mix-up: the n8n and WooCommerce same KVM plan resource conflict is a bug in one of the apps.

Reality: both behave as designed. n8n keeps execution data in memory because that's what makes debugging workflows possible, and WooCommerce bypasses caching on checkout because carts are per-user. The conflict comes from the pairing, not a defect.

When it's time to split them onto separate servers

Sharing works until it doesn't, and there are clear signals.

Split them when your store's monthly revenue makes a two-minute outage more expensive than a second small VPS. That calculation usually lands in favour of splitting far earlier than people expect.

Split them when you need n8n queue mode. Queue mode adds Redis plus one or more worker processes, and each worker is another Node instance with its own memory footprint. Stacking that on a live store's box means you're now managing four or five competing services on shared cores.

Split them when workflows have become part of the business. Order fulfilment, inventory sync, and invoicing that run through n8n shouldn't share a fate with the web server. If an OOM kill takes down MariaDB, you don't want your fulfilment pipeline in the blast radius.

A practical middle path: keep WooCommerce on the KVM plan you already have and put n8n on the smallest KVM tier by itself. Two 1 vCPU / 4 GB servers usually cost less than one 4 vCPU / 16 GB server, and the isolation is total. If you're still on shared hosting and weighing your first move, the signals that shared hosting has run out apply here too.

What this means for you and what to do next

If you're running a small store with a few dozen orders a week and five or six workflows, one KVM plan at 8 GB is fine, provided you do the container limits and pruning work in the steps above. Skip that work and you'll be debugging random database outages in a month.

If your store takes real volume, or your workflows move large batches of orders and products, size up to 4 vCPU / 16 GB or split the two apps. Choosing between the two comes down to whether you'd rather manage one bigger box or two small ones. Bigger single box is simpler to administer; two boxes fail independently, which matters more as the store grows.

If you're evaluating hosts for this pairing, the specifics you care about are per-plan RAM, full root access, snapshot support, and whether NVMe storage is standard. Hostinger's KVM VPS lineup ticks those boxes and includes one-click templates for both n8n and WordPress, which cuts the initial setup down considerably. Check current Hostinger KVM VPS pricing and apply code hHostCouponHub at checkout for the active discount, which reaches up to 85% on longer terms depending on the plan and promotion running when you order.

Whichever route you take, write down your baseline memory and CPU numbers before you migrate anything. Half the pain in this setup comes from not knowing what normal looks like. Keeping notes on your own stack pays off later, and there's a decent case for documenting your server setup properly if more than one person touches it.

Frequently asked questions

How much RAM does self-hosted n8n need alongside WooCommerce?

Budget 1.5 to 2 GB for n8n on top of whatever WooCommerce already uses, and add more if your workflows process large batches. n8n idles at a few hundred megabytes but spikes hard during executions that load big JSON payloads, so the idle figure is misleading. On an 8 GB plan, capping the n8n container at 2 GB leaves enough for MariaDB, PHP-FPM, and Redis.

Can I run n8n and WooCommerce on a 1 vCPU, 4 GB KVM plan?

For a development store or a personal project with almost no traffic, yes. For a live store taking orders, no: 4 GB leaves nothing spare once MariaDB's buffer pool, PHP-FPM workers, and n8n's Node heap are all resident, and you'll see OOM kills within weeks. Two vCPUs and 8 GB is the sensible starting point for both on one server.

Should n8n use the same MySQL database as WordPress?

No. Give n8n its own Postgres instance or leave it on SQLite. Sharing MariaDB means competing for connection slots against PHP-FPM, and the two workloads want conflicting database tuning, since WooCommerce does short reads while n8n writes large execution blobs.

Will n8n slow down WooCommerce checkout even if the server has spare RAM?

It can, through CPU and PHP-FPM contention rather than memory. A workflow that calls the WooCommerce REST API repeatedly generates uncached PHP requests that queue behind real shoppers, and checkout can't be page-cached, so those seconds land directly on the customer. Limit workflow concurrency and use webhook payload data instead of re-fetching to stop it.

Get the resource limits and pruning in place first, then decide on hardware, because a plan upgrade won't fix an unbounded workflow. If your current server is already showing OOM kills or checkout delays, moving to a larger KVM tier buys immediate breathing room while you tighten the workflows: see what the Hostinger VPS plans cost with code hHostCouponHub applied before you renew anything at full price. Last verified: February 2027.

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.