Can One KVM 4 VPS Host n8n, a Database, and a Website?

Yes, you can run n8n plus a database server plus a website on one KVM 4 without the box breaking a sweet, provided your automations are normal business workflows rather than heavy AI or video jobs. Hostinger’s KVM 4 gives you 4 vCPU cores, 16 GB of RAM, 200 GB of NVMe storage and 16 TB of monthly bandwidth, and a self-hosted n8n instance backed by PostgreSQL usually sits under 1 GB of RAM at rest, which leaves plenty for a WordPress or static site alongside it. The three things that decide whether this works are how you store execution data, whether you cap n8n’s memory and concurrency, and whether you keep the website’s database separate from n8n’s.

Get those right and 16 GB is generous. Skip them and a single workflow pulling a 200 MB API response can take the whole server down with it.

KVM 4’s 4 vCPU cores and 16 GB of RAM are the reason this combination works at all

The plan sits in the middle of Hostinger’s VPS range, and that middle position is what makes it the sweet spot for a stack like this. Here’s what you get:

Compare that with KVM 2 (2 vCPU, 8 GB RAM, 100 GB NVMe). KVM 2 will run n8n and a small site fine. It gets uncomfortable the moment you add a busy Postgres instance, a staging copy of your site, and a couple of AI nodes that each hold a few hundred megabytes of JSON in memory.

KVM 4 doubles every number, and RAM is the resource that runs out first in self-hosted n8n setups.

The 200 GB NVMe matters more than people expect. n8n writes every execution to the database, including the input and output data of each node. A workflow running every five minutes with a modest payload will quietly add hundreds of megabytes a month to your Postgres data directory. Add WordPress uploads, Docker images, and a few database dumps, and 200 GB stops looking huge.

Bandwidth is rarely the limit here. 16 TB covers a site with real traffic plus thousands of webhook calls a day with room to spare.

Note: Hostinger’s VPS backup frequency and included add-ons vary by plan and change with promotions. Check the current KVM 4 plan page before you buy if a specific inclusion is a dealbreaker for you, and it’s worth knowing how far back the automatic copies go so you can decide whether you need your own dumps on top.

Splitting RAM between n8n, the database and the site is the part people get wrong

Everything on a single VPS shares one pool of memory. Nothing stops n8n from eating all of it and getting killed by the kernel’s OOM killer, which will happily take PostgreSQL or PHP-FPM down in the same swing.

Rough idle figures to plan with. These move around with versions, plugins and traffic, so treat them as planning numbers, not promises:

Add it up and a realistic working total lands somewhere between 2.5 GB and 4 GB. On a 16 GB box, that’s a lot of unused headroom, and the headroom is the point. Workflow spikes are where servers die.

Three limits I’d set on day one:

Cap n8n’s Node.js heap. Set NODE_OPTIONS=--max-old-space-size=4096 in the n8n container. That gives n8n up to 4 GB and stops one runaway workflow from claiming 12. n8n’s own documentation covers this variable and the memory behaviour behind it.

Cap concurrent production executions. N8N_CONCURRENCY_PRODUCTION_LIMIT sets how many production executions run at once. Something in the 5 to 10 range is sensible on 4 cores. Without it, a webhook burst starts dozens of executions simultaneously and CPU load goes vertical.

Give PostgreSQL a modest shared_buffers. The usual advice of a quarter of system RAM assumes a dedicated database server. Here it isn’t dedicated. On a KVM 4 running all three roles, 1 GB to 2 GB is a reasonable starting point, and you can raise it later if queries slow down.

Add 2 GB of swap as well. Swap on NVMe is slow compared to RAM, and it will not save a badly written workflow. What it does do is give the kernel somewhere to put idle pages instead of killing a process outright.

PostgreSQL is the database n8n actually wants once you’re past testing

n8n ships with SQLite by default. It works, it needs no setup, and it’s fine for kicking the tyres. For a server you intend to keep, switch to PostgreSQL. n8n’s docs list PostgreSQL as the supported production database, and support for MySQL and MariaDB as n8n’s own backing store was dropped, so don’t plan around it.

