"Self-hosted or managed?" sounds like an infrastructure question. It is really a governance question wearing an infrastructure costume. Where your agents run determines where your data lives, who carries the operational burden, and how much of your risk posture you control directly. Getting it right is less about preference and more about matching the deployment to the sensitivity of the work.
Meta3Agents ships in three tiers — self-hosted, managed, and multi-tenant enterprise — and the governance model is identical across all three. The four rungs of trust, the gating, the kill-switch, and the audit trail do not change with the deployment tier. What changes is the boundary your data sits inside and who runs the machinery. Here is how to decide.
In a self-hosted deployment, the full platform runs on your own infrastructure, with all capabilities and your data inside your boundary. Nothing leaves your environment as part of normal operation. For organizations with strict data-residency requirements, sensitive proprietary information, or a regulatory context that makes external processing a non-starter, this is often the only acceptable option.
The trade-off is ownership of the operational burden. You run the containers, manage the upgrades, monitor the system, and own the uptime. The platform is delivered containerized with CI/CD to make this as clean as possible, but self-hosting means your team carries the day-two responsibilities. Choose this when control of the data boundary outweighs the cost of operating the system yourself.
In a managed deployment, we run the infrastructure for you — fully managed operations with monitoring and support — while you get the same governed agents and the same controls. This suits teams that want the capability and the governance but do not want to staff the operational side, or that would rather their people focus on the work the agents support than on keeping the platform running.
The trade-off is the inverse of self-hosting: you give up direct control of the infrastructure in exchange for offloading the burden of running it. For many organizations whose data sensitivity does not mandate an in-boundary deployment, this is the pragmatic default. Exact data-handling terms for managed deployments are confirmed in your agreement, and your content is not used to train third-party foundation models as part of normal operation.
The enterprise tier adds multi-tenant isolation, private integrations, and dedicated engineering. This is for organizations running governed agents across multiple teams, business units, or downstream clients who each need their data and execution kept separate. Tenant boundaries, client-scoped execution, and data-retention windows are configured per deployment. Where you need both the leverage of a shared platform and hard separation between the parties using it, this is the model built for it.
Three questions usually settle it:
Notice what is not on this list: the strength of the governance. Because the four rungs, the gating, the kill-switch, and the audit trail are constant across tiers, you are never trading away control to get the deployment shape you need. You choose where it runs based on data, operations, and isolation — and keep the same command over the agents regardless.
One reason this decision is less fraught than it first appears: it is not a one-way door. Organizations frequently start managed to get value quickly while their team comes up to speed, then migrate to self-hosted as the use case matures and the data sensitivity becomes clearer. Others run a hybrid posture, keeping the most sensitive workflows in-boundary while letting lower-risk work run managed. Because the governance model and the agent behavior are identical across tiers, moving between them changes operations and data boundary without forcing you to re-learn how to control the agents or re-establish trust in them.
This is worth keeping in mind when the decision feels high-stakes. You are choosing where to run a system whose controls do not change, not committing to a governance philosophy you can never revise. Start with the tier that matches your current data sensitivity and operational capacity, and revisit it as both evolve.
It is worth restating the constant, because it is the most important fact in this whole decision. Across self-hosted, managed, and multi-tenant, the same things hold: agents earn authority through evidence and calibrated confidence; consequential actions are gated and high-impact or externally consequential workflows carry a quadruple-gate; a supreme kill-switch sits over anything that touches the real world; and every decision lands in a hash-chained, replayable audit trail. No tier is a "lite" version of governance. The deployment question is purely about boundary, operations, and isolation — never about how much control you retain over the agents themselves.
The Deployment models page lays out all the options, including private cloud, hybrid, white-label, and embedded variants. The Trust Center documents how the constant governance controls are implemented, and the Security page covers the isolation mechanics in depth.
Compare self-hosted, managed, private cloud, and multi-tenant — same governance, different boundary.
Compare deployment models →