Does n8n Slow Down Your Website on the Same Server?

Yes, n8n can slow down your website when both run on the same server, but only when the box runs out of RAM or CPU headroom, not because the two are on the same machine. A self-hosted n8n instance sitting idle uses a few hundred megabytes of RAM and almost no CPU, so on a VPS with 4 GB of RAM and a couple of vCPUs, a WordPress site and a handful of light workflows coexist fine. The trouble starts when a workflow pulls a large dataset into memory, when several executions fire at once, or when you try this on a 1 GB server where PHP, MySQL and Node.js are already fighting for the same scraps.

On typical shared hosting you can't run n8n at all, since it needs a long-running Node.js process, a free port and usually Docker. Below I'll cover what n8n actually consumes, how to spot it as the culprit, and how to cap it so your site stays fast.

The honest answer: n8n competes for the same RAM and CPU, and that's the whole story

Your website and n8n aren't slowing each other down through some mysterious conflict. They're two processes asking one machine for memory, CPU cycles and disk I/O. Whoever asks harder wins.

Here's the practical breakdown. Idle n8n is quiet. The Node.js process sits there polling for triggers and waiting on webhooks.

It costs you memory, not speed. A running workflow is a different animal. n8n holds the data flowing between nodes in memory, so a workflow that fetches 20,000 rows from an API and loops through them will spike RAM and pin a CPU core for as long as it takes.

That spike is where your website feels it. If the server has spare RAM, nothing happens and your visitors never notice. If it doesn't, Linux starts swapping to disk, MySQL queries crawl, and your time to first byte jumps from 300 ms to three seconds.

Same thing with CPU. On a single-vCPU VPS, a busy n8n execution steals cycles PHP needs to build your pages.

So the real question isn't "does n8n slow down my website if on the same server." It's whether your server has enough spare capacity to absorb n8n's peaks. That's measurable, and I'll show you how further down.

Note: memory pressure is the failure mode that actually takes sites offline. When RAM runs dry, the Linux OOM killer picks a process to terminate, and it often chooses MySQL or MariaDB because they're the biggest target. Your site then throws a database connection error while n8n keeps humming along, which makes the cause look unrelated.

It isn't.

What n8n actually consumes on a server: memory, CPU, disk and a database

n8n is a Node.js application. Understanding where each resource goes tells you exactly which knob to turn later.

Memory is the number that matters most

An idle n8n container typically sits somewhere in the low hundreds of megabytes. During execution it grows in proportion to the data you push through it, because n8n keeps each node's input and output items in memory for the duration of the run.

Small payloads, tiny footprint. Pull a 50 MB JSON response or process a folder of PDFs through binary nodes, and memory climbs fast. Multiple concurrent executions multiply that. n8n's own self-hosting documentation over at the n8n project site covers configuration and resource guidance, and it's worth reading before you pick a plan size rather than after.

CPU spikes are short but sharp

Most workflows are I/O-bound. They wait on HTTP requests, which costs almost nothing. Code nodes, large loops, image or file manipulation, and heavy data transforms are CPU-bound and will occupy a core.

One core busy on a two-core VPS is survivable. One core busy on a one-core VPS means your website is now sharing what's left with the operating system.

Disk I/O and execution history creep up on you

Every execution n8n saves writes rows to its database plus any binary data to disk. Left alone for months, execution history grows into gigabytes. That slows n8n's own interface, eats disk space, and adds write pressure that your site's database also has to compete for.

n8n has pruning settings for exactly this, controlled through environment variables that cap how long execution data is kept and how many records to retain. Check the current variable names in the docs, since defaults and naming shift between versions.

The database choice changes the picture

Out of the box, self-hosted n8n uses SQLite, which is a single file on disk. It's fine for testing and light use. For anything real, n8n recommends PostgreSQL, and that means another daemon on your server using more RAM alongside your site's MySQL.

That's a detail people miss when planning capacity. A "small" n8n install can quietly become three processes: n8n itself, Postgres, and Redis if you later move to queue mode.

You can't run n8n on ordinary shared hosting, so this problem usually starts on a VPS

Shared hosting is built to serve PHP requests and stop. It doesn't give you root access, doesn't allow Docker, doesn't let you keep a Node.js daemon alive for weeks, and firewalls off the non-standard ports n8n listens on. n8n's default port is 5678, and on shared hosting you have no way to bind it or reverse-proxy it.

Some shared plans do offer a Node.js app manager, but the process limits, memory caps and lack of persistent background workers make n8n a bad fit even when installation technically succeeds. Your workflows will get killed mid-run and you'll spend more time debugging the host than building automations.

That's why nearly everyone asking this question is on a VPS. If you're currently on shared hosting and considering self-hosted automation, moving up to a virtual server is the actual prerequisite, not an upsell. Hostinger sells VPS plans with an n8n template that handles the Docker setup for you, so check their VPS page for the current specs and pricing per tier.