The environment variables you need on the n8n side:

DB_TYPE=postgresdb
DB_POSTGRESDB_HOST=postgres
DB_POSTGRESDB_PORT=5432
DB_POSTGRESDB_DATABASE=n8n
DB_POSTGRESDB_USER=n8n
DB_POSTGRESDB_PASSWORD=your-strong-password

Do the switch before you build anything. Migrating live workflows from SQLite to Postgres later is possible, but it’s fiddly, and there’s no supported one-click path. Starting on Postgres costs you ten minutes now.

Should the website share the same database server?

Keep them apart. Not necessarily on separate machines, but in separate database instances or at minimum separate databases with separate users.

Two reasons. WordPress runs on MySQL or MariaDB, and n8n runs on PostgreSQL, so you’re already dealing with two engines unless your site is static or built on something Postgres-friendly. And when n8n’s execution table balloons to several gigabytes, you want to be able to prune, vacuum or restore it without touching the thing that serves your homepage.

In Docker, that means one postgres service for n8n and one mariadb service for WordPress. Each gets its own volume. Each can be dumped and restored on its own.

Total extra RAM cost is a few hundred megabytes, which on 16 GB is nothing worth arguing about. PostgreSQL’s official project site has the tuning documentation if you want to go deeper on memory settings.

Note: if you run both engines, back both up. A snapshot of the whole VPS covers you, but a file-level snapshot of a running database can be inconsistent. Scheduled pg_dump and mysqldump jobs are the reliable version, and they’re small enough to store off-server.

Here’s how to set up n8n, a database server and a website on one KVM 4

Time: 60 to 90 minutes for the whole stack, longer if DNS is slow to update.

Difficulty: intermediate. You need to be comfortable with SSH, a terminal text editor, and editing DNS records. No programming required.

You’ll end up with two hostnames on one IP: something like n8n.yourdomain.com for the automation instance and yourdomain.com for the site, both on HTTPS, both behind one reverse proxy.

1. Order KVM 4 and pick your operating system. In hPanel, choose an OS template during VPS setup. Ubuntu 24.04 LTS with Docker is a solid base. Hostinger also lists application templates, including an n8n one, which pre-installs the stack for you. If you want control over how the database and the website are laid out, take plain Ubuntu instead and build it yourself.

2. Log in over SSH and update everything. Run ssh root@your-server-ip, then apt update && apt upgrade -y. Reboot if the kernel updated. Provisioning usually finishes within a few minutes of purchase, and the panel shows you the root password and IP.

3. Create a normal user with sudo, then lock down root. adduser yourname, usermod -aG sudo yourname, copy your SSH key across, then set PermitRootLogin prohibit-password and PasswordAuthentication no in /etc/ssh/sshd_config. Warning: test the new login in a second terminal window before you close the first one. Locking yourself out means a rebuild or a console session.

4. Turn on the firewall. ufw allow OpenSSH, ufw allow 80, ufw allow 443, then ufw enable. Leave 5678 (n8n) and 5432 (Postgres) closed to the internet. Both are reachable inside the Docker network, which is all they need.

5. Add 2 GB of swap. fallocate -l 2G /swapfile, chmod 600 /swapfile, mkswap /swapfile, swapon /swapfile, then add the line to /etc/fstab so it survives a reboot.

6. Install Docker and the Compose plugin. Use Docker’s official apt repository rather than the distro package, which is often behind. Confirm with docker compose version.

7. Create your project folder and an .env file. Something like /opt/stack/. Put every password, hostname and the n8n encryption key in .env, and chmod 600 it. Warning: generate N8N_ENCRYPTION_KEY yourself and save a copy somewhere safe. Lose it and every stored credential in n8n becomes unreadable, even with a working database backup.

8. Write your docker-compose.yml with four or five services. A reverse proxy (Caddy is the least painful for automatic certificates), postgres for n8n, n8n itself, and then your website containers. Give each database a named volume. Put everything on the same Docker network so n8n can reach postgres:5432 by name.

