Most people running n8n for clients end up with one instance per client, separate and client-owned, which is the sane call for isolation and roughly what the license nudges you toward anyway. The catch is that past a few clients it gets painful: the same workflow change redone on every instance, credentials rebuilt on each one, and failures that surface when the client notices before you do.
There wasn’t really a tool for managing the whole fleet, so I built one. It works over the standard public API and doesn’t host or bundle n8n, so it stays clear of the Sustainable Use License. Roughly what it does:
Keep a golden version of a workflow and push it to whatever instances you pick, with each client’s own credentials injected and per-client variables filled in. If one instance fails, the rest still go.
Drift detection for when someone hand-edits a deployed workflow. It compares a canonical hash so per-client creds and variables don’t count, only real edits, and you get a diff plus a one-click re-sync.
Fleet-wide execution polling with failure alerts (Telegram or webhook), and a basic monthly per-client report: runs, success rate, hours saved.
A few things I ran into building it, in case it helps anyone:
n8n rewrites a workflow on save (settings defaults, version metadata, node ids), so you compare the canonical form of what the API returns, not what you sent, or everything looks drifted.
Webhook nodes need a webhookId or the deployed webhook 404s. The editor adds one for you, the API doesn’t.
No “run workflow” endpoint on the public API, so you trigger through the production webhook.
It’s a product (Flotilla), but there’s a free tier (2 instances) and you can point it at a workflow you
already run to watch it for drift without deploying anything, so it’s quick to try:
Still early. Mostly I want to know if this is a real pain for people here, or if I’ve misjudged it. Happy
to dig into the drift or credential side if anyone’s curious.
This feels like the deploy/control-plane half of agency ops. The part I would keep separate is the support record after a push: which client got which version, what broke after deploy, what got fixed, and what can be shown back to the client later. That is basically the lane I am testing with Maintain Flow: not fleet management, just the check → issue → fix note → report layer after workflows are live.
Yeah, that split makes sense to me. Flotilla touches the post-deploy side a little, it polls executions, alerts on failures, keeps an audit log of which instance got which version, and does a basic monthly per-client report, but you’re right that a real support record is a different job from deploy plus drift. Deploy and drift are state in the moment; “what broke after this push, what we did, what the client sees” is a timeline, and stapling those two together in one tool gets muddy fast. The part I found genuinely hard is attribution: tying a failure back to a specific deploy/version instead of just “this workflow errored today”. How are you handling that in Maintain Flow, keying the record to the workflow version or to a time window around each push? Curious how you frame the fix-note to client-report handoff too.
Good question. I would track both, but I would not pretend the attribution is cleaner than it is.
If the agency has a deploy id / workflow version / change note, the issue should attach to that. If not, I would key it to the time window around the push or failed check and show that honestly as “this happened after X change / during Y window”.
The handoff I want is simple: failed check → issue → fix note → follow-up check → report line. The client report should say what broke, what changed, what evidence confirmed it, and what is still being watched.
So Maintain Flow is less “this deploy definitely caused it” and more “here is the support timeline and confidence level”. Exact version attribution is great when the upstream tool gives it, but the report still has to be useful when all you have is time-window evidence.
