The internal automation and AI substrate for a US managed service provider. I proposed it, built it and operate it. Every AI and integration system the company runs internally sits on it: the PSA ticket intelligence pipeline, the Teams assistant, the knowledge-base retrieval pipeline, the multi-tenant client tooling and the fleet-management sync.

n8n in queue mode across five Docker containers, a main instance, a dedicated worker, Postgres 16, Redis 7 and Traefik, on a hardened Ubuntu VM in Azure. Live since September 2025 and still in daily production. Five production systems on a single 2 vCPU virtual machine.

Production architecture was chosen up front rather than retrofitted. Redis-backed queue mode with a separate worker so a long job cannot block the webhook path. Bounded execution retention. A non-root application database user provisioned by an init script. An instance-wide error handler created the same day as the first workflow and later registered in 28 workflows, so a failure anywhere surfaces in one place instead of dying quietly. Daily workflow backups to blob storage. Credentials for every connected system live on the platform rather than scattered through the workflows.

The part I am most pleased with is that other people build on it. Three colleagues and a third-party vendor have shipped their own workflows onto it. The instance holds 109 workflows and 1,284 nodes in total; 68 workflows and 981 nodes are mine. Making an internal platform safe enough for someone else to build on is a different job from making it work.

Honest limits: 47 workflows are active, which means enabled rather than used. Backups run daily and no restore has been tested, so this does not support a disaster-recovery claim. No load test or utilisation series exists. Running cost is not stated because no cost reading was ever taken.