Note: hosting your website and n8n on one VPS also merges their fate for backups and reboots. If you restore the server to yesterday's snapshot to fix a broken plugin, you roll back your workflows and execution history too. Worth knowing how far back restore points go on your plan before you rely on that.

Whether sharing one server is fine depends on RAM, cores and how heavy your workflows are

I'd rather give you a rough matrix than a vague "it depends." These are practical starting points based on how Node.js and PHP stacks behave together, not guarantees, since your workflow design matters more than any single spec.

Two things break this table. The first is a workflow that processes big files or huge arrays, which can consume more RAM in one execution than your entire website does in a day. The second is webhook volume.

A webhook that fires 500 times an hour turns n8n from a background process into a second web application on your server.

If your site already feels slow before n8n enters the picture, adding it will make diagnosis harder. Sort the existing problem first. Most of the usual suspects behind a sluggish WordPress install have nothing to do with automation tools and everything to do with bloated plugins, missing caching and undersized PHP workers.

How to tell whether n8n is really the thing slowing your site

Guesswork wastes hours here. Run these checks while the site feels slow, not afterwards, because the evidence disappears when load drops.

1. SSH in and run htop. Sort by memory, then by CPU. If the n8n or Node.js process is at the top during a slowdown, you have your answer in about ten seconds.
2. Check the load average with uptime. Compare the first number to your vCPU count. A load average of 3.5 on a two-core VPS means processes are queuing, and something is oversubscribed.
3. Look at swap usage with free -h. Any meaningful swap use on a web server is a red flag. If swap grows during n8n executions, RAM is your bottleneck.
4. Run docker stats if n8n is containerised. This shows live memory and CPU per container, which separates n8n's usage from your web stack's cleanly.
5. Check the kernel log for OOM events with dmesg | grep -i oom. Entries here confirm the server ran out of memory and killed something, and they name the victim.
6. Correlate timing. Open n8n's executions list and note the timestamps of recent runs. Then compare them with your slow periods in uptime monitoring or server metrics. Matching timestamps are strong evidence, mismatched ones point elsewhere.
7. Test with n8n stopped. Stop the container or service for an hour during a normally slow window and measure your site's response time. If nothing improves, n8n was never the problem.

That last step is the one people skip, and it's the most conclusive. I've seen plenty of cases where the real cause was a backup job, a search engine crawler hammering the site, or a cron-heavy plugin, and n8n took the blame because it was the newest thing on the server.

Eight ways to keep n8n from dragging your website down

You don't have to choose between one server and a fast site. Most of the fix is setting boundaries so n8n can't consume everything.

Cap n8n's memory and CPU with Docker. This is the single highest-value change. Running the container with a memory limit and a CPU share means a runaway workflow gets throttled or killed instead of taking your website with it. In a compose file that's the deploy.resources.limits block, or --memory and --cpus flags on docker run.

The official Docker documentation covers the current syntax for both. Pick a limit that leaves your web stack breathing room, then raise it if legitimate workflows start failing.

Turn on execution data pruning. Stop storing every successful run forever. Configure n8n to keep only recent executions, and consider saving data for failed runs only if you don't need success logs. Smaller database, faster interface, less disk churn.

Move n8n to PostgreSQL if it's doing real work. SQLite is fine for a few workflows a day. Under concurrent executions it becomes a bottleneck and the locking gets ugly. Budget the extra RAM for Postgres before you make the switch.

Split large jobs into batches. A loop that handles 200 items at a time uses a fraction of the memory of one that loads 20,000 at once. n8n's batching node exists for this. Use it on anything touching a big dataset.

Schedule heavy workflows for quiet hours. If a workflow syncs a product catalogue or generates reports, run it at 3 a.m. instead of during your traffic peak. Nothing technical about this one, and it solves more problems than it should.

Keep binary data off the database. Configure n8n to store binary files on the filesystem rather than inline, and clean them up. Large attachments passing through workflows are a common cause of memory spikes and disk bloat. While you're at it, sanity-check the sensible upload limits your host applies, since your website and your workflows share the same disk and the same transfer ceilings.

Give n8n its own subdomain behind a reverse proxy. Serve your site on the root domain and n8n on something like automations.yourdomain.com through Nginx or Caddy. It keeps the editor off a raw port, lets you add authentication cleanly, and makes logs readable. Setting up a subdomain that points to it takes a couple of minutes in your DNS panel.

Do also handle securing that endpoint with HTTPS, because your n8n instance holds API keys and credentials for every service you've connected.

Cache your website properly. Every page your site serves from cache is a page PHP and MySQL never have to build. Full-page caching plus object caching cuts your website's own resource use so dramatically that n8n's share stops mattering. This is the cheapest performance win available and it's usually already installed and misconfigured.

