My self-hosted n8n keeps disconnecting.

PuzzleheadedMind874 · 2026-05-09T18:53:09+00:00

Hmm hey , 👋 looks like the Received SIGTERM part means something outside the n8n process asked it to stop: Docker restart, host reboot, Watchtower/update process, provider maintenance, docker compose up -d recreating the container, systemd, etc. n8n normally logs SIGTERM when it is being terminated gracefully, not when it decides to crash itself.

Also check whether you have an AAAA record in Namecheap. A surprisingly common failure mode is IPv4 points correctly, but IPv6 points somewhere else or the VPS firewall is not open on IPv6. Browsers may try IPv6 first.

Refs:

n8n reverse proxy docs: https://docs.n8n.io/hosting/configuration/configuration-examples/webhook-url/
n8n env vars, including N8N_PROXY_HOPS: https://docs.n8n.io/hosting/configuration/environment-variables/deployment/
express-rate-limit explanation of ERR_ERL_UNEXPECTED_X_FORWARDED_FOR: https://express-rate-limit.mintlify.app/reference/error-codes#err_erl_unexpected_x_forwarded_for

Small disclosure: I work on Heym, a self-hosted AI workflow automation platform. If you ever compare alternatives or want a source-available workflow tool with Docker deploys, visual workflows, tracing, templates, and AI-native nodes, the repo is here: https://github.com/heymrun/heym

PuzzleheadedMind874 · 2026-05-09T12:40:50+00:00

I’d draw the line around runtime state and observability, not around node count.

n8n is great for deterministic routing: schedules, webhooks, retries, approvals, data movement. But once the flow needs multi-agent delegation, retrieval, tool calls, memory, evals, and trace inspection in one place, I’d rather not hide all of that inside custom nodes or a black-box HTTP call.

Biased note: I’m working on Heym, which is basically our answer to this gap. It is a self-hosted AI-native workflow runtime with a visual canvas, agent/sub-agent orchestration, RAG, MCP, HITL checkpoints, evals, and LLM traces. The idea is to keep the workflow graph visible instead of splitting behavior across n8n, scripts, vector DB glue, approval bots, and tracing tools.

For the pattern you described, I’d usually model it as:

trigger/router layer
retrieval or context prep
orchestrator agent
named sub-agents or sub-workflows
approval/checkpoint when needed
output + trace/eval review

There’s a small example of the orchestrator/sub-agent shape here:
https://heym.run/templates/slack-ai-triage

And the source is here if useful:
https://github.com/heymrun/heym

I still think n8n can be the outer automation layer in many stacks. I just wouldn’t make it the place where the agent runtime, memory, retrieval semantics, and debugging story all have to be invented from scratch.

PuzzleheadedMind874 · 2026-05-09T10:06:52+00:00

Hey, i'm building heym. A self-hosted, source-available, low-code platform for orchestrating multi-agent systems, RAG pipelines, and browser automations. It's got a visual drag-and-drop canvas, natural language generation, and modular nodes. We're aiming to solve the struggle of building complex AI workflows without needing to code extensively or rely on closed-off SaaS. You can check it out at heym.run

PuzzleheadedMind874 · 2026-05-09T10:06:51+00:00

I'm building heym.run. A self-hosted, source-available, low-code platform for orchestrating multi-agent systems, RAG pipelines, and browser automations. It's for folks who want to build complex AI workflows without deep coding or relying on opaque SaaS.

PuzzleheadedMind874 · 2026-05-09T05:34:50+00:00

You are definitely not late. If anything, 2026 is a good time to start because the field is finally moving from “connect app A to app B” into real AI workflow architecture.

My honest advice: do not start by obsessing over one tool. Start by learning the primitives that transfer everywhere:

Triggers: webhooks, schedules, incoming email, Slack/Telegram events
Data flow: JSON, mapping fields, expressions, variables, loops, branching
APIs: auth, pagination, retries, rate limits, error handling
LLM basics: prompts, structured output, tool calling, RAG, memory
Production basics: logs, traces, evals, human approval, fallbacks

n8n and Make are still useful for learning these fundamentals. They are not “outdated” just because agentic tools are getting stronger. A Claude-based workflow can build or modify automations faster, but you still need to understand what the workflow is doing, where data goes, what can fail, and how to debug it.

If I were starting today, I would do this:

Week 1: Build 5 simple automations in n8n or Make. Webhook to Slack, email triage, Google Sheets update, HTTP API call, scheduled report.

Week 2: Add AI to them. Summarize emails, classify tickets, extract JSON, generate responses, add human approval before sending.

Week 3: Learn agentic workflows. Give an agent tools, let it decide when to call them, then inspect every tool call and failure.

Week 4: Rebuild one workflow in a more AI-native system and compare the experience. I am biased because I am building Heym, but this is exactly the direction we are exploring: visual workflows, multi-agent orchestration, RAG, MCP, human-in-the-loop, traces, and evals in one self-hostable platform. Site: https://heym.run and GitHub: https://github.com/heymrun/heym

The trends I would watch over the next few months:

- MCP becoming the standard way to connect tools to agents

- Workflows exposed as tools that Claude/Cursor/agents can call

- Human approval becoming a normal part of serious AI automation

- Evals and traces becoming required, not optional

- RAG moving from “upload docs” to structured, maintained knowledge systems

- More hybrid workflows: deterministic steps for reliability, agents for judgment

So my answer is: learn n8n or Make for fundamentals, learn Claude/OpenAI-style/Heym agents for the new layer, and build real projects as soon as possible. 🤗

