If you've ever set up a Zapier or Make.com account and then watched your monthly task quota disappear before the month was even half over, you already understand the appeal of n8n. It does the same job — connecting apps, moving data between them, triggering actions on a schedule or a webhook — except it runs on hardware you own, with no per-task billing and no vendor deciding what you're allowed to automate.
Your Proxmox VE server is a good home for it. Rather than installing n8n directly on the Proxmox host (which you really shouldn't do — the host should stay dedicated to virtualization), you can drop it into a small LXC container that boots in seconds and barely touches your resources when it's idle.
This guide walks through building that container from a blank Proxmox node, installing n8n inside it the standard way (via npm, not Docker), and getting it running as a proper background service that survives reboots. If you've never touched an LXC container before, don't worry — every command gets explained as we go.
What You Will Learn
- What n8n actually is and why people run it themselves instead of paying for a SaaS automation tool
- How to create a lightweight, unprivileged LXC container on Proxmox VE for it
- How to install Node.js and n8n inside that container
- How to run n8n as a systemd service so it starts automatically and restarts if it crashes
- How to reach the n8n editor from your browser and fix the errors people run into most often
What Is This Feature?
n8n (pronounced "n-eight-n," short for "nodemation") is an open-source workflow automation tool. You build workflows visually by dragging "nodes" onto a canvas and connecting them: a Gmail trigger feeds into a filter, the filter feeds into an HTTP request node, the HTTP request node writes a row into a spreadsheet. Each node does one small job, and the connections between them define the logic.
It's the same idea behind Zapier or Make, but n8n is self-hostable and source-available, so once it's installed there's no usage-based billing and no hard cap on how many workflow runs you can execute per month.
Under the hood it's a Node.js application. By default it stores its workflows and credentials in a local SQLite database file, which is more than enough for a single-user homelab setup — you don't need a separate database server to get started.
Why Would You Use It?
A few reasons people move their automations onto their own Proxmox box specifically:
- No execution limits. Cloud automation platforms bill per task or per workflow run. Self-hosted n8n has no such counter — run a workflow every ten seconds if you want to.
- Your data stays on your network. If a workflow touches anything sensitive — home security camera events, financial exports, internal household documents — it never has to leave your LAN.
- It fits naturally next to the rest of your homelab. n8n is genuinely useful for gluing together the other self-hosted services people already run on Proxmox: post a Discord message when a Proxmox backup job fails, sync a new Immich photo album to cloud storage, restart a container when a health check fails.
Honestly, if you already run three or four self-hosted apps on your Proxmox box, n8n is one of the more genuinely useful additions you can make. It's the glue layer nobody thinks to build until they already have one.
Prerequisites
Before you start, make sure you have:
- A working Proxmox VE 9.x host with a bit of free storage (8 GB is plenty to start) and at least 2 GB of RAM free for the container
- Root or admin access to the Proxmox web interface
- A basic comfort level with a Linux terminal — you'll be typing commands, not clicking through a wizard, for most of this
- Network access from the container to the internet, so it can download packages during setup
You don't need any prior n8n experience, and you don't need Docker installed anywhere. This guide uses the plain npm installation method, which is a little more hands-on than a Docker container but easier to understand for a first install.
Step-by-Step Tutorial
Step 1: Download the Debian 13 container template
Proxmox VE 9.2 ships on Debian 13 ("Trixie") as its base, and the matching container template is the natural choice for a container running on it. In the Proxmox web interface, click your storage under local (or whichever storage holds your templates), open the CT Templates tab, and click Templates. Search for debian-13 and download debian-13-standard.
If you'd rather do it from the shell on the Proxmox host, this does the same thing:
pveam update
pveam available --section system | grep debian-13
pveam download local debian-13-standard_13.1-2_amd64.tar.zstThe exact version number in the filename (13.1-2 here) will drift as Proxmox refreshes the template, so just use whatever pveam available shows you.
Step 2: Create the LXC container
Click Create CT at the top of the Proxmox interface. Walk through the wizard with these settings:
- Hostname: something like
n8n - Unprivileged container: leave this checked — there's no reason n8n needs root-level access to the host
- Template: the debian-13-standard template you just downloaded
- Disk size: 8 GB is comfortable; n8n's SQLite database and execution logs are small unless you're running very high-volume workflows
- Cores: 2
- Memory: 2048 MB, with swap of 512 MB
- Network: DHCP is fine for testing. If you want a fixed address so bookmarks and other services always find it at the same IP, set a static one now — a previous Vormox guide covers configuring a static IP in Proxmox VE if you need the walkthrough.
Finish the wizard and start the container. If you'd rather skip the GUI entirely, the command-line equivalent looks like this (adjust the container ID and IP for your environment):
pct create 115 local:vztmpl/debian-13-standard_13.1-2_amd64.tar.zst \
--hostname n8n \
--unprivileged 1 \
--cores 2 \
--memory 2048 \
--swap 512 \
--rootfs local-lvm:8 \
--net0 name=eth0,bridge=vmbr0,ip=dhcp \
--features nesting=1
pct start 115The --features nesting=1 flag isn't strictly required for n8n itself, but it avoids some odd systemd cgroup permission errors inside unprivileged containers, so it's worth including.
Step 3: Log in to the container
From the Proxmox host shell, enter the container directly — no SSH keys needed for this:
pct enter 115This drops you straight into a root shell inside the container. Everything from here happens inside that shell, not on the Proxmox host.
Step 4: Update the system and install build tools
apt update && apt full-upgrade -y
apt install -y curl gnupg ca-certificates build-essential python3The build-essential and python3 packages look unnecessary for what's supposed to be a Node.js install, but n8n depends on better-sqlite3, which occasionally needs to compile a native binding from source if npm can't find a prebuilt one for your exact Node and CPU architecture combination. Installing the toolchain up front saves you from a confusing build failure later.
Step 5: Install Node.js
n8n needs Node.js 20.19 or newer, up to the 24.x line. NodeSource's setup script is the simplest way to get a current LTS release on Debian:
curl -fsSL https://deb.nodesource.com/setup_22.x | bash -
apt install -y nodejsConfirm it installed correctly:
node -v
npm -vYou should see something starting with v22. for Node and a 10.x version for npm.
Step 6: Install n8n
npm install -g n8nThis pulls down n8n and its dependencies from the npm registry. It's a fairly large install — give it a minute or two, especially on a container with only 2 cores.
Once it finishes, run n8n --version to confirm it's on your path and working.
Step 7: Create a dedicated system user
Running n8n as root works, but it's not something you want to make a habit of, even inside a throwaway container. Create a separate user for it:
useradd -r -m -d /home/n8n -s /usr/sbin/nologin n8n
mkdir -p /home/n8n/.n8n
chown -R n8n:n8n /home/n8nThe -r flag makes this a system account rather than a regular login user, and -s /usr/sbin/nologin means nobody can actually log in as this account interactively — it exists purely to own the n8n process and its files.
Step 8: Run n8n as a systemd service
Create a service file so n8n starts on boot and restarts automatically if it ever crashes:
nano /etc/systemd/system/n8n.servicePaste in the following, then save and exit:
[Unit]
Description=n8n workflow automation
After=network.target
[Service]
Type=simple
User=n8n
Environment=N8N_LISTEN_ADDRESS=0.0.0.0
Environment=N8N_PORT=5678
Environment=GENERIC_TIMEZONE=UTC
Environment=N8N_USER_FOLDER=/home/n8n/.n8n
ExecStart=/usr/bin/n8n start
Restart=on-failure
RestartSec=5
[Install]
WantedBy=multi-user.targetTwo of these variables are worth calling out. N8N_LISTEN_ADDRESS controls which network interface n8n binds to — newer versions default to listening on IPv6 only (::), which can make the editor unreachable on an IPv4-only LAN, so setting it to 0.0.0.0 explicitly avoids that headache. GENERIC_TIMEZONE should match wherever you actually are, since it's used for scheduling triggers — swap UTC for something like America/New_York if that's more accurate for you.
Reload systemd and start the service:
systemctl daemon-reload
systemctl enable --now n8nCheck that it's actually running:
systemctl status n8nYou're looking for active (running) in green. If it says failed instead, jump down to the Troubleshooting section.
Step 9: Open the n8n editor
Find the container's IP address (run ip a inside the container if you're not sure), then visit it in a browser on port 5678:
http://<container-ip>:5678The first time you load it, n8n asks you to create an owner account — an email, a name, and a password. This account is stored locally in the container; nothing gets sent anywhere external. Once that's done, you land on an empty canvas, ready to build your first workflow.
Commands Explained
| Command | What it does |
|---|---|
pveam download local debian-13-standard... | Downloads a container template to Proxmox's local storage so it's available for new containers |
pct create | Creates a new LXC container from a template with the resource limits and network settings you specify |
pct enter 115 | Opens a root shell inside a running container, without needing SSH configured |
npm install -g n8n | Installs the n8n package globally, making the n8n command available system-wide inside the container |
useradd -r -m -d /home/n8n -s /usr/sbin/nologin n8n | Creates a dedicated system account with no login shell, purely to own the n8n process |
systemctl enable --now n8n | Enables the service to start on boot and starts it immediately in one command |
systemctl status n8n | Shows whether the service is currently running and prints its recent log output |
Common Errors
"n8n: command not found" after installing. This almost always means the npm global bin directory isn't on your PATH, or you installed Node.js through a method (like nvm) that scoped the global install to a different user than the one you're logged in as. Run npm root -g and check the path it prints matches what which node resolves to.
"gyp ERR! build error" during npm install -g n8n. This is the native module compile step failing, usually because build-essential and python3 weren't installed before you ran the npm command. Install them and run the npm install again.
Systemd shows "Failed to start n8n.service" with status code 217/USER. This means systemd couldn't find the n8n user in /etc/systemd/system/n8n.service. Double-check you actually ran the useradd command in Step 7 before enabling the service, and that the username matches exactly.
The editor loads but nothing happens when you save a workflow, or you see "Problem loading workflows" in the browser console. This is typically a permissions issue on the .n8n data folder. Confirm /home/n8n/.n8n is owned by the n8n user with ls -la /home/n8n, and re-run the chown command from Step 7 if it isn't.
Troubleshooting
If systemctl status n8n shows the service crash-looping, the fastest way to see why is to follow its live log rather than just the status snapshot:
journalctl -u n8n -fMost crash-loop cases trace back to one of three things: a typo in the systemd unit file's environment variables, the .n8n folder having the wrong ownership, or port 5678 already being in use by something else in the container. You can check for a port conflict with ss -tlnp | grep 5678.
If the browser just times out instead of showing an error, that's a network-layer problem rather than an n8n problem. Check the container's Proxmox firewall settings (Datacenter → your container → Firewall) — if you enabled the firewall on the container without adding a rule for port 5678, it'll silently drop the connection. Confirming the container actually has an IP address with ip a is also worth doing before you chase anything more exotic.
If workflows run but scheduled (cron-style) triggers never fire at the time you expect, revisit the GENERIC_TIMEZONE setting in the systemd unit. It's a common miss, and it's easy to not notice until a trigger silently fires three, five, or eight hours off from when you expected it.
Best Practices
Take a snapshot of the container right after this initial setup, before you start building real workflows. It costs almost nothing on Proxmox and gives you an easy rollback point if a future n8n update breaks something.
Back the container up with your normal Proxmox backup job (vzdump or Proxmox Backup Server, whichever you already use) rather than treating it as disposable. The workflows themselves are just data in that SQLite file — losing the container means losing every automation you've built, along with any stored credentials.
Don't expose port 5678 directly to the internet. If you want to trigger workflows from outside your home network — a webhook from GitHub, for instance — put a reverse proxy in front of it with TLS, or route access through something like Tailscale rather than forwarding the raw port.
Set an N8N_ENCRYPTION_KEY environment variable explicitly rather than letting n8n generate one automatically on first run. If you ever need to restore this container from a backup onto a different host, a mismatched auto-generated key means every stored credential becomes unreadable. Pick a random 32+ character string, add it to the systemd unit alongside the other environment variables, and write it down somewhere safe.
Frequently Asked Questions
Do I need Docker to run n8n on Proxmox?
No. This guide installs n8n directly with npm inside a plain LXC container, which is lighter weight than running Docker-in-LXC and easier to reason about for a first install.
Is SQLite good enough, or do I need PostgreSQL?
For a single-user homelab setup with a modest number of workflows, SQLite is fine. n8n's own docs recommend PostgreSQL mainly for multi-user or high-volume production deployments — not something most homelab users need on day one.
How much RAM does n8n actually need?
It'll run in less, but 2 GB gives you comfortable headroom for a handful of active workflows without the container swapping constantly.
Can I run n8n in Docker inside this same LXC container instead?
You can, but it adds a layer of nested containerization for no real benefit in a single-app setup like this. The npm install described here is simpler to troubleshoot when something goes wrong.
Will updates break my workflows?
Rarely, but it happens. That's exactly why the snapshot-before-you-start-building advice above matters — take another one before any major version upgrade too.
Conclusion
You now have a self-hosted automation engine running quietly in its own container, separate from the rest of your Proxmox infrastructure, costing you nothing per workflow run. From here, the interesting part starts: open the editor, pick a trigger — a webhook, a schedule, an RSS feed — and start wiring nodes together.
The systemd service you set up in Step 8 means none of this depends on you remembering to start anything after a reboot. Restart the Proxmox host, and the container comes back, and n8n comes back with it, ready to keep running whatever you've built.