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
Offboarding: copy the record out, uninstall. Nothing retained anywhere else.
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.
One deployment per client. The same single-team deployment our security page describes: one client, one deployment, one record.
Night alerts
Read-only overnight. Signed by name in the morning.
Incident report
Alert CompletedPaymentsGateway5xx, payments namespace · fired 14:08:11 · run a41c
- Root cause
- Rollout to revision 47 at 14:02 wedged the gateway’s workers: readiness stayed green while every request thread blocked on the old connection pool. Traffic kept routing; 5xx began six minutes later.
- Evidence
-
- rollout historyrevision 47 applied 14:02:34; previous revision ran clean for 9 days
- pod status0 restarts, readiness green throughout: not a crash, a wedge
- gateway logsworker pool saturated from 14:06:58; every thread waiting on pool acquire
- Proposed
kubectl rollout restart deployment/payments-gateway -n paymentsproposed, not executed. Mutative actions require your approval.
Ask Virgil about this Open full report
Night is where an MSP carries the most risk: an alert at 02:40 in one client’s cluster, and whoever is on call deciding alone.
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; each execution runs under that client’s scoped write principal and leaves an audit entry with the engineer’s name.
0 writes in any client’s cluster while nobody is awake. One bench engineer reviews across every client in the morning, and every change that follows carries that engineer’s name.
Investigations run under a read-only principal against a read-only allowlist; proposed fixes are stored, never executed.
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 scoped write principal, 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. 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
Scoped to your fleet, fixed before you start.
For MSPs, scoped to your fleet
Scoped to your fleet
one-time pilot fee · fixed scope · deployed in each client’s cluster
- Deployment in the client clusters agreed on the first call
- Per-client context and runbook setup
- The acceptance run: three scenarios agreed on the first call, run end to end in one 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: your bench, the client’s own staff, or both. Whoever clicks, the audit entry carries their name, and the change runs under the write principal scoped to that client’s cluster.
What does onboarding a client take?
A Helm install in their cluster, their context documents loaded, their alert rules tuned. The first root-cause report comes from the built-in failure simulator, so the client sees the whole loop before a real alert. Every client after the first starts from the last one’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 stays in their cluster, apart from what each call sends to the model endpoint you configure, and that endpoint can be a model served inside their own boundary with vLLM or llama.cpp. 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.
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?
Your named engineer approved it, it ran under the client-scoped write principal and 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.
How to start