Note: capping n8n's memory in Docker has a real trade-off. A workflow that exceeds the limit gets killed mid-execution, which can leave a task half-finished, for example rows written to a spreadsheet but no confirmation email sent. Build your important workflows so a retry is safe rather than assuming they always complete.

Same server, separate server, or n8n Cloud: which one actually fits you

Once you've measured the load, the decision gets straightforward.

Sharing one server makes sense when the workflows are modest and the VPS has headroom. It's cheaper, there's one machine to patch, and n8n can reach your site's database over localhost without opening it to the internet, which is genuinely handy.

A second VPS is the answer the moment automation becomes business-critical or unpredictable. Isolation means an n8n mistake can't take down your storefront. Small VPS plans are inexpensive enough that this is often the right call for anyone running client sites.

n8n Cloud removes the server question entirely, at the cost of a subscription and less control over data residency. Self-hosting is free under n8n's fair-code licence for internal business use, so the calculation is usually your time against their monthly fee. Check n8n's current licence terms directly if you plan to build automations for clients, because there are restrictions on reselling n8n as a service.

Things people get wrong about running n8n alongside a website

Mix-up: n8n slows your site because it's PHP-heavy or conflicts with WordPress.

Reality: n8n is Node.js and doesn't touch your PHP stack at all. The only interaction is competition for RAM, CPU and disk on the shared machine, plus whatever load your workflows create by hitting your own site's API.

Mix-up: if n8n is idle it costs nothing, so any server size works.

Reality: idle n8n still holds its memory allocation the whole time. On a 1 GB VPS that reservation alone can push a WordPress site into swap before a single workflow ever runs.

Mix-up: more workflows automatically means more slowdown.

Reality: thirty small workflows on schedules can be lighter than one badly built workflow processing a huge dataset. Design and payload size matter far more than workflow count.

Mix-up: a slow n8n editor means the server is overloaded.

Reality: a sluggish editor is often a bloated execution history in SQLite. Prune old executions and the interface usually snaps back without you touching the server spec.

What this means for you, and what to do next

If you're on a 4 GB VPS with a normal WordPress site and you want to automate lead notifications, spreadsheet syncs or a few API calls, run n8n on the same server. Set a Docker memory limit, turn on pruning, put it on a subdomain behind your proxy, and check htop after a week. That's the whole job, and I'd expect zero noticeable impact on your site.

If you're on 1 or 2 GB, or your workflows shift large files and datasets, or your site's revenue depends on staying up during traffic peaks, keep them apart. A separate small VPS for automation costs less than the time you'll spend explaining downtime, and it lets you restart or rebuild the automation box whenever you like without touching your site. The same logic applies if you're managing sites for other people, where tooling for bigger WordPress setups usually assumes a clean separation between the website and everything else.

Either way, the specs you start with decide how much of this you'll be fighting later. n8n plus a website on 2 GB means constant tuning. On 4 GB with two vCPUs, it mostly looks after itself.

Ready to size a server properly? Hostinger's VPS plans start cheap and include an n8n template, and the code hHostCouponHub takes up to 85% off, so grabbing 4 GB instead of squeezing into 1 GB costs less than you'd think.

Frequently asked questions

How much RAM does self-hosted n8n need alongside a website?

Plan for 4 GB total on a VPS running both, which leaves roughly 1 to 1.5 GB of headroom for n8n peaks after your web stack takes its share. You can run n8n on 2 GB with light workflows and strict Docker limits, but 1 GB with a live website is asking for OOM kills. If you add PostgreSQL and Redis for queue mode, add another gigabyte.

Can n8n run on shared hosting instead of a VPS?

Practically, no. n8n needs a persistent Node.js process, a bindable port and ideally Docker, and shared hosting gives you none of those with the reliability n8n requires. Even where a Node.js app manager exists, process and memory limits kill long-running executions, so a VPS or n8n Cloud is the realistic choice.

Will n8n webhooks slow my website down when traffic spikes?

They can, because each incoming webhook starts an execution that competes with your site for CPU and RAM. High-volume webhook automation is the clearest signal to move n8n to its own server or switch to queue mode with Redis and separate worker processes so executions don't pile up in the main instance.

Does n8n keep using resources when no workflows are running?

Yes, though very little CPU. The Node.js process stays resident in memory, typically a few hundred megabytes, and polls for scheduled triggers. That baseline memory is what makes tiny 1 GB servers a poor fit, since the reservation exists whether workflows fire or not.

If you'd rather not gamble on whether one box can carry both, start with a VPS that has room to spare and grow into it. Check the current Hostinger VPS tiers and apply hHostCouponHub at checkout, then set your Docker limits on day one and forget about this question entirely.

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.