Yes, running n8n alongside Nextcloud on one server works well, and thousands of people do it on a single small VPS. The setup that causes the fewest headaches is Docker Compose plus one reverse proxy: Nextcloud answers on cloud.yourdomain.com, n8n answers on n8n.yourdomain.com, the proxy owns ports 80 and 443, and n8n stays on its internal port 5678 where the public internet can't reach it directly. For a household or small team Nextcloud plus light-to-moderate automation, I'd start with 2 vCPUs, 4GB of RAM, and enough disk for your files, then watch actual usage before scaling up.
The trap most people fall into is trying to share one MariaDB container between the two apps, which won't work because recent n8n releases only support SQLite and PostgreSQL, not MySQL or MariaDB.
Both apps can share a box because they want different things from it
Nextcloud and n8n don't naturally step on each other. Nextcloud is a PHP application: a web server, PHP-FPM, a database, and a big folder of user files. It sits mostly idle, then spikes when someone syncs a folder or a desktop client uploads a batch of photos. n8n is a Node.js application with a small footprint at rest, spiking when a workflow runs, and its default SQLite database lives in a single volume.
Different runtimes, different databases, different traffic patterns. That's why the pairing works.
The real conflicts are boring and fixable: two apps both wanting port 80, two apps both wanting to be "the" HTTPS site on the IP, and both apps competing for RAM during a spike. Every one of those has a standard answer, and I'll walk through all three.
How much RAM and CPU do you actually need?
There's no single published number that covers both apps, because it depends entirely on how many people use Nextcloud and what your workflows do. What I can give you is a practical floor and a set of tripwires.
Two vCPUs and 4GB of RAM is the sane starting point for a Nextcloud instance with a handful of users plus n8n running scheduled and webhook workflows. You can technically squeeze both onto 2GB. I've seen it done.
But Nextcloud's PHP memory limit alone is usually set at 512MB, background jobs pile on top, and one heavy n8n workflow that pulls a large API response into memory will push the box into swap. When that happens, Nextcloud gets slow first and you'll spend an afternoon chasing the wrong culprit.
Go up to 4 vCPUs and 8GB if any of these are true: more than about ten active Nextcloud users, Collabora or OnlyOffice document editing running on the same server, workflows that process files or images, or n8n running in queue mode with separate worker containers.
Note: heavy Nextcloud add-ons change the maths completely. Collabora Online in particular is a memory hog, and running it next to n8n on a 4GB box is asking for trouble. Give document editing its own server or budget 8GB from the start.
Disk is the other half of the sizing question. Nextcloud grows with user files, versions, and the trash bin, and those last two surprise people. n8n's storage need is small until you keep every execution's full data forever. If you're weighing this against a cheaper plan, it's worth reading the case for moving off a shared plan first, because neither app can run on standard shared hosting. n8n needs a Node process you control, and shared hosts don't hand that out.
Should you run them in Docker or install them directly?
Docker Compose, without much hesitation. Two apps on one machine means two sets of dependencies, and a bare-metal install has n8n's Node version and Nextcloud's PHP version living in the same OS package tree. That's manageable, but upgrades get tense.
With Compose you get separate containers, a private network between them, per-container memory limits, and a single YAML file that documents your whole setup. Updating n8n becomes pulling a new image tag instead of praying about a Node upgrade.
There is one caveat worth knowing before you commit. Nextcloud All-in-One (AIO) is the officially recommended deployment for many users, and it's excellent, but it manages its own container stack through a master container and expects specific ports for the setup interface. Putting AIO behind a reverse proxy you also use for other apps is documented and doable, but it's fussier than the plain nextcloud image. For a shared box with n8n, I prefer the standard nextcloud:apache image with my own proxy in front.
You keep full control of ports and TLS.
One reverse proxy on two subdomains is the layout that gives the least trouble
Here's the shape of the finished setup:
| Piece | Public address | Port it uses | Exposed to the internet? |
|---|---|---|---|
| Reverse proxy (Caddy or Nginx) | both hostnames | 80, 443 | Yes |
| Nextcloud container | cloud.yourdomain.com | 80 (internal only) | No |
| n8n container | n8n.yourdomain.com | 5678 (internal only) | No |
| MariaDB or PostgreSQL for Nextcloud | none | 3306 / 5432 (internal only) | No |
| Redis for Nextcloud caching | none | 6379 (internal only) | No |
Two DNS A records point at the same server IP. The proxy reads the incoming hostname and sends the request to the right container. Both get their own certificate.
If you've set up extra hostnames before, pointing several names at one account works the same way here, except the destination is a container instead of a folder.
Caddy is my default choice for this because automatic HTTPS is built in and the config file is four lines per site. Nginx Proxy Manager is the friendlier pick if you'd rather click through a web UI than edit text files. Traefik is the most powerful and the most confusing on day one.
Any of them work.
Can you use subfolders instead of subdomains?
You can run Nextcloud at the root and n8n at /n8n, and some people do. I'd advise against it. n8n's editor and webhook URLs assume they own a path root, and while N8N_PATH exists for subfolder installs, you'll spend time chasing broken asset paths and webhook URLs that half work. Subdomains are free, and DNS propagation for a new record usually settles within minutes to an hour.
Take the easy road.
How to set up n8n alongside Nextcloud on one server, step by step
Estimated time: 60 to 90 minutes for a first-timer, closer to 25 if you've done Docker Compose before. Add up to an hour on top if DNS is slow to propagate.
Difficulty: intermediate. You need to be comfortable with SSH, a text editor in the terminal, and editing a YAML file without breaking indentation.
Buy or provision a VPS with at least 2 vCPUs and 4GB of RAM, and pick a clean Ubuntu LTS image. Note the IP address it gives you.
Log in over SSH as root, create a non-root user with sudo rights, and add your SSH key to that user. Then disable root SSH login and password authentication in
/etc/ssh/sshd_configand restart the SSH service.Install Docker Engine and the Compose plugin using Docker's official apt repository instructions. Confirm it worked by running
docker compose version.Set up a firewall before you deploy anything. With UFW, allow 22, 80, and 443, then enable it. Warning: if you enable UFW before allowing port 22, you'll lock yourself out of the server and will need console access from your host's control panel to recover.
Create the two DNS A records at your registrar:
cloudandn8n, both pointing to the server's IP address. Do this now so the certificates can be issued later without waiting.Make a project folder such as
/opt/stack, then create adocker-compose.ymlinside it with five services:caddy,nextcloud,db,redis, andn8n. Put all of them on one shared Docker network.Configure the Nextcloud service with named volumes for
/var/www/htmland its data directory, and set the database environment variables to match yourdbservice. AddTRUSTED_PROXIESpointing at your Docker network subnet, plusOVERWRITEPROTOCOL=httpsandOVERWRITECLIURL=https://cloud.yourdomain.com, or the login page will redirect tohttp://and loop.Configure the n8n service with a volume mounted at
/home/node/.n8n, then setN8N_HOST=n8n.yourdomain.com,N8N_PROTOCOL=https,WEBHOOK_URL=https://n8n.yourdomain.com/,GENERIC_TIMEZONEfor your region, andN8N_PROXY_HOPS=1. Do not publish port 5678 to the host; the proxy reaches it over the internal network.Generate a long random string and set it as
N8N_ENCRYPTION_KEYin the n8n service, then store a copy in your password manager. This key decrypts every saved credential in n8n, and losing it means re-entering all of them by hand.Write a
Caddyfilewith two blocks: one forcloud.yourdomain.comreverse-proxying tonextcloud:80, one forn8n.yourdomain.comreverse-proxying ton8n:5678. Mount it into the Caddy container along with volumes for/dataand/configso certificates survive a restart.Add the
.well-knownredirects to the Nextcloud block in your Caddyfile as documented in Nextcloud's admin manual. Skip this and calendar and contact clients will fail to auto-discover, even though the web interface looks perfectly healthy.Run
docker compose up -dfrom the project folder, then watchdocker compose logs -f caddywhile certificates are issued. Timing note: the first certificate request usually completes in 10 to 30 seconds, but if DNS hasn't propagated yet, Caddy will retry with a backoff. Wait rather than restarting in a panic.Open
https://cloud.yourdomain.com, finish the Nextcloud setup wizard, and create your admin account. Then openhttps://n8n.yourdomain.comand create the n8n owner account on the first-run screen.Switch Nextcloud's background jobs from AJAX to cron. Add a host crontab entry that runs
docker compose exec -T -u www-data nextcloud php cron.phpevery five minutes, then confirm the Basic settings page shows the last run as recent.Log into Nextcloud, open the admin overview page, and work through every warning it lists. This page catches missing PHP modules, absent database indices, and caching that isn't configured, and clearing it now saves you from blaming n8n for slowness later.
That's the whole build. From here everything else is tuning, connecting, and backing up.
Keeping the two apps from fighting over the same RAM and disk
A shared server needs limits, or one app's bad day becomes both apps' bad day.
Set memory limits per service in Compose using the deploy.resources.limits block or mem_limit. Giving Nextcloud a ceiling of roughly half your RAM and n8n a smaller slice means a runaway workflow gets killed instead of dragging the file server down with it. A container that restarts is annoying.
A server that stops responding to SSH is a bad evening.
Add swap even if you have plenty of RAM. A 2GB swap file on a 4GB box acts as a cushion during Nextcloud's cron runs, and Linux will use it before the OOM killer starts picking victims. It's five minutes of work with fallocate and swapon.
Watch n8n's execution history. n8n stores the data from every workflow run, and on recent 1.x versions old executions are pruned automatically after a set age. If you run high-volume workflows, tighten it: set EXECUTIONS_DATA_SAVE_ON_SUCCESS=none so only failures are kept in full, and check the current pruning variables in n8n's self-hosting documentation before you rely on the defaults. Unpruned SQLite files can climb into the gigabytes faster than people expect.
On the Nextcloud side, the disk eaters are file versions and the deleted-files bin. Both have retention settings in config.php, and both default to generous. If your users sync large media libraries, cap them.
It's also worth knowing your platform's upload ceilings for large files, since PHP limits and proxy body-size limits both need raising for multi-gigabyte uploads to complete.
Install Redis and point Nextcloud's file locking and memory cache at it. This single change does more for perceived Nextcloud speed than any other tweak, and it costs about 30MB of RAM. If you've ever wondered why PHP sites crawl on cheaper plans, missing object caching is usually somewhere in the answer.
Connecting n8n to Nextcloud is the part that makes the shared server worth it
Once both are running, n8n can talk to Nextcloud over the local Docker network instead of going out to the internet and back. That's the quiet payoff of co-locating them: no external round trip, no bandwidth cost, and file transfers happen at local speeds.
To connect them, create a dedicated Nextcloud user for automation, then generate an app password for it under Personal settings, Security. Use that app password in n8n's Nextcloud credential, never the account's real password, because app passwords can be revoked individually and they sidestep two-factor prompts. n8n's Nextcloud node speaks WebDAV, so it handles uploading, downloading, moving, copying, and deleting files and folders.
For the WebDAV URL, I'd use your public hostname (https://cloud.yourdomain.com) rather than the internal container name. Nextcloud checks incoming requests against its trusted_domains list, and using the public name avoids a whole class of confusing rejections. If you'd rather keep traffic internal, add the container hostname to trusted_domains in config.php first.
For triggers, polling is the reliable route: a Schedule Trigger that lists a folder every few minutes and acts on new files. Newer Nextcloud releases also include a webhook listeners app that can push events to an external URL, which would let n8n react instantly. Check whether it's available on your version in the Nextcloud app store before you design a workflow around it.
Details on what Nextcloud supports per release live in their admin manual.
Three workflows worth building on day one: dump form submissions or invoices into a dated Nextcloud folder, back up a database export to Nextcloud on a schedule, and post a Nextcloud Talk message when a workflow fails. That last one turns your file server into your alerting system for free.
Backups and security need a plan before you put real data on this box
Two apps means two backup jobs, and they don't overlap.
Nextcloud needs three things captured together: the data directory, the database dump, and config.php. A file backup without a matching database dump gives you files nobody can log in to see. Put Nextcloud into maintenance mode during the dump if you want a consistent snapshot.
n8n needs its .n8n volume, which holds the SQLite database with your workflows and encrypted credentials, plus the encryption key itself stored somewhere else. Export workflows to JSON as a secondary copy if they matter, since a JSON file restores anywhere.
Snapshots at the host level are the safety net rather than the plan, and it's worth knowing how far back your daily snapshots reach before you assume last month's data is recoverable.
On security, the short list: keep n8n's port unpublished so the only way in is through the proxy, turn on two-factor authentication for Nextcloud admin accounts, install fail2ban, enable unattended security upgrades, and leave the firewall closed to everything except 22, 80, and 443. Your reverse proxy handles certificate issuance and renewal on its own with Let's Encrypt, though it's still useful to understand where a certificate actually comes from when you're deciding between automated and purchased options.
One more habit that pays off: write down what you built. Which volumes hold what, which env vars matter, where the encryption key lives. Six months later you won't remember, and having your own notes in a sensible format beats reverse-engineering a Compose file at 11pm.
There's a decent rundown of formats that work for setup notes if you want a starting structure.
Common mix-ups people run into with this setup
Mix-up: You can point both apps at the same database container to save resources.
Reality: Nextcloud runs on MySQL, MariaDB, or PostgreSQL. Recent n8n versions support SQLite and PostgreSQL only, having dropped MySQL and MariaDB support in the 1.0 release. If you want one database engine, use PostgreSQL for both, with separate databases and separate users.
Sharing MariaDB is a dead end.
Mix-up: n8n needs its own server because automation is resource-heavy.
Reality: at rest, n8n uses very little. What's heavy is a specific kind of workflow: one that loads big files or large API responses into memory, or one that fires dozens of parallel executions. If your workflows move JSON between APIs on a schedule, n8n is the lighter of the two apps on this server by a comfortable margin.
Mix-up: Because both apps sit on one IP, one certificate covers both.
Reality: each hostname needs its own certificate, or one wildcard covering the subdomains. Caddy and Nginx Proxy Manager both handle this automatically per site, so you rarely think about it, but the certificate count is two, not one.
What to do if something goes wrong
Problem: n8n's editor loads but webhook URLs show localhost or http:// instead of your domain.
Fix: WEBHOOK_URL and N8N_PROTOCOL aren't set correctly, or aren't being read. Fix them in your Compose file, then recreate the container with docker compose up -d. A plain restart won't pick up changed environment variables.
Problem: Nextcloud shows "Access through untrusted domain" after you put it behind the proxy.
Fix: add your hostname to the trusted_domains array in config.php, either by editing the file inside the volume or with occ config:system:set trusted_domains 1 --value=cloud.yourdomain.com. Reload the page afterwards.
Problem: Large uploads to Nextcloud fail partway through, or n8n returns a 413 error.
Fix: the reverse proxy's request body limit is capping you, and PHP's upload_max_filesize and post_max_size are probably too low as well. Raise the proxy limit first, then the PHP values, then retry. Both layers have to allow the size.
Problem: The server slows to a crawl at regular intervals.
Fix: check whether Nextcloud's cron and a scheduled n8n workflow are firing at the same minute. Offsetting the workflow schedule by two or three minutes fixes it. Run docker stats during a slow patch to see which container is actually eating the CPU.
What this means for your setup, and what to do next
If you're weighing whether to buy one VPS or two, one is the right call for most people reading this. A 4GB box running both apps costs less than two 2GB boxes, gives you local-network speed between n8n and Nextcloud, and means one server to patch instead of two. Split them later if Nextcloud gains real users or your workflows start processing files at volume.
Migrating a Docker Compose service to its own host is a couple of hours of work, not a rebuild.
Where this setup isn't the right fit: if you need Nextcloud with Collabora for a team of 25, or n8n in queue mode with multiple workers handling thousands of executions a day, give each one a dedicated machine. And if you were hoping to do this on shared hosting, that door is closed. n8n needs a long-running Node process, root-level control, and open outbound network access, none of which shared plans provide.
For hardware, any KVM VPS with 4GB of RAM and full root access will do the job. Hostinger's VPS plans run KVM with prebuilt templates including Docker and n8n, which shortens step three of the build considerably. Hostinger also lists their current template catalogue on the plan pages, so confirm what's available before checkout.
Check current Hostinger VPS pricing and apply code hHostCouponHub for up to 85% off
Frequently asked questions
How much RAM do I need to run n8n and Nextcloud together?
Plan for 4GB with 2 vCPUs as a working minimum for a small Nextcloud instance plus normal automation workloads. Go to 8GB if you add Collabora or OnlyOffice document editing, run more than about ten active Nextcloud users, or build workflows that process files and images.
Can n8n and Nextcloud share the same database?
Only if you use PostgreSQL, with a separate database and user for each app. Recent n8n releases support SQLite and PostgreSQL, having dropped MySQL and MariaDB support in version 1.0, so a shared MariaDB container won't work. SQLite for n8n and MariaDB for Nextcloud is a perfectly fine combination too.
Do I need two domains, or will subdomains work?
Two subdomains on one domain are fine and are what I'd recommend: cloud.yourdomain.com and n8n.yourdomain.com, both pointing to the same server IP. The reverse proxy routes by hostname and issues a separate certificate for each. Subfolder installs are possible with n8n's path variable but create more problems than they solve.
Will one app slow the other down?
Not under normal load, since the two have different runtimes and different spike patterns. Problems appear when memory runs short, so set per-container memory limits, add swap, and offset your n8n schedules from Nextcloud's five-minute cron. Run docker stats during any slow patch to see exactly which container is responsible.
Get the server sized right the first time and this whole setup takes an evening, then runs quietly for months with nothing more than image updates and a look at the Nextcloud admin warnings page. If you're picking hardware now, a 4GB KVM plan with root access covers both apps comfortably.
Spin up a VPS that handles both apps, code hHostCouponHub
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.
