Deployment models
The same platform runs in three shapes. What changes is where it sits and who operates it. What does not change is the security model: identity, role scoping, injection detection, secret stripping and audit are identical in all three, because they are the product rather than a feature of the hosting.
The three models
| Managed cloud | Private instance | Self-hosted | |
|---|---|---|---|
| Where it runs | Msharti infrastructure, on-continent | Dedicated instance, isolated from other tenants | Inside your own network |
| Who operates it | Msharti | Msharti | You, with our support |
| Tenancy | Multi-tenant, isolated at credential, container and database row | Single tenant | Single tenant |
| Data leaves your network | To the connector, as it would to any SaaS | To the connector | No |
| Upgrades | Continuous, no action needed | Continuous, coordinated with you | On your schedule |
| Availability | All plans | Enterprise | Enterprise |
Choosing between them
You want to be answering real questions this week, your regulator does not require the data plane to stay inside your perimeter, and you would rather not run infrastructure. This is the right default for most organisations, including most mid-market finance teams.
You need single tenancy for a contractual or audit reason, want your own upgrade window, or have throughput that deserves dedicated capacity. Operationally it behaves like managed cloud; the isolation guarantee is simply stronger.
You are a bank, a SACCO or a regulated institution whose policy is that business data does not leave the network. The platform runs inside your perimeter and connects to systems that are already there.
OAuth 2.1 identity, role-scoped tools, prompt-injection detection, secret stripping, immutable audit, encrypted credentials, read-only database enforcement. None of it is a hosted-only feature.
Data residency
On managed cloud, data is hosted on-continent. For institutions that need it, self-hosted deployment inside Kenya removes the question entirely. The residency detail, including what is stored versus what is passed through, is in security and data protection.
Msharti is a pass-through by default. Business records are fetched, used to answer, and not retained, unless you subscribe to a retention add-on. Retention is opt-in per connector, not a platform default. See limits and plans.
Moving between models
Connector configuration, roles and team structure are portable. Moving from managed cloud to a private instance or on-premise means re-authenticating connectors against the new deployment, because OAuth tokens are bound to the instance that obtained them, and issuing fresh API keys. Roles and allowlists come across as definitions rather than needing to be rebuilt by hand.
Migrations are scoped with you rather than self-serve. Start that conversation and we will plan the cutover.