Key facts
| MSP fit | Host once, serve many clients inside agreed boundaries |
| Private access | Private endpoints; traffic stays in the deployment you select |
| Tenant isolation | Workspaces, scoped keys and namespaced retrieval per client |
| Retention | Configurable prompt retention per workload; confirm terms in the DPA |
| Audit | Inference, key and admin events tagged per client and exported to SIEM |
| Models | 30+ models behind one OpenAI-compatible API |
| Pricing | Flat monthly self-serve plans; hosted deployment scoped on the pricing page |
| Free plan | plugsky-micro and plugsky-lite, no card; 14-day full-access trial |
TL;DR
- Let the client's data boundary drive the hosting model, then keep one API for all tenants.
- Route everything through a tenant-aware gateway with per-client keys and quota.
- Keep retrieval namespaces disjoint so one client's data cannot surface in another's.
- Tag audit events per client so you can hand over evidence on request.
- Price the managed layer: capacity, upgrades, monitoring and support are the service.
How it works, step by step
- Agree the data boundary per client in writing — MSP data centre, client site, region-locked plane or air-gapped — and map it to a deployment.
- Build the tenant-aware gateway: resolve the client from the session, enforce quota and model policy, attach the right scoped key server-side.
- Automate onboarding: workspace, keys, retrieval namespace and monitoring entries from one runbook.
- Set retention per client workload and confirm the terms in each DPA.
- Tag authentication, key, admin and inference events with the client identifier, and export them to your SIEM.
- Define capacity tiers and publish your upgrade windows so tenants know what to expect.
- Run an offboarding check that revokes keys, freezes namespaces and produces a client evidence pack.
Try it yourself
Open the private LLM cost estimator →
Private AI as a managed service
Clients want the guarantees of private AI without operating it. The MSP proposition is exactly that: a private endpoint, a defined data boundary and predictable capacity, delivered as a service. Plugsky makes the delivery manageable because every deployment variant — region-locked plane, VPC, MSP data centre, client site or air-gapped — exposes the same OpenAI-compatible API, so one integration pattern serves every client.
The service wrapper is what clients pay for: onboarding, tenant isolation, monitoring, model updates and audit reporting. Flat monthly plans keep your underlying cost base stable so the managed margin stays predictable; see the live pricing page for current options.
Isolation and operations
On shared hosting, isolation is the engineering priority. A tenant-aware gateway should resolve the client from the session, enforce tier limits and model policy, and attach the correct scoped key without ever exposing it to the client application. Retrieval stays namespaced, and logs stay tagged.
- Keys: one set per client, system and environment, centrally rotated.
- Quota: tier limits prevent noisy-neighbour effects on shared capacity.
- Retention: configured per client workload and documented in the DPA.
- Evidence: per-client auth, key and inference events in your SIEM for reporting.
Packaging, contracts and honest limits
Sell the service on outcomes and guarantees: boundary, availability, upgrade cadence, support windows and evidence. Be explicit that endpoint coverage is uniform across deployments — chat, streaming, JSON mode, function calling and embeddings are live, while audio, images, files and batch are labelled coming soon — so client expectations match reality from the start.
Also state the responsibility split: the MSP owns infrastructure, isolation and operations; the client owns its data classifications, end-user access policy and regulatory obligations. That clarity is what lets regulated clients sign without months of legal back-and-forth.
Honest comparison
| Concern | MSP-hosted private AI | Client cloud subscription | Client-built platform |
|---|---|---|---|
| Boundary options | MSP DC, client site, plane or air-gapped | Vendor-defined region | Client data centre |
| Tenant isolation | Gateway, keys and namespaces | Account separation | Custom |
| Management | MSP handles capacity and updates | Split responsibility | Client handles all |
| Evidence | Per-client audit export | Account logs | Client SIEM only |
| Time to value | Days via onboarding runbook | Weeks of setup | Quarters |
Frequently asked questions
Can we host in our own data centre for clients?
Yes. Run the deployment in your data centre, at the client site, in a region-locked plane or air-gapped, and expose the same OpenAI-compatible API in every case.
How do we keep client data separate?
Per-client workspaces, scoped keys and namespaced retrieval, enforced at a tenant-aware gateway. Logs and events are tagged with the client identifier.
Who owns retention decisions?
The client's policy decides, and you implement it per workload. Document the agreed retention in the DPA and verify it in configuration.
What do we tell clients about capability?
The core API is live everywhere: chat, streaming, JSON mode, function calling and embeddings. Audio, images, files, batch, moderation, fine-tuning and assistants are labelled coming soon.
How do we price the service?
Combine a platform fee with capacity tiers, plus optional integration and reporting. Use the live pricing page for your cost base and add a margin for managed operations.
How do we offboard a client?
Revoke their keys, freeze and archive namespaces, remove policy entries and deliver an audit evidence pack covering access and model activity.
How do we start?
One deployment, one or two clients, using the free plan for development and the 14-day full-access trial for realistic load before committing capacity.