Key facts
| MSP fit | Host once, serve many clients with tenant-aware routing and keys |
| Deployment | Same OpenAI-compatible API in your data centre, client site or air-gapped |
| Data path | Client prompts and logs stay within the hosting boundary you agree |
| Live endpoints | Chat, streaming, function calling, JSON mode and embeddings |
| Tenant isolation | Workspaces, scoped keys and namespaced retrieval per client |
| Operations | MSP owns capacity, upgrades, monitoring and support in hosted mode |
| Audit | Key lifecycle and inference events exportable to SIEM, tagged per client |
| Pricing | Flat monthly self-serve plans; hosted deployment scoped on the pricing page |
TL;DR
- Host once and serve many clients with a tenant-aware gateway and per-client keys.
- Keep each client's data, retrieval namespace and logs inside the hosting boundary you promised.
- Package capacity tiers so heavy clients pay for the headroom they consume.
- Automate onboarding and offboarding with key, namespace and evidence steps.
- Sell it as managed private AI: infrastructure, model updates and audit reporting included.
How it works, step by step
- Decide the hosting model per client: MSP data centre, client site or an air-gapped enclave, and record the data boundary in the contract.
- Size shared capacity by aggregating peak concurrency across tenants with headroom, and define tier limits so one client cannot starve others.
- Build a tenant-aware gateway that resolves the client, enforces quota and model policy, and attaches the right scoped key server-side.
- Provision per-client workspaces, keys and retrieval namespaces through an automated onboarding runbook.
- Wire monitoring, alerting and per-client usage reporting into your service desk, and stream key and inference events to your SIEM.
- Define model update windows and communicate them to clients; test rollback before changing production bundles.
- Run an offboarding runbook that revokes keys, freezes namespaces and hands the client an evidence pack.
Try it yourself
Open the private LLM cost estimator →
The hosted-service model
On-prem AI is a natural managed service: clients want the data-boundary guarantees of self-hosting without hiring the platform team. The MSP runs the deployment — in its own data centre, at the client site or in an isolated enclave — and exposes the same OpenAI-compatible API that any cloud application already uses. Clients integrate once and get an endpoint that never leaves the agreed boundary.
The commercial shape usually combines a platform fee with capacity tiers, plus optional management for client applications. Flat monthly plans keep your vendor cost base stable so hosting margins are predictable; see the live pricing page for current options.
Tenant isolation on shared hardware
Hosting many clients on one deployment makes isolation the core engineering problem. Route every request through a tenant-aware gateway that resolves the client from the session, enforces quota and model policy, and attaches the correct scoped key without exposing it to the client application.
- Keys: one set per client, system and environment, stored centrally and rotated.
- Retrieval: namespaced per client so data can never surface across tenants.
- Quota: tier limits protect shared capacity from noisy neighbours.
- Evidence: logs and key events tagged with the client identifier for reporting.
Operations, packaging and honest limits
Managed hosting means owning capacity planning, upgrades, monitoring and incident response, so price the service accordingly and document the support boundaries. Model bundle updates should follow a published window with rollback tested; clients will ask what changes and when.
Be precise in contracts about endpoint coverage — chat, streaming, JSON mode, function calling and embeddings are live, while audio, images, files and batch are labelled coming soon — and about responsibilities: the MSP owns infrastructure and isolation, the client owns its data classifications and end-user policies. That clarity is what makes an on-prem AI service sellable to regulated clients.
Honest comparison
| Concern | MSP-hosted Plugsky | Per-client cloud accounts | Client-built platform |
|---|---|---|---|
| Time to serve client | Days via onboarding runbook | Days, but per-account setup repeats | Quarters |
| Isolation | Tenant gateway, keys and namespaces | Account separation | Custom, client-owned |
| Operations | MSP owns capacity and updates | Split responsibility | Client owns everything |
| Cost shape | Platform fee plus tiers | Usage per account | Capex plus hiring |
| Evidence | Per-client key and inference events | Per-account logs | Client SIEM only |
Frequently asked questions
Can we host for clients in their own data centre?
Yes. The same deployment runs in your data centre, a client site or an air-gapped enclave, and the OpenAI-compatible API is identical in each.
How do we stop one client consuming all capacity?
Aggregate peak concurrency with headroom and enforce per-tenant quota and rate limits at the gateway, then align tiers with what each client pays for.
How is client data kept separate?
Separate workspaces, scoped keys and namespaced retrieval, enforced at the gateway. Logs and key events are tagged by client for reporting.
Who updates models?
The MSP, on a published window with rollback tested first. Confirm which model bundles are included under the licensing agreement.
What can we sell alongside hosting?
Onboarding, application integration, monitoring, per-client usage reporting and audit evidence packs — the operational work regulated clients prefer to outsource.
How do we offboard a client?
Revoke their keys, freeze and archive their namespaces, remove their policy entries, and deliver an evidence pack covering access and model activity.
Is there a smaller starting point?
Yes. Begin with a single deployment and two clients on the free plan for development, then scale once the runbook and capacity model are proven.