Automation platforms are powerful, but they can become messy when they are asked to own everything.
BoringOps uses two automation runtimes with different roles: n8n for rapid prototyping and Windmill for production flows. The operational truth stays in BoringOps either way.
Two runtimes, one purpose
n8n is the prototyping sandbox. New integration ideas start here. The visual editor makes it fast to wire up a new channel, test a webhook, or sketch a multi-step flow. When a prototype is ready to harden for production, it graduates to Windmill.
Windmill is the production executor. Flows deployed to Windmill run as version-controlled scripts with typed inputs, structured error handling, and a durable execution log. BoringOps routes each flow to the right runtime based on which path is set in the flow catalogue — no global switch, no big bang migration.
Both runtimes orchestrate. Neither owns the business.
Workflows should orchestrate, not own the business
A workflow — whether in n8n or Windmill — can receive a WhatsApp message, call an API, wait for approval, post to Xero, or send a reply.
What it should not be forced to own is the durable domain model: jobs, approvals, tenant permissions, reference numbers, audit history, and operational status.
Those belong in the platform database and API, where rules can be enforced consistently regardless of which runtime executed the flow.
This boundary keeps operations inspectable
When workflows are the only source of truth, teams eventually have to inspect execution histories to understand the business.
That is not a good operating surface for SMEs.
Instead, n8n execution should leave behind readable business records: a job was created, an approval is pending, an integration is blocked, a callback completed, a dispatch failed and can be replayed.
The portal should show the operational story. n8n should do the integration work behind it.
Ingress and completion are separate concerns
Many real workflows are not instant.
A request arrives, the system creates a job, an approval is needed, a manager approves, and the workflow resumes to notify the requester or update an external system.
In production flows, Windmill dispatches work and BoringOps signals completion back via a Postgres notify channel — no polling, no tight coupling. The approval record and final decision live in BoringOps; Windmill receives the outcome and acts on it.
Reliability needs a record too
Integrations fail. APIs time out. Credentials expire. External systems return unexpected responses.
That is normal. What matters is whether the team can see the failure, retry safely, and understand the impact.
Keeping dispatch logs, failed events, and execution timelines in the platform makes automation supportable instead of mysterious.
