AgeniusDesk CE: a free, open-source control plane for running multiple n8n instances

[Michael_Frostbutter]

Hey everyone,

If you run n8n for clients or across more than one environment, you know the pain: multiple logins, scattered execution logs, and no single picture of what’s broken right now. I built AgeniusDesk Community Edition to fix that for myself, and I’m releasing it free and open-source (MIT) for the community.

It’s a lightweight, self-hosted dashboard that sits on top of the n8n you already run. It talks to any n8n instance over the public API, so there’s nothing to change in your workflows.

What it does

• One-click n8n deploy. Spin up a fresh self-hosted n8n instance in Docker right from the dashboard. Set the name, port, admin login, and timezone in a form, hit deploy, and manage it alongside everything else. The same one-click flow also stands up Postgres, Redis, Qdrant, and Ollama.
• Multi-instance management. Add any number of n8n instances by URL + API key and switch between them instantly. One dashboard for all of them.
• Real-time error visibility. A live error feed across instances, grouped by workflow, node, and error type with occurrence counts. Install a one-click global error handler and failures start showing up here automatically.
• AI error triage. Ask AI to analyze a failure and suggest the root cause.
• Code Lab. A Monaco editor for n8n Code-node logic with AI generation/explanation, a structured Prompt Builder, and one-click “Send to n8n.” Pairs really well with n8n-mcp by czlonkowski for deep node knowledge.
• Per-area AI models. Code Lab, error triage, and the general assistant each get their own provider/model (OpenRouter, OpenAI, Anthropic, or local Ollama). Keys live in an encrypted store and never touch the browser.
• Insights. Success rates, execution timeline, and busiest/slowest workflows per instance.
• The Harness. A markdown knowledge vault plus agent instructions the assistant works from.

Run it

