AI agent for infrastructure operations
The AI agent that runs your infrastructure. With the whole harness around it.
From code to GPU in one conversation.
Tell it what you need, in plain language: it deploys, scales, repairs and bills, on your GPUs, your clusters, your VMs and your clouds. It never holds your keys, it asks before it acts, and it proves what it did. One layer above your toolchain, not another tool in it.
Don't kill anything that's running.
- Target
- gpu-07 · 2 training jobs · 1 Ray worker
- Policy
- Drain = risky → preview and approval required
- Approved
- Platform lead · 21:04
- 1Cordon gpu-07✓ 21:04
- 2Wait for both training jobs to finish✓ 21:43
- 3Move Ray worker to gpu-03✓ 21:44
- 4Drain node. Nothing deleted.✓ 21:45
sha256 · 9f3c…a41e
The problem
Capacity scales. Operations don't. And the obvious fix can't be trusted, until now.
You can buy GPUs in an afternoon. Running them takes a team: each vendor, site and tenant adds a toolchain, a runbook, an on-call rotation, and a line in a spreadsheet after the invoice. Work waits on the two people who know the cluster, while the hardware sits idle.
An AI agent is the obvious answer, and the obvious risk. A generic agent holds your keys, acts on its own say-so and reports success it never checked. Nobody hands production to that.
VibOps is the agent you can hand it to.
Why you can let it act
Three guarantees, built into the platform.
An agent that can touch production has to earn it. These are not settings you turn on. They are how VibOps is built.
Your credentials stay on site.
A small gateway lives on your site and only calls out: no inbound port, no VPN. It holds the credentials. The model, whichever one you choose, never sees a secret.
Anything that can break something waits for your approval.
Before a risky action it shows you exactly what it is about to do, and stops. Your admins decide what needs an approval, and from whom.
Done means read back, never assumed.
After every action it checks the real state and reports whether it is actually done. Everything lands in an audit trail that cannot be quietly edited, and your compliance reports are built from it.
How it works
You ask. It checks. You approve. It acts, and proves it.
You ask
In the console, in plain language. Or from a schedule, a pipeline, an alert, or your editor over the MCP server.
It checks
Your rules, your roles, your tenants. Anything risky comes back as a preview, not an action.
You approve
Or someone else does. The agent cannot approve on your behalf, even if the model tries.
It acts and proves it
The action runs on your site, the state is read back, the result is recorded and billed to the right team.
Product demo
Watch it work.
The real console, on real infrastructure. No mockup.
Capabilities
One console for GPUs, VMs and the agents that use them.
GPU operations
Inventory, health, saturation, anomaly detection and failure prediction across NVIDIA, AMD and Intel, with no per-machine agent.
VM operations
Proxmox, vSphere, Vates XCP-ng, Nutanix, HPE VME. Lifecycle, GPU passthrough, backup compliance, SLA tracking.
FinOps
One cost model for GPU and VM alike. Per-tenant chargeback, configurable margin, budgets that block before the invoice does.
Agent FinOps
An inference proxy: cost per agent, per model and per organisation, with ceilings that actually stop the spend.
Governance
Deny by default on any unknown action, mandatory preview before destruction, hash-chained and anchored audit trail.
Sovereignty
On-prem, air-gap compatible, tenant isolation enforced by the database rather than by code discipline.
Integrations
It works with what you already run.
VibOps does not ask you to give up kubectl, vCenter or sbatch. It sits one layer above them: the same request, the same policy, the same audit record, whatever is underneath — a managed EKS, AKS or GKE cluster included.
Accelerators
Platforms and hypervisors
Managed Kubernetes and clouds
Models
| Vendor | Device | Resource |
|---|---|---|
| NVIDIA | H200 · 141 GB | nvidia.com/gpu |
| AMD | MI300X · 192 GB | amd.com/gpu |
| Intel | Gaudi 3 · 96 GB | gaudi.intel.com/accelerator |
| Groq | LPU inference endpoints | api.groq.com |
Who it's for
Teams that own infrastructure, and those who serve it to others.
GPU operators
Turn raw compute into a managed platform. White-label console, per-tenant chargeback with configurable margin, enforceable budgets, multi-accelerator. Your customers deploy self-service and billing follows.
Integrators and MSPs
Operate your customers' VMs (Proxmox, vSphere, XCP-ng) and their GPU clusters from a single console, under each customer's rules. One operator covers ten sites instead of three.
Enterprises and platform teams
Your ML teams are waiting on the two people who know the cluster. VibOps is the operator those two would hire, if it could be trusted. That is the point.
Model choice
Change the model. Nothing changes about what it can touch.
Run VibOps on Claude, GPT or Mistral, or on a model served from your own GPUs that never leaves your network. The agent holds no credential: it emits an intent that VibOps authenticates and policy-checks. The guardrails belong to the platform, not to the model.
Getting started
Three steps. No agent on the compute machines.
VibOps sits beside your infrastructure, not in front of it.
Deploy the control plane
A self-hosted stack, on your own ground.
Connect your sites
One lightweight gateway per site. It discovers the clusters, the GPUs and the hypervisors on its own, and changes nothing you have not confirmed.
Operate
From the console, or from your editor over the MCP server. The MCP server and the Python SDK are public and MIT-licensed.
Access
You operate GPUs. Let's talk.
We open access in waves, so that every install gets attention. Tell us what you run.