Why we chose self-hosted over SaaS for agent orchestration
Modulo Team
Why we chose self-hosted over SaaS for agent orchestration
The default assumption in 2026 is SaaS for everything. You do not run your own email, your own CRM, or your own CI runners. Why would you run your own agent orchestration platform?
The answer is that agent orchestration is different from every other SaaS category. When you use a SaaS agent platform, your prompts, pipeline definitions, audit logs, model configurations, and every agent output live on someone else's infrastructure. That is not a theoretical concern - it has concrete consequences for how you can use the system.
What you give up with SaaS
Data sovereignty. Every prompt you write, every pipeline you build, every agent output, and every audit event lives in the SaaS vendor's database. If you are in a regulated industry - finance, healthcare, defense, government - that is often a hard block, not a negotiable trade-off.
Vendor lock-in. Your pipeline definitions, connector configurations, and agent prompts are all stored in the vendor's format on the vendor's infrastructure. Switching costs are high because your entire configuration is someone else's data.
Audit ownership. The audit trail is the most valuable output of a governed agent system. If the audit trail lives in a SaaS database, you do not truly own it. You have read access, but the vendor controls retention, export formats, and deletion policies.
Upgrade control. When the vendor pushes a new version, your pipelines run on it immediately. You cannot test against the new version, pin to a known-good version, or roll back if the upgrade breaks something.
Cost model. Most SaaS agent platforms charge per seat, per agent invocation, or per token. As your usage grows, the cost grows linearly with value. Self-hosted has no per-unit pricing.
What self-hosted gives you
Full control. You deploy Modulo on your infrastructure - Docker Compose on a single machine, or a cluster behind a load balancer. Your data never leaves your network. Your audit trail is your database, your retention policy, your export format.
Data sovereignty. For regulated teams, this is the difference between "we can use this" and "we cannot." Self-hosted means no data residency concerns, no third-party access to agent outputs, no cloud dependency.
Audit ownership. The audit events are in your Postgres database. You control retention, backup, export, and deletion. SOC 2 evidence export is a feature of the software, not a request to the vendor.
Upgrade control. You choose when to upgrade. You can test against a staging instance, pin to a known-good version, and roll back if something breaks. Your pipelines do not change unless you decide they do.
Predictable cost. No per-seat pricing, no per-invocation fees, no per-token charges. The cost is the infrastructure you choose to run it on.
The trade-off
Self-hosted means you manage the infrastructure. For Modulo, that is Docker Compose on a single machine or a small cluster. The operational cost is minimal - Postgres and Redis are well-understood technologies - but it is not zero. If you do not want to manage infrastructure at all, the hosted demo at demo.modulo.run is available for evaluation.
For production use, especially in regulated environments, self-hosted is the only model that gives you the control and sovereignty that governed automation requires. We built Modulo self-hosted first because we believe governance without data ownership is theatre.
The principle behind this: self-hosted, no telemetry - your infra, your data, no cloud dependency.