git clone https://github.com/Mfrostbutter/ageniusdesk-ce.git`
cd ageniusdesk-ce
cp .env.example .env
docker compose up -d --build`

Open http://localhost:3000 and a setup wizard walks you through connecting your first instance.

Repo: GitHub - Mfrostbutter/ageniusdesk-ce: The command center for n8n automation operators: multi-instance management, real-time error tracking, AI-assisted debugging, a Code Lab, and one-click container deployment. Self-hosted, source-available (MIT). · GitHub

Built-in login, encrypted secrets, role-based access, and a security-hardening pass are all in there. Full docs (user guide + architecture) live in /docs.

I’m putting up a full walkthrough video on YouTube later today and will drop the link in this thread.

This is an early release and I’d genuinely love feedback from people running n8n in anger. What’s missing, what’s confusing, what would make it part of your daily workflow? Happy to answer anything here.

Cheers,
Michael (founder, Agenius AI Labs)

[Michael_Frostbutter]

I would really love someone to test the n8n cloud integration. I don’t currently use the cloud version.

[nguyenthieutoan]

Welcome @Michael_Frostbutter!

The Harness concept is the part that stands out most to me - a centralized knowledge vault for agent instructions across multiple instances solves a real pain point for anyone managing several client environments. Right now I’m maintaining separate Text nodes in each workflow as a workaround.

The Code Lab with a “Send to n8n” button is also a solid idea - being able to write and test Code node logic outside the main canvas before dropping it in would speed up iteration a lot. Happy to test the cloud integration if you want a second set of eyes on it.

[Michael_Frostbutter]

Here’s a full walk through on YouTube

One Dashboard for EVERY n8n You Run (Free & Open Source)

[Michael_Frostbutter]

Feel free to fork the repo and play with it!

GitHub - Mfrostbutter/ageniusdesk-ce: The command center for n8n automation operators:...

[Michael_Frostbutter]

Just added OpenTelemerty for observability as well as cost!

[Michael_Frostbutter]

Lots of updates made, website is live and there’s a click through mockup demo of the app online now.

AgeniusDesk — Every automation, one desk.

[Ahmad_Shakir]

This is very close to the pain agencies hit once one client becomes ten.

I’d make the instance boundary really explicit: which API key can touch which workflows, where errors are aggregated, and what receipt proves a fix or redeploy happened on the right client instance. Do you track key rotation or per-client audit history yet?

[Michael_Frostbutter]

You’ve named the exact axis. Right now the instance is the boundary in the data
model, but not yet in access control. Honestly:

What’s there today

• Each client is its own n8n instance with its own encrypted API key (stored as a
  reference, not inlined). A workflow lives on one instance, so “which key can
  touch which workflows” is answered at the instance level.
• Errors, executions, and health are aggregated per instance, so the error view
  is per-client by construction.
• The one real receipt is the module-install audit: who approved it, when, the
  exact commit, and the capabilities they consented to.

What’s not there yet (and it’s what you’re poking at)

• RBAC is global (viewer/operator/admin across the dashboard), not per-client.
  There’s no “this operator can only touch client A’s instance.”
• No key-rotation history, and no per-action audit trail that proves operator X
  redeployed workflow Y on client Z at time T. Module installs are the only
  audited action so far.

Per-client access scoping plus an action-level audit log (the redeploy/fix
receipt) is the next layer on the roadmap. The work I’ve been shipping lately is
the sibling of this problem: sandboxing community-module code so an add-in can’t
reach across boundaries. Same instinct, applied to the multi-tenant control plane
next.

[Michael_Frostbutter]

Folding in a Fleet Health View now to aggregate errors across instances Thanks for the idea

[Michael_Frostbutter]

Hey guys,

I have been super busy this weekend, so here is everything that landed. Two releases since launch.

A few of these I dropped in the thread as they shipped, so quick recap on those:

• OpenTelemetry tracing, in the dashboard. Runs emit OTel spans and you watch the full waterfall right in the UI: every step, how long it took, where the time actually went. No separate tracing stack to stand up.
• Per-run LLM cost. Each run’s cost comes from its own execution data, input and output tokens against a built-in price book, for an estimated dollar cost per run. No more guessing what a workflow or agent costs to operate.
• Aggregate Fleet Health view. @Ahmad_Shakir this came straight out of your nudge: one pane across every connected instance, active workflows, run stats, and errors rolled up, so you see the health of the whole fleet instead of clicking through instances one at a time.

Now the new stuff.

First community module: YouTube to research doc. @nguyenthieutoan you called the Harness the part that stood out, so this one is for you. Paste a YouTube link, get a structured research document filed straight into your Harness, ready for your agents to use later. It is also the first end-to-end proof of the community module system.

n8n intelligence, installed for you. On first boot AgeniusDesk auto-installs n8n-mcp by czlonkowski as a running MCP server, and full credit to czlonkowski for that project, it is what gives the assistant deep n8n node knowledge plus workflow search, validation, and create/update tools. It also seeds a curated n8n skill library into your workspace, so Code Lab and the assistant build workflows correctly the first time. Both are best-effort and opt-out (AGD_N8N_MCP_AUTO=false, AGD_SEED_SKILLS=false), and the n8n-mcp card lives under Settings > MCP Servers. This is the other half of the Send-to-n8n flow you liked.

Security on community modules. Modules are third-party code, so install is gated. A two-phase inspect-then-install flow runs a static scan over the module and shows you exactly what it can reach (network, files, secrets, host access) before anything is registered, and you consent to anything risky. Beyond that, a module’s backend can run isolated in its own Docker container, with separate filesystem, process, and network namespaces, instead of in-process. Honest caveat, and the docs say the same: the in-process scan is a heuristic, not containment; the container tier is the real boundary. @Ahmad_Shakir this is the sibling of the multi-tenant boundary problem we were talking about, aimed at add-in code first.

What is next: a deliberate pause. I am holding new features for a bit, on purpose. The goal now is to get people actually running it, gather feedback, and shake out bugs against real usage before the next wave. There is plenty more on the roadmap and it is coming, but stability and real-world use come first.

So here is the ask, and it is the whole point of this window: pull it down, run it, and push it until something breaks. Open an issue when it does, send a PR if you have a fix or an idea. Let’s get this thing working perfectly together.

[Michael_Frostbutter]

Almost forgot

You can now build actual LangGraph and PydanticAI agents right in Code Lab (the new Agent Builder mode): pick a framework, start from a scaffold (ReAct tool loop, human-in-the-loop, or parallel fan-out), and write the agent. Register it and it shows up in the Agent Fleet, where you run and monitor it the same way you run n8n. You get a live node graph for LangGraph agents, a normalized run waterfall that looks the same for either framework, and human-in-the-loop agents that pause for your approval and resume from exactly where they stopped. Agents are plain files in your vault that you own, so you can edit, export, or delete them, and the fleet picks up changes with no restart.

[Michael_Frostbutter]

@nguyenthieutoan have you had a chance to play with it on the cloud version yet?

[cadence_flows]

The audit trail piece you mentioned in post 8 has a specific failure mode worth guarding against: a repair that starts but fails midway leaves the health view green while the underlying issue persists, with no record of what was attempted.

The pattern that prevents this: write the repair receipt before the action fires, not after. When your fleet view detects a problem and routes a fix to the right instance, the first step in that repair workflow is a log entry – instance ID, workflow ID, action type, timestamp, current state snapshot, initiator. Then execute the repair. If the fix fails halfway, the log already exists. You know what was attempted, when, on which client, and from what state. Without this, a partial repair is silent: nothing in the health view flags it, and reconstructing what happened means trawling execution logs that may themselves be incomplete.

The cheap implementation before you have a full audit system is a Google Sheets append-before-execute step inside each repair workflow. One row per action. When something goes wrong across several client instances overnight, that sheet tells you which clients you already touched and what you did, without guessing.

The same principle applies to credential rotation: write the rotation event to the log first, rotate second. A failed rotation attempt looks identical to “never attempted” if the receipt waits until after the action – and that ambiguity is exactly what causes duplicate rotation runs or missed clients in a multi-instance setup.

[nguyenthieutoan]

Haven’t had a chance to test it on n8n Cloud yet - I’m mostly on self-hosted Docker setups across client environments. That said, since AgeniusDesk talks to n8n over the public API, I’d expect the connection flow to be the same. Planning to spin up a trial Cloud instance to verify. The per-run LLM cost view you shipped is exactly what I’ve been wanting - makes it much easier to scope client projects accurately.

[Michael_Frostbutter]

@nguyenthieutoan It is just an estimate based on a price book that will obviously change as time wears on and models are deprecated and pricing structures change.

The thing I find the most valuable is the ability to use what I call the Capability vs Cost metric. I’m very much a believer in being vendor agnostic in my system architecture when it comes to models. I always test multiple and track latency, cost and actual output vs expected, as well as tool calling reliability. And that’s how I choose what that architecture maps out to be.

If my testing reveals a combination that’s 80% better on the output and reliability side but costs 10% more to run…I’ll spend a little more on the workflow to ensure it’s production ready. And you can’t make informed decisions like that without the data.

How pricing/cost tracking works in AgeniusDesk’s observability waterfall

Token capture: Cost isn’t pulled from OTLP spans (n8n doesn’t emit token/cost data there). Instead, when you open a trace in the waterfall, cost.py lazily fetches that execution’s raw run-data from n8n and pulls promptTokens/completionTokens out of the AI Language Model node’s output.

The price book (backend/modules/observability/pricing.py): Three-tier lookup, in priority order:

1. Operator overrides you’ve manually pinned
2. A cached table fetched from OpenRouter’s public /models API
3. A small hardcoded fallback (~13 Anthropic/OpenAI models)

Model names get normalized (strip vendor prefix, strip date stamps, strip :free/:beta tags) so anthropic/claude-sonnet-4.6-20260115 matches claude-sonnet-4-6 in the table.

Staleness handling: It’s not fetched fresh on every request. The fetched tier is cached to data/price_book.json with a fetched_at timestamp, and refreshed on a TTL, default 24 hours, configurable via AGD_PRICEBOOK_REFRESH_HOURS. Refresh happens automatically at app startup and can be triggered manually via POST /api/otel/pricing/refresh. If a refresh fetch fails, it logs a warning and keeps serving the last-good cached data rather than going empty. There’s an escape hatch, AGD_PRICEBOOK_DISABLE_REFRESH=1, for air-gapped deployments that never call out. So staleness is bounded to at most ~24h under normal operation, and degrades gracefully (not silently wrong) if OpenRouter is unreachable.

Math: cost = tokens_in/1e6 * price_in + tokens_out/1e6 * price_out, rounded to 6 decimals, written per-span into otel_spans (SQLite), then rolled up with SUM(cost_usd) for trace totals and the 24h metrics strip. No separate cost dashboard, it surfaces in the waterfall detail view and the metrics strip only.

Test coverage: tests/test_otel_receiver.py covers bundled pricing/normalization and end-to-end enrichment math, but nothing tests the OpenRouter refresh path, overrides, or staleness/TTL behavior itself, that’s a gap if you want confidence the refresh actually degrades correctly under failure.

[Rory_Hayes]

The Fleet Health direction is the right one. Once you have more than a handful of client instances, the real question becomes less “can I see all the errors?” and more “can I prove what happened for client X and what was done about it?”

I would make three records first-class:

1. Health event: what failed or went stale, on which instance/workflow, and when.
2. Action receipt: what repair/redeploy/rotation was attempted, by whom, from what starting state.
3. Resolution note: what actually fixed it, whether client impact happened, and whether it should appear in the client report.

The append-before-execute point above is important. A failed repair attempt should still leave a receipt, otherwise “we tried to fix it and failed halfway” looks the same as “nobody touched it.”

That is the layer I am thinking about a lot with Maintain Flow as well: the control plane catches the fleet problem, but the maintenance record is what lets the agency explain and prove the outcome later.

[Michael_Frostbutter]

Update — v0.4.2 is out

Thanks for the interest on this one. Just cut a new release, and it’s a security-led one, so worth grabbing if you’re already running it.

Security hardening (the headline). We ran a full security review and closed four high-severity issues plus a batch of medium/low ones. The short version: tightened who can do what (agent code execution is now admin-only, the container-template and MCP surfaces are locked down against injection and SSRF), and hardened the places where AI/agent output gets rendered so nothing untrusted can run in your dashboard. If you’re self-hosting on anything reachable, upgrade.

Name and port your services in the setup wizard. When you stand up your stack, each service now shows an editable instance name and host port, with live conflict warnings as you type. It tells you up front if a port is already taken (and by which container), if it’s one browsers block, or if two services in the same stack would collide, so you fix it before the deploy fails instead of after. Same warnings on the Containers deploy panel.

Show/hide toggle on password fields. Small quality-of-life thing people asked for: an eyeball to reveal what you’re typing on the setup, sign-in, and reset screens, so a typo gets caught before submit.

Configurable error-reporting window. The Overview now has a lookback picker (24h / 7d / 30d / 90d / all time). It drives the whole dashboard together, so the error feed, failure rate, and execution counts all report over the same window and finally agree with the Insights view.

[Michael_Frostbutter]

What’s coming next

A few things I’m building toward, weighted for folks running this across a bunch of client instances:

Support inbox / ticketing module (agency-focused). If you run AgeniusDesk for an agency, your clients’ support requests probably land in a shared support@ mailbox today. We’re building an opt-in module that routes that mailbox straight into the dashboard: each inbound email becomes a ticket in its own inbox view, with a real status lifecycle (open through resolved), AI triage and draft replies through the built-in assistant, and the option to link a ticket to the exact workflow or execution a client is asking about. It’s deliberately separate from the Errors view. Errors are machine-generated workflow failures; tickets are human requests. Same control plane, two different jobs.

Scheduled backups. Automated per-instance workflow backups on a schedule, with configurable retention, so you’re not relying on manual exports.

Scheduled health reports. A recurring (say monthly) per-instance health report that generates and delivers itself without anyone opening the dashboard. It rolls the period’s success and error rates, trends, busiest and slowest workflows, and notable incidents into a client-ready summary sent over your notification sinks or email. For agencies, that’s the client-reporting loop mostly handled for you.

Also in the near-term queue:

• Workflow version history: snapshot on import, a diff viewer, and restore from a snapshot.
• Health/uptime monitoring folded into Fleet Health via an Uptime Kuma connector, so your existing monitors show up next to workflow health instead of being a separate tab.
• Expanded notification routing: email, PagerDuty, and per-instance webhook routing.
• A workflow security audit scan: flags missing error handlers, unused credentials, and exposed webhooks.

Open to feedback on priority. If the support inbox or scheduled reporting is the thing that unblocks you running this for clients, say so and it moves up.

[Rory_Hayes]

The support inbox direction makes sense for agencies. The useful thing is not only getting the client email into the same dashboard; it is linking the request to the operational object it belongs to.

The lifecycle I would want is:

1. Client email becomes a ticket.
2. Ticket links to client, instance, workflow, and execution if known.
3. If it is a real failure, it creates or links to an issue.
4. The issue gets owner, severity, root cause, and resolution.
5. The resolution can be summarized back to the client and included in the next maintenance report.

That keeps support from becoming a separate inbox full of context-free messages. For agency work, the durable trail matters: what the client reported, what workflow it affected, what changed, and whether it should show up in client reporting later.