I ran a personal n8n server for two years. Twenty-something workflows wiring together Telegram, Vikunja, Qdrant, my vault, my calendar, my email. Most of them worked. Most of them needed me to think about them. Two weeks ago I turned the whole thing off and replaced it with a three-layer pattern that runs inside the chat tool I was already using. This is the model, the constraints that drove it, and why “automation” turned out to be the wrong frame all along.
What I had
A self-hosted n8n instance, behind Cloudflare Tunnel, with about twenty live workflows. The greatest hits:
- Email arrives → classifier categorises → routes to the right Telegram channel.
- A meeting transcript lands in Drive → diarise → summarise → write to the vault → file a task in the right project.
- A new vault note matching a pattern → auto-tag → cross-link to related notes via embeddings.
- A calendar event finishes → check whether I logged the call → nudge me if I didn’t.
- Friday afternoon → pull GitHub commits for the week → write a draft summary email to a small list of clients.
Each one was clever. Each one had taken me a Saturday to build. Each one was, on average, seventy percent of the way to being good, and the remaining thirty percent was the part you have to fix every few weeks when something upstream changed.
The day I added it up, I had spent eleven Saturdays in 2025 fixing n8n workflows. The workflows themselves saved me maybe an hour a week. The math was deeply uncomfortable.
The three things that broke me
The OAuth treadmill. Google, Microsoft, and (in the previous regime) Twitter all required periodic re-authentication of n8n’s credentials. n8n would show a green checkmark. The workflow would silently fail. I would discover this in the worst possible way — the rare moment when the workflow was supposed to matter. Then I’d spend forty minutes re-doing OAuth flows on five different services.
The breaking-change tax. n8n itself updates aggressively. Node packages get renamed. Inputs change shape. A workflow that worked on a Tuesday throws a red icon on Friday because something deep in the JSON schema of one of seventeen nodes changed. The fix is usually small. The cost is the attention.
The “but does it run when I’m not looking?” anxiety. I’d visit the n8n dashboard every couple of days because I didn’t trust the workflows. Visiting the dashboard is not a workflow.
I was running a tiny ops team for a single user. The team was me. The user was also me.
What I actually wanted
I sat down with a notebook (paper; first time in months) and wrote what I’d wanted from n8n, in plain English:
“I want to open something in the morning and know what matters. I want to be reminded of things I promised. I want to ask questions about my own data in a sentence, not a query language. I do not want to maintain anything.”
The last sentence is the one that mattered. I do not want to maintain anything. If a thing requires me to babysit it, it has failed before it started — because the whole point of automation, for one person, is to subtract maintenance, not add it.
Which is when I noticed: the chat assistant I’d started using for code work could already reach my calendar, my email, my task tracker, my vault, my code repos. Through MCPs. Through skills. Through a folder I’d already given it access to. The infrastructure I’d been running n8n on — to connect things — was, on the assistant side, already connected.
The n8n server existed because the chat assistant hadn’t existed when I’d built it.
The three-layer replacement
What replaced n8n isn’t a workflow engine. It’s a pattern, and the pattern has three layers:
┌─────────────────────────────────────────────┐
│ Layer 1 — THE HUB │
│ A live HTML view I open in the morning. │
│ Pulls fresh data from connectors on every │
│ load. "What matters right now." │
│ Trigger: I open it. │
└─────────────────────────────────────────────┘
▲
│ I look at this in the morning
│
┌─────────────────────────────────────────────┐
│ Layer 2 — RITUALS │
│ Scheduled tasks. Morning briefing. │
│ End-of-day closure sweep. Sunday prep. │
│ Friday inbox triage. │
│ Trigger: clock. │
└─────────────────────────────────────────────┘
▲
│ runs even if I don't open the chat
│
┌─────────────────────────────────────────────┐
│ Layer 3 — COMMANDS │
│ A vocabulary I can say in chat. │
│ "What's on my plate today?" │
│ "I just shipped X — close the task." │
│ "Triage my inbox." │
│ Trigger: I say it. │
└─────────────────────────────────────────────┘Three distinct triggers. Three distinct frequencies. Together they cover roughly the same surface n8n did, with one critical difference: none of them runs when I’m not paying attention to it. Layer 2 (the rituals) is the closest to “background automation,” and even those write their output to a markdown file I can read on my own time, rather than firing a notification at me.
Why this works where n8n didn’t
No OAuth treadmill. The connectors are owned by the chat tool, not by me. When Google re-authenticates, the tool handles it. I am not in that loop anymore.
No breaking-change tax. There are no workflow JSONs to maintain. The “logic” of each ritual lives in a prompt and a small amount of glue code that the chat tool runs. When something upstream changes, the prompt still works because prompts are written in English. (This is the part where six months ago I would have argued. I no longer argue.)
No anxiety. Layer 1 (the Hub) is a single page that shows me everything at once. If something is broken — a missing connector, a stale data feed — I can see it on the page. No “is it running?” question. The page is either right or it’s visibly wrong.
No mutation without me. The pattern I broke when I retired n8n was background writes. No workflow now writes to ClickUp, sends an email, or modifies the vault unless I press a button. The chat tool drafts; I confirm; the action happens. The loss of “fire and forget” is small. The gain in confidence is real.
The hardest part: letting workflows die
The n8n workflows hadn’t been useless. They’d done real work. Turning them off felt like losing capability, even though I knew — by the math, by the eleven Saturdays — that I was losing maintenance burden, not capability.
The way I got through this was by making a list of every workflow and asking which of them I’d actually miss. Out of twenty-two:
- 6 had been broken for more than a month and I hadn’t noticed → off.
- 7 had been replaced by the equivalent action being something I could just ask the chat to do → off.
- 5 produced output I wasn’t actually reading → off.
- 3 produced output I was reading and did want → re-implemented as Rituals.
- 1 had real-time requirements (incoming webhook → reply) that the new pattern can’t do → kept on a small Cloudflare Worker. Not n8n. Twenty lines of code. Set-and-forget.
The realisation: I’d been treating n8n as my automation tool when what I actually wanted from automation was already three other things — a dashboard, a scheduler, and a chat. Each of those three tools is good at one of the jobs. n8n was an attempt to be good at all three. It mostly was. It just cost more than it paid.
What I learned, in three lines
Automation isn’t a tool category, it’s a property of having less to do. The right question is never “what should I automate?” It’s “what should I stop doing?” Sometimes the answer is “automate it.” Sometimes the answer is “stop doing it.” Sometimes the answer is “this only needs to happen when I look at it, so let it happen when I look at it.” n8n forced everything into the first answer.
A dashboard you trust is better than ten silent jobs you don’t. The Hub is the centerpiece of the new setup because I trust it. When I open it, I see the current state of the things I care about, computed live, from the actual sources. If I close my laptop and walk away, the Hub doesn’t do anything — but it also doesn’t fail silently, because there’s nothing to fail. The contract is simple: “you open me, I tell you the truth.” n8n’s contract was: “I run all the time, and sometimes the truth is correct.”
The “automate everything” instinct is for people who like building automation systems. That includes me. It includes most of the people I know in tech. We build automation because building automation is more fun than the thing the automation is supposed to do. The grown-up move — and I am, with some reluctance, becoming a grown-up — is to ask whether the automation is for the work or for the joy of building, and to admit when the answer is the latter. The joy of building is real. It is also expensive. You’re allowed to spend it on other things.
The honest postscript
I have not, in fact, fully retired n8n. The container is stopped. The compose file is still in the repo. There’s a directory of workflow JSONs sitting on a disk, version-controlled, eleven Saturdays’ worth of design decisions.
I’m not deleting them. They’re a snapshot of a way I used to work, and they’re useful as a record — and on a sufficiently bad Friday, the thought of turning them all back on is comforting. I don’t think I will. But it’s good to know I could.
The three-layer pattern, two weeks in, has my whole automation surface area covered, with about an hour a month of attention. The remaining 87% of my Saturdays will, I assume, find other places to spend themselves. They always do.
Adjacent: ClickUp is a lagging indicator — the same realisation, told from inside the task tracker.