9. Set n8n’s public URL variables. N8N_HOST=n8n.yourdomain.com, N8N_PROTOCOL=https, WEBHOOK_URL=https://n8n.yourdomain.com/, plus GENERIC_TIMEZONE and TZ set to your zone. Skipping WEBHOOK_URL is the single most common cause of webhooks that trigger in the editor but fail from outside.

10. Point your DNS records at the server. One A record for the root domain, one for the n8n subdomain, both to your VPS IP. Propagation is usually minutes but can take up to 24 to 48 hours depending on your previous TTL. If you’re hosting the domain with Hostinger, adding a second hostname takes a couple of clicks in the DNS zone editor.

11. Bring the stack up and watch the certificates issue. docker compose up -d, then docker compose logs -f caddy. Certificates only issue once DNS resolves to your IP, so if you see repeated failures, the records haven’t updated yet. Wait, then restart the proxy container.

12. Install the website. For WordPress, hit the domain and run the installer. For a static site, drop the files in the volume the proxy serves. If you’d rather run the site through a control panel instead of containers, install one at this stage and keep n8n on its own subdomain in Docker.

13. Set your PHP upload limits. WordPress defaults are conservative, and a media-heavy site will hit them. Our notes on sensible upload ceilings explain where the practical lines sit.

14. Turn on execution pruning and schedule backups. Add EXECUTIONS_DATA_PRUNE=true, EXECUTIONS_DATA_MAX_AGE (in hours, default 336, which is 14 days) and EXECUTIONS_DATA_PRUNE_MAX_COUNT (default 10000) to the n8n service. Then add a nightly cron job running pg_dump and mysqldump, plus a monthly restore test.

15. Verify HTTPS on both hostnames. Load the site and the n8n editor. Fire a test webhook from outside the server, using your phone off Wi-Fi if you want a genuinely external request. Hostinger’s VPS panel shows free SSL options too, and if you’re weighing a paid certificate against an automatic one, the certificate question is worth five minutes of reading first.

That’s the whole build. Fifteen steps, one server, three jobs.

Where this setup stops being a good idea

KVM 4 has a ceiling, and it’s worth knowing where it sits before you commit.

Heavy AI workflows. Nodes that hold large documents in memory for embedding or summarising are memory-hungry by nature. Chunk your inputs and process in batches. If you’re running a local language model on the same box, forget it: KVM 4 has no GPU, and CPU inference will starve everything else.

Big binary payloads. n8n keeps binary data in memory by default. Pulling a 500 MB file through a workflow on a shared 16 GB server is asking for trouble. Use n8n’s filesystem binary mode, or better, have the workflow hand off large files to object storage and pass URLs around instead.

Queue mode with multiple workers. Once you genuinely need Redis plus separate worker containers, you’re adding another 500 MB to 1 GB and a lot more moving parts. KVM 4 can host a small queue-mode setup. Beyond two or three workers, move n8n to its own VPS and give the site the old one.

A high-traffic website. If the site alone needs 8 GB and four cores at peak, the automation instance becomes the thing that suffers. Watch your load average across a full week before you decide.

One point of failure. Everything on one server means one reboot takes down your site and your automations together. If a stalled webhook costs you money, split the roles. Anyone still on shared hosting and wondering whether this jump makes sense should read our take on the right moment to move up first.

Things people get wrong about this stack

Mix-up: n8n is a lightweight app, so any small VPS will do.

Reality: n8n at rest is light. n8n under load depends entirely on your workflows. A single node handling a large API response can multiply memory usage several times over, which is why the heap cap and concurrency limit matter more than the plan size.

Mix-up: the default SQLite database is fine to keep, since it’s what n8n installs with.

Reality: SQLite handles one writer at a time. With scheduled workflows, webhooks and manual runs overlapping, you’ll hit lock contention and slow editor loads. n8n’s self-hosting documentation points to PostgreSQL for production use.

Mix-up: a VPS snapshot is a complete backup of everything.

Reality: a snapshot of a running database can be inconsistent, and it doesn’t protect you from losing your n8n encryption key. Logical dumps plus a copy of .env stored off the server are what actually let you rebuild.

