No shared control plane
There is no central Infraware anything holding all your clients’ data.
Each deployment is complete and alone in that client’s cluster.
For MSPs
Run more clients without running more risk.
Infraware deploys separately into each client’s cluster: their data stays theirs, their audit trail stays theirs, and every fix your engineers ship carries the engineer’s name, evidence you can put on the table at the next SLA review. Scoped to your fleet on the first call.
the msp model · one picture
The isolation model
One deployment per client. Nothing shared.
One Helm install per client cluster. That sentence is the whole multi-client architecture, and it is worth reading twice, because what it removes is the part MSPs get burned by:
No cross-client path
Client A’s logs, reports, and audit trail cannot leak to client B,
because no component exists that ever holds both. Isolation isn’t a
tenancy feature we implemented carefully, it’s a topology in which
the failure can’t be expressed.
Per-client model policy
The bank client serves its model in-cluster with vLLM, zero egress; the startup
client runs Anthropic on their own key. Each deployment’s Helm
values, each client’s call.
Clean offboarding
Client leaves: their audit trail and reports are already in their
cluster’s storage, copy them into the handover file,
helm uninstall, done. Nothing about them is retained
anywhere else, because nowhere else exists.
Honest note: this is the same single-team deployment model our security page describes, we are not hiding a multi-tenant control plane behind an MSP diagram. One client, one deployment, is the offer today, and for this audience it is the right shape.
Engineer leverage
Mornings, not nights.
What first response looks like when it arrives finished: your engineer reviews this, not twenty dashboards.
The MSP math has always been ugly at night. An alert at 02:40 in one client’s cluster costs you a senior engineer’s morning, whichever way it goes.
With Infraware in each client cluster, the 02:40 alert starts Virgil investigating at 02:40, read-only. By the time your engineer sits down, the root-cause report is waiting: evidence collected, cause identified, fix proposed, and nothing touched. The engineer reads three such reports across three clients with coffee, approves two fixes and rejects one, and each execution runs under that engineer’s mapped identity in that client’s cluster, each leaving its audit entry.
40 min of on-call investigation returned per incident, per client, before a human joins. One bench engineer reviews across every client; nobody gets paged to go collect logs.
Typical time to root cause for common Kubernetes failures when a human does the collecting and correlating by hand, the work the read-only investigation finishes before you open the report. An industry-derived figure, stated as such.
The unattended part is strictly read-only, so “the AI investigated overnight in a client’s production cluster” is a sentence you can say to that client with a straight face, and with the config to prove it. How read-only is enforced →
Per-client operations
Your knowledge, operational per client.
Your differentiation as an MSP is that you know each client’s stack. Infraware makes that knowledge operational, per client:
Context, per deployment
Each client’s infrastructure descriptions and procedures live in
their deployment, human-editable, API-managed. The investigation
reads the client’s context, not a generic one.
Runbooks, per client
Codify each client’s standard procedures once. Each step is either a
literal command or an instruction to the agent. Read-only steps run
unattended inside the same allowlist-and-parser boundary; a write
step never runs unattended, it executes only as an individually
approved command, same identity mapping, same audit entry.
Your playbook becomes an asset
The onboarding kit for client #12 is the refined context and
runbook set from clients #1–11, applied per deployment, owned per
client.
The evidence story
Who made that change? Now there’s an answer.
Every MSP has sat in the review meeting where the client asks “who made that change?” and the answer is a Slack scroll.
Each client’s deployment writes 1 permanent structured audit entry per approved execution: who approved what, on what evidence, and what ran. Scoped to that client by construction, it never contained anyone else’s operations. It lives in that client’s cluster, in the log storage run for them; the trail is browsable there with the tooling you already run. A packaged per-client extract tool is Roadmap , until it ships, your log tooling queries the trail like any other structured stream.
- The SLA review. Here is every operation this quarter, evidence attached, attach it to the report instead of writing one.
- The client’s insurance or audit questionnaire. Their “does any third party have controlled, logged privileged access?” answer is now yes-with-attachment, and you are the reason.
- The incident dispute. The timeline is not reconstructed from memory; it was written at execution time.
Your governance stops being a paragraph in your proposal and becomes an artifact in your delivery.
Economics
Transparent, scoped to your fleet.
For MSPs, scoped to your fleet
Scoped to your fleet
one-time pilot fee · fixed scope · deployed in each client’s cluster
- Deployment across up to 3 client clusters
- Per-client context and runbook setup
- The acceptance run: the 5 reproducible failure scenarios passing in a real client cluster
- A review of the first period’s audit entries with a client stakeholder
Licensing after the pilot: flat, annual, scoped to your infrastructure on the first call, locked for early adopters.
No per-seat pricing, an MSP’s whole bench can review and approve. No usage metering, an incident-heavy month costs the same as a quiet one. A cluster is not a unit of measure; the offer is tailored to the fleet you actually run.
Questions MSPs actually ask
Before you sign, ask us this.
Who clicks approve, our engineers or the client’s?
Your choice per client, in the approval mapping: your bench, the client’s own staff, or both, each mapped to their own execution identity in that client’s cluster. Whoever clicks, the audit entry carries their name.
What does onboarding a client take?
An afternoon: Helm install in their cluster, load their context documents, tune the alert rules. First root-cause report inside the hour, on the built-in failure simulator. Your #12 is faster than your #1, the onboarding kit is last client’s refined context and runbooks. The pilot, week by week →
A client demands nothing leaves their environment. Deal-breaker?
No, that is the default topology. Their data never leaves their cluster; serve the model in-cluster with vLLM and not even model traffic leaves. Show their CISO the security page. The security page →
What access does Infraware have to our clients’ clusters?
None. No control plane, no remote path, no telemetry to us. You are not introducing a fourth party into your client relationships.
Can we white-label it?
No. Reports and the console carry Infraware branding today, not yours. What you brand is the service around it, and the audit record you deliver is your artifact. If white-labeling is pivotal for you, say so in the pilot; it shapes the roadmap. Roadmap conversation, not a promise.
What happens when a client offboards?
Copy their audit trail and reports out of their cluster’s storage for the handover, then helm uninstall. Nothing is retained anywhere else, there is no anywhere else.
Do my engineers need new skills?
No new languages. Operations run through the web console; configuration is Helm values and JSON alert rules; runbooks are edited in the console. If your team runs Kubernetes for clients, they already have everything.
Who is liable when an approved fix goes wrong?
The execution ran under your engineer’s mapped identity with the client-scoped RBAC you configured, on evidence recorded in the report, so the dispute is over a documented decision, not a mystery. Your MSA governs liability as it does today; what changes is that you argue from the record. We are software, not your insurer, anyone who implies otherwise is selling something else.
Is this actually run-ready for us today?
It is pilot-stage and priced that way. The pilot exists to prove the loop in real client clusters with a small cohort. You would be early, on purpose, at early prices. How it is secured →
Direct proof
Bring one client cluster.
We’ll break it, investigate it, and put the audit entries on the table in the same hour.
Bring the client’s security lead to the demo. The page they’ll want to read first is the security page, send it ahead.