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

[Michael_Frostbutter]

Two more drops since the v0.4.2 security release, both aimed at folks running this across a bunch of instances. One fixes a real n8n deployment gap, the other is straight off the "what's coming next" list.

Python Code nodes just work in deployed n8n

If you stand up n8n from AgeniusDesk, Python Code nodes now run out of the box. The catch before: the stock n8n image ships no Python 3, so the in-process Python runner never started and Python Code nodes failed. The built-in n8n template now deploys as a two-container bundle, n8n running its task runners in external mode plus an n8nio/runners sidecar that carries the JavaScript and Python runners. That fixes Python, and it also isolates JavaScript execution, which is n8n's recommended production posture anyway.

The Python standard library is open by default (json, datetime, re, hashlib, and friends); third-party pip packages still need a custom runners image. Existing template-deployed instances pick this up on their next redeploy or recreate, with workflows, credentials, and data preserved.

Scheduled backups, with offsite storage

Second on the roadmap list, now in. Automated per-instance workflow backups on a schedule, so you are not relying on manual exports. Set an interval and how many snapshots to keep, and it snapshots every connected instance to disk, fanning out across the whole fleet no matter which instance is active. A failing or unreachable instance is isolated, the rest still run. Off by default, and the schedule is read live, so toggling it takes effect with no restart.

It picked up a bonus on the way out the door: offsite storage. A backup that only lives on the same box as the app dies with the box, so each snapshot can now also push to S3-compatible object storage: AWS S3, Cloudflare R2, Backblaze B2, Wasabi, or a self-hosted MinIO. The local copy is always written first and the offsite push is best-effort on top, so a failed upload never costs you the local snapshot. Credentials stay in the secret store as references, never in plain config. Retention mirrors offsite, and there is an option to encrypt each snapshot before it leaves the host.

On cost: Cloudflare R2's free plan gives you 10 GB and, unlike most object stores, no egress fees, so restores never cost anything. Workflow snapshots are small JSON, a few MB each, so 10 GB holds years of fleet backups for free. Backblaze B2's 10 GB free tier works the same way. Point every client instance at one bucket and you have a rolling, retained, offsite copy of all their workflows, generated on a schedule without anyone touching an export button.

Local models stop showing "price unknown"

Small one from the cost side. Ollama and other local models were getting tagged "price unknown" in the trace cost view, the same label as a cloud model the price book simply had not caught up to. They now show their token usage with a plain "local" tag instead of a meaningless dollar figure. An operator price override still wins if you set one.

Still on the list

Scheduled health reports are next: the recurring, client-ready per-instance summary that generates and delivers itself over your notification sinks or email. Workflow version history, the Uptime Kuma connector folded into Fleet Health, expanded notification routing, and the workflow security audit scan are still queued. The support inbox / ticketing module is the big agency one.

Open to feedback on order. If offsite backups or the scheduled reporting is the piece that unblocks running this for clients, say so and it moves up.

Michael

[Michael_Frostbutter]

I've been working really hard on trying to figure out an issue that bites a lot of people. Detecting silent failures before they become a client issue: the runs that report success while a node quietly drops work. What I was treating as one problem is really four failure classes, each with its own layer:

• A node runs but returns less than it should (a swallowed 503, a query that drifts to 5 rows instead of 500). Item-count and output-shape anomaly, with a declared must-produce flag so a node whose role is to always return rows never treats zero as normal.
• A node continues past an error but the run stays green. This one turned out to be the hard case, covered below.
• A node that should have run did not (a skipped branch, an empty upstream node). Caught by diffing the workflow's declared nodes against the spans that actually landed for that execution.
• The workflow never fired. External heartbeat, since nothing inside n8n sees its own absence.

One rule holds it together: keep input history next to output history, so a node starved by an upstream drop is flagged as the victim, not the origin. One root cause, one alert.

On the continued-error class: I first assumed I could read it off the OpenTelemetry span by inspecting the node's output. I built that and took it apart, because it is unsound. A field named error in legitimate output is identical to a swallowed error, and error markers ride on the items themselves, so a pass-through node forwards a stale one and looks like it failed. The fact that distinguishes a real continued error, that a catch fired and the node chose to continue, only exists inside the node at the moment it swallows.

So I stopped inferring it downstream. n8n holds the typed error one step before it demotes it into the output item and exports the span as OK. The fix is to record it there, in core, once, and let every consumer read it: the span, the editor UI, a detector. I built a proof of concept and validated it against a live n8n to OTLP to Jaeger pipeline. Same green run, a continue-on-fail node eats a 503, and the node span comes through as Error with the status attached, while the parent execution span stays OK. I am working on getting that upstream, because fixed at the source it helps everyone's detection.

Before:

After:

These workflows are going into production, so a green run has to mean green. A good part of the detector's complexity exists only because the platform drops a signal it already has, so the higher-leverage move is to put that signal back rather than reconstruct it downstream.

Two open questions: how people run the heartbeat layer in practice, and whether a declared must-produce flag is the right shape for the floor or whether it should be automatic.