I kept running into small, repetitive jobs in the homelab. A container would wedge and I would restart it by hand. An alert would fire in one place when I wanted it in another. None of it was hard, all of it was manual, and I wanted somewhere to wire services together without writing a daemon for every little task. That sent me to n8n. What I did not expect was to research it, recommend it, shelve it the same afternoon, and then come back weeks later and deploy it for something I had not planned on at all.

Why a workflow engine, and why self-hosted

Workflow automation tools let you connect services: trigger on a webhook or a schedule, run a few steps, call an API, move data between things that do not natively talk. The famous ones are hosted: Zapier and Make.com. Both are polished and both are cloud-only, which is a non-starter when half of what I want to automate lives on a private network and I would rather not hand a SaaS my homelab credentials. So the search was specifically for self-hosted.

The alternatives

• Zapier: cloud-only, paid, thousands of integrations, great for non-technical users. Out on self-hosting alone.
• Make.com: cheaper, a hybrid option exists, still cloud-first. Out for the same reason.
• Huginn is properly open source and self-hosted, agent-based, built in Ruby. It can do a lot, but it asks for more manual configuration and ships fewer ready-made integrations. More to maintain than I wanted.
• Node-RED overlaps, but it aims at IoT and message wiring more than service-to-service automation.

n8n sat in the middle: self-hosted, a visual node-based builder, a couple hundred native integrations plus generic HTTP and webhook nodes for anything with an API, and JavaScript or Python code nodes for when the no-code path runs out. On paper it was the obvious pick, and my first research pass said exactly that. Proceed.

Then I shelved it the same day

A few hours later I moved the issue back to the backlog. The note I left myself was blunt: research done, immediate value not apparent. I had a list of things n8n could automate and not one job painful enough on its own to justify standing up another stateful service with its own database to look after. A tool looking for a job is a reliable way to accumulate maintenance you do not need. So it sat.

What changed

When I came back to it weeks later, I re-ran the evaluation with an ROI lens instead of a feature list. Which specific jobs would actually save me time or catch something I would otherwise miss? A handful cleared the bar: verifying backups had genuinely completed instead of assuming they had, funneling alerts from a half-dozen sources into one place, and turning critical alerts into tracked issues automatically. That was enough of a reason to deploy. The difference was not new information about n8n, it was being honest about which problems were real.

Deploying it: Docker-in-LXC

Same pattern as everything else here: a Docker Compose stack inside a Proxmox LXC container, driven by Ansible. n8n needs a database, so the stack is two containers, n8n and PostgreSQL 15:

n8n:
  image: n8nio/n8n:latest
  environment:
    DB_TYPE: postgresdb
    N8N_DIAGNOSTICS_ENABLED: 'false'
    N8N_VERSION_NOTIFICATIONS_ENABLED: 'false'
    EXECUTIONS_DATA_PRUNE: 'true'
    EXECUTIONS_DATA_MAX_AGE: 336

The Docker-in-LXC bind mounts need the same ownership care any database container does (the Postgres data directory has to be owned by the uid the image runs as), which the Ansible role handles before Compose starts. Two other things I set on the way in. Telemetry off, both N8N_DIAGNOSTICS_ENABLED and the version-notification ping disabled, because a self-hosted tool has no business phoning home. And execution-data pruning on with a 336-hour (14-day) max age, because n8n records every run and that table grows without bound otherwise.

The SSO constraint worth knowing up front

One finding from the research that is easy to miss until you are planning auth: n8n’s Community Edition has no built-in single sign-on. SAML and OIDC are Enterprise-only. In a homelab where other services sit behind a single identity provider, that matters. I run n8n with its built-in login behind Traefik for HTTPS, which is fine for a single user, but if you want it gated by a real identity provider you are adding a reverse-proxy auth layer in front of n8n, not configuring it inside n8n.

Where it landed, and the part I did not predict

The case I made for deploying n8n was homelab monitoring. I am building toward those workflows, and they are the reason the evaluation finally passed. But the thing that turned out to earn its keep first was content automation, pulling rows from a spreadsheet into templated graphics and scheduling posts, which had nothing to do with the monitoring story I had used to justify it. The tool I researched for one reason got deployed and then immediately used for another.

A few takeaways:

• For self-hosted workflow automation, n8n is the pick over Zapier and Make (cloud-only) and over Huginn and Node-RED (more setup, or a different focus). The tradeoff is running a stateful service with its own database to maintain.
• Do not deploy a tool because it could be useful. I shelved n8n once for exactly that reason and was right to. Re-running the evaluation with an ROI lens, not a feature list, is what made the second decision clear.
• n8n Community Edition has no native SSO. If your homelab is SSO-first, plan to gate it at the proxy.
• Turn telemetry off and execution pruning on from day one. The defaults log forever and ping home.
• The use case that justifies a tool and the use case that makes you glad you deployed it are not always the same one.