Self-hosted workflow automation software like n8n replaced a pile of cron jobs and glue scripts around here, but it didn’t replace three specific jobs. Credential handling is per-instance, and a rebuild can destroy secrets you can’t get back. At homelab scale, that’s the real tradeoff.
What n8n actually replaced
Before n8n, I had a handful of shell scripts running under cron. Two of them mattered. One pushed scheduled content to a WordPress site through the REST API. The other pulled data from an external source into Postgres on a schedule. Both worked, mostly, until they didn’t. A script would fail silently, or a token would expire, and I’d find out days later. n8n replaced that with a single place where the logic is visible, retries are built in, and failures at least show up in an execution log. That’s the part worth keeping.
For a single operator, n8n’s real advantage isn’t the drag-and-drop interface. It’s that the workflow definition lives in one place and you can see the last ten runs without SSHing into a box and grepping logs. The scheduled content workflow is a few HTTP request nodes, a check for a non-200 response, and a notification if something breaks. The Postgres pull is a scheduled trigger, a query, and an insert. Nothing exotic. I could have kept doing it with cron, but the visibility and retry logic are worth the overhead of running a service.
That said, self-hosting n8n is not the same as self-hosting a static site. You now have a database to back up, an encryption key to keep safe, and a web UI exposed to your network. If you’re comparing self-hosted vs SaaS, the costs that show up in month three are exactly these operational gotchas—not the license fee. I wrote about that in more detail when looking at business process automation software self-hosted vs SaaS, and the same logic applies here. The monthly bill for a hosted automation platform removes that noise, but you pay for it forever.
The three jobs it didn’t replace
Here’s where the honest scale matters. n8n is great at moving data between APIs on a schedule, but it is not a secret manager, not a password vault, and not a backup system. I hit all three of those limits in practice.
1. Credential storage across rebuilds
n8n stores credentials encrypted in its database, using a key from its configuration. That’s fine while the instance is running. But if you rebuild the container—say, to upgrade the base image or move to a new host—and you don’t preserve that encryption key and database together, the credentials are gone. They don’t come back from a workflow export because n8n deliberately keeps credentials separate from workflow JSON. The workflow will import fine and then fail on the first run with an auth error.
What this means is that n8n did not replace the job of keeping a secure, recoverable record of API keys and passwords. You still need that outside the tool. For me, that’s a password manager with the credentials documented, plus a backup of the n8n database and the encryption key. If you lose the key but keep the database, the credentials are unreadable. If you lose the database but keep the key, you have nothing to decrypt. Both have to be restored together. That’s a coordination problem cron never had.
2. Application password recovery
The WordPress application password I use for the content publishing workflow is not recoverable. If that password is lost—say, n8n’s credential store gets wiped by a bad rebuild—WordPress won’t show it to me again. I have to generate a new application password, update n8n, and hope I didn’t miss another workflow using the same credential. That’s a manual step with no undo. n8n doesn’t solve this; it just consumes the credential. The recovery process is still on me.
This is a specific example of a general rule: any system that issues non-recoverable secrets (API tokens, app passwords, SSH keys) is outside n8n’s jurisdiction. n8n will happily store them, but it won’t help you rotate them or recover them if they vanish. I’d argue that’s not a bug—it’s a boundary. Don’t ask your automation tool to be your source of truth for secrets.
3. Being the only copy of your automations
The third job n8n didn’t replace is the backup and version control of the workflows themselves. Yes, you can export workflows to JSON. Yes, you can commit those to a git repo. But if you don’t, and the n8n database dies, you lose every workflow you’ve built. The web UI is not a backup. The scheduler keeps running until the container stops, and then it’s gone.
For a homelab, the temptation is to treat n8n like a durable service and forget to export. I’ve been guilty of that. The fix is boring: a weekly export of all workflows to a git repo, plus a database dump, plus the encryption key stored somewhere safe. That’s three things, and none of them are n8n’s job. If you’re running n8n in a Proxmox LXC, you also need to keep the container’s network working—when the container can’t reach the WordPress API or Postgres, the workflows fail silently. I’ve had to diagnose that once or twice, and diagnosing a Proxmox container with no internet is its own rabbit hole.
What I’d do differently at a different scale
If I were running n8n for a team or a business, I’d still self-host it, but I’d pair it with an external secret manager like Vault or even a locked-down password manager with an API. I’d also run two n8n instances behind a load balancer with a shared Postgres database, because a single container going down would stop every automation. That’s overkill for one person, but the failure mode is the same: n8n is stateful, and the state is fragile. The difference is how many people notice when it breaks.
At homelab scale, the honest takeaway is this: n8n replaced my cron jobs and glue scripts, but it didn’t replace operational discipline. You still need to back up the database, keep the encryption key safe, and document every credential you feed it. If you’re not willing to do that, use the hosted version and let someone else handle the operational burden. The tradeoff is cost, and that’s a monthly bill instead of a Saturday afternoon.
If you’d rather pay for this
The obvious paid alternative is n8n Cloud, which is n8n’s own hosted offering. It’s billed per execution or per seat depending on the plan, and at the time of writing the entry tier is free for a limited number of workflow executions per month, which is enough for light homelab use. The pricing model is what matters: you pay for either the number of workflow runs or the number of users, not for the server itself. That removes the container rebuild problem, the database backup problem, and the encryption key problem all at once.
Another option is Zapier or Make, which are purely SaaS and charge per task or per operation. They’re more expensive at scale but dead simple. The honest take: if you only have two or three automations and you don’t want to babysit a container, the free tier of n8n Cloud or Zapier’s free plan will handle it. You lose the control and the data stays on their servers, but for a non-critical workflow that’s a fair trade. For anything that touches personal data or needs to run on your own hardware, self-hosting n8n is still worth the effort—just understand that the three jobs above are yours forever.
