Infrastructure built for the managed service provider operating model

The MSP Challenge

Managed service providers run multiple customers on shared infrastructure. That makes isolation non-negotiable: one customer cannot see another customer’s inventory, metadata, credentials, audit history, or operational state.

Delegation also has to be precise. A provider needs to hand a customer enough control to operate their environment without exposing the rest of the estate, while federation across sites is table stakes for regional capacity, locality, and resilience.

Database-Enforced Isolation

Basalt uses Postgres row-level security at every business table. Tenant boundaries are enforced by the database engine itself, not by application-layer filters, folder hierarchies, naming conventions, or UI-only scoping.

That distinction matters for MSP risk. Even if an application bug asks for data outside the active tenant, the database policy prevents cross-tenant rows from being returned. Review the security architecture for how Basalt treats isolation as a control-plane invariant.

Multi-Region Federation

Basalt federation uses a global controller that registers regional gateways. Users sign in once and see only the regions they are entitled to access, so regional capacity can be presented without flattening every customer into one undifferentiated admin surface.

Service-to-service trust is protected with HMAC-signed service tokens, and regional health checks run every 30 seconds. That gives providers a single operating view while preserving regional boundaries and failure domains. See the platform architecture for the federation shape.

Cluster-Scoped RBAC

Basalt RBAC includes approximately 200 granular permissions in a resource-action model across system, tenant, and cluster scope levels. Permissions can be composed into custom role definitions per tenant.

In practice, that means you can hand a customer admin rights to one cluster without exposing the rest of the provider estate. Provider staff keep system-level authority, tenant administrators get their delegated boundary, and cluster operators receive only the verbs required for their scope.

Tenant Lifecycle

Tenants move through active, suspended, and deleted states. Suspension gives providers a controlled operational state for billing, incident response, or contractual holds without erasing historical context.

Users with multi-tenant access can switch tenants deliberately, so provider operators and customer delegates work inside an explicit tenant context. That supports white-label delivery: the same underlying Basalt platform can present customer-scoped operations without leaking provider-internal identifiers or adjacent customer details.

Operational Capabilities for Shared Infrastructure

MSPs still need the day-two infrastructure surface: deploy and recover VMs, assign customer capacity, and run delegated operations without a separate toolchain. Basalt’s compute capabilities expose lifecycle, migration, templates, console access, and recovery actions through one API.

Managed service provider FAQ

Is tenant isolation enforced only in the application?

No. Basalt uses Postgres row-level security so the database engine enforces tenant isolation even when application code is wrong.

Can one customer administer only one cluster?

Yes. Cluster-scoped RBAC lets providers delegate customer administration to a specific cluster without exposing other tenants, regions, or provider-wide controls.