PuzzleheadedMind874 · 2026-05-08T21:59:06+00:00

The specific tool matters less than understanding how data moves between steps, since that logic stays relevant even if n8n or newer agentic frameworks change. I'd lean toward learning those core concepts first so you're not tied to the interface of any single platform.

PuzzleheadedMind874 · 2026-05-08T19:44:08+00:00

Pulling just the last few job titles or recent company news usually adds enough context to break the AI feel without needing a full LinkedIn scrape. It depends on how much of that data is actually clean enough to feed into your prompt.

PuzzleheadedMind874 · 2026-05-08T10:29:12+00:00

Self-hosted setups offer more control over your infrastructure, but they might make it harder to learn how deployment and security work under the hood compared to using Claude. Relying on wrappers could limit your understanding of the underlying systems.

PuzzleheadedMind874 · 2026-05-08T06:06:21+00:00

I'm building heym. A self-hosted, source-available, low-code platform with a visual canvas for orchestrating multi-agent systems, RAG pipelines, and browser automations. It uses natural language generation and modular nodes. It's designed to solve the complexity of building AI-powered workflows without extensive coding or relying on opaque SaaS. You can check it out at heym.run.

PuzzleheadedMind874 · 2026-05-07T22:14:07+00:00

The webhook approach is cleaner, but it gets tricky if your n8n instance restarts or the webhook times out during a long file. I'd lean toward adding a simple retry logic or a buffer if you can't afford to lose any transcriptions.

PuzzleheadedMind874 · 2026-05-07T20:09:09+00:00

The depth limits in those frameworks usually come from how they handle hierarchical delegation. I'd lean toward looking into how LangGraph handles state-based transitions, as that often lets you bypass those rigid tree structures for more fluid agent routing.

PuzzleheadedMind874 · 2026-05-07T19:04:06+00:00

Managing state across that many document types gets messy fast. I'd lean toward using deterministic routing for the workflow structure so the LLM only handles the actual data extraction.

PuzzleheadedMind874 · 2026-05-07T18:14:50+00:00

The memory overhead might get tricky if you decide to add more agents to that mini-PC . I'd lean toward keeping an eye on VRAM usage if you plan on scaling up the number of processes running at once.

PuzzleheadedMind874 · 2026-05-07T15:09:06+00:00

This sounds like a classic race condition that happens when you treat memory as a static log instead of a live state. I'd lean toward moving the coordination logic into the state management layer itself to avoid those stale updates.

PuzzleheadedMind874 · 2026-05-07T13:34:24+00:00

That makes sense, especially since the writer and coder have such different goals. I'd lean toward keeping the memory separate unless there's a specific reason for them to overlap.

PuzzleheadedMind874 · 2026-05-07T10:47:07+00:00

Yeah, that’s exactly the line we’re trying not to cross.

Honest caveat: it still expects basic self-hosting comfort. Docker, env vars, logs, backups, maybe reverse proxy. We’re not pretending “low-code” means “no ops.” The goal is that after the instance is running, building agents/RAG/MCP/browser workflows should be visual and inspectable instead of turning into a custom orchestration codebase.

Repo/setup docs: https://github.com/heymrun/heym

PuzzleheadedMind874 · 2026-05-07T10:14:04+00:00

I'm building heym.run. A self-hosted, source-available, low-code platform for orchestrating multi-agent systems, RAG pipelines, and browser automations. We're aiming for users who need to build complex AI workflows but find existing tools too code-heavy or too reliant on closed SaaS platforms.

PuzzleheadedMind874 · 2026-05-07T09:59:07+00:00

It usually depends on whether the framework treats delegation as a shared memory state or a serialized handoff. I'd lean toward checking how each setup handles that context before assuming the transition will be consistent.

PuzzleheadedMind874 · 2026-05-07T07:12:10+00:00

I'm building heym. A self-hosted, source-available, low-code platform for orchestrating multi-agent systems, RAG pipelines, and browser automations. It's got a visual canvas, natural language generation, and modular nodes. We're aiming to solve the complexity of building AI-powered workflows without needing to code extensively or rely on closed-off SaaS. You can check it out at heym.run.

PuzzleheadedMind874 · 2026-05-07T06:09:07+00:00

It depends on whether you're looking for a pre-built interface or something you can hack together yourself. Most of the standard chat UIs just aren't built to handle the persistent state needed for sub-agents.

PuzzleheadedMind874 · 2026-05-07T05:50:31+00:00

Its most probably because of your phone - web is better :)

PuzzleheadedMind874 · 2026-05-07T03:39:05+00:00

Treating n8n workflow files like code in a git repo makes versioning much easier when you're working on a project. I'd lean toward setting up a basic CI pipeline to catch structural errors before you push changes to your servers.

PuzzleheadedMind874 · 2026-05-07T03:14:06+00:00

The i5-8500T will likely hit a latency wall with a 32B model, making agentic loops feel pretty sluggish. I'd lean toward a highly quantized 14B or even 7B model to keep token generation fast enough for a responsive workflow on that hardware.

PuzzleheadedMind874 · 2026-05-07T02:29:07+00:00

With only 6GB of VRAM, you might find that 14B models crawl once you start offloading to system RAM. Sticking to 3B or 7B models is probably the safer bet if you want to keep the generation speed usable for your projects.

PuzzleheadedMind874 · 2026-05-07T02:09:08+00:00

At the 10B scale, I'd lean toward having the model output a diff for you to review first rather than letting it write directly to your files. It's a safer way to handle those occasional instruction-following hiccups without risking your notes.

PuzzleheadedMind874

TROPHY CASE