Mix-up: you need a separate VPS for the database server.

Reality: on 16 GB, running PostgreSQL as a container next to n8n is normal practice and removes network latency between them. Separate machines make sense at a size where the database needs its own tuning and its own restart schedule.

When something breaks, it’s usually one of these three

Problem: webhooks work inside the n8n editor but external services get a 404 or connect to the wrong address.

Fix: WEBHOOK_URL is missing or wrong. Set it to your full public HTTPS URL with a trailing slash, restart the container, and copy the production webhook URL fresh from the node afterwards.

Problem: n8n restarts on its own, or the site goes down while a big workflow runs.

Fix: you’re hitting memory limits. Check dmesg -T | grep -i oom for kill messages. Lower N8N_CONCURRENCY_PRODUCTION_LIMIT, set the Node heap cap, and switch binary data to filesystem mode.

Problem: disk usage keeps climbing and Postgres queries get slower every week.

Fix: execution history is piling up. Turn on pruning, then reclaim the space with a VACUUM FULL on the executions tables during a quiet hour. Docker also hoards old images, so docker system prune is worth running after updates.

Problem: the site loads slowly even though the server looks idle.

Fix: check whether it’s the server or the application. Load average, disk I/O and PHP-FPM worker counts tell you the first part. Plugin bloat and missing caching cause most of the rest, and the same patterns that make a sluggish WordPress install drag on any host apply here too.

What this means for your setup, and what to do next

If your automations are the everyday sort, form submissions to CRM, scheduled reports, Slack alerts, invoice syncing, then n8n plus a database server plus a website on one KVM 4 is a comfortable fit with room left over. You’ll be running at a fraction of capacity most of the day, which is exactly where you want to be on a server that hosts something customer-facing.

The economics are the strong part. Self-hosted n8n is free under its Sustainable Use License, so you pay for the VPS and nothing per workflow execution. Compare that with per-execution pricing on hosted automation platforms and the maths favours one KVM 4 pretty quickly, as long as you’re willing to own the updates and the backups.

Before you build, decide two things. First, whether this server is allowed to go down. If not, split the site and the automations across two smaller VPS plans instead.

Second, whether you’ll keep notes. Container versions, environment variables and cron jobs are all easy to forget six months later, and keeping a written record of your own setup saves a bad afternoon when something breaks and you can’t remember which variable you changed.

If KVM 4 looks like the right size, grab it with the coupon code hHostCouponHub for up to 85% off and pick the longest term you’re comfortable with, since VPS renewal rates are always higher than the first-period price.

Frequently asked questions

How much RAM does self-hosted n8n need on its own?

A single-instance n8n with PostgreSQL typically runs in under 1 GB when idle. n8n’s docs suggest 2 GB as a workable baseline for light use, but memory demand scales with payload size and how many executions overlap, so plan for headroom rather than the minimum.

Can I run n8n and WordPress on the same VPS without them clashing?

Yes, as long as they use separate database instances and separate hostnames. Run n8n on a subdomain behind a reverse proxy, keep its Postgres data apart from WordPress’s MariaDB, and cap n8n’s memory so a heavy workflow can’t starve PHP-FPM.

Is KVM 2 enough, or do I need KVM 4 for all three?

KVM 2 (2 vCPU, 8 GB RAM) runs n8n, Postgres and a low-traffic site. KVM 4 doubles both CPU and RAM, which is what you want if the site gets real traffic, if any workflow touches AI nodes or large files, or if you plan to add a staging copy later.

Do I need Docker, or can I install n8n directly with npm?

Both work. n8n supports npm installation and Docker, but Docker Compose makes running n8n, PostgreSQL, a reverse proxy and your website side by side far less painful, and updates become a matter of pulling a new image tag rather than reinstalling Node packages.

Build the stack in the order above, test one webhook from outside the server before you migrate any real workflows, and you’ll have all three jobs running on a single box by the end of the afternoon. Check the current KVM 4 pricing here if you’re ready to start.

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.