Under the hood
For the engineer who has to approve it
Everything in the platform, and what is in scope at launch
Watching, raising the event and running the fix are one service here, on the host where it happened. Your engineer names the commands, AI writes when they run and in what order, and your team approves it before it can ever run. No observability stack to assemble, no automation platform to own, and a conversation instead of a console.
What it does
For whoever picks the tools
What's in the platform.
Execution, no automation platform
The agent runs the fix on the host itself — cloud VM or on-prem. Other tools that reach a host get there through automation you already wrote and maintain, a script registered ahead of time, or one cloud provider's control plane. Here the agent runs what your engineer named and your team signed, so there is no automation platform to stand up first.
ActionBooks
Your engineer names the commands that fix it. AI writes when they run and in what order. Your team reads it back and signs it, and it has to pass the real parser and be registered before it can ever run. It holds the whole pass — validate, investigate, act, confirm — not just the fix. Nothing is invented mid-incident, and it can only call Builtin Functions from its registered catalog.
Not every event needs a person
Most close at the first check, as noise. Plenty more are real but have no approved action, so your team gets the facts in the morning and makes the call. When something needs a second look, it reaches you as one tap — never a login.
Conversation, not a console
Configure, investigate and tune by saying what you want — over MCP from your own AI client, or in Virca. The screen shows state and history, not a wall of charts.
Audit log
Every action on the record — trigger, decision, outcome, and who or what triggered it.
Any connected environment
Anywhere you can install the Agent — cloud VMs, bare metal, on-prem, hybrid. It behaves the same everywhere because the Agent is the whole footprint. The next section says exactly what is covered at launch.
What it watches
For whoever owns the on-call rotation
Infrastructure and hosts at launch.
Virca brings its own data. The automation does not rent what it acts on, which is why there is nothing to assemble before an action can run — and no reason to remove the stack you already have. Metrics, dashboards and alerts are native, and the Agent collects exactly what its actions need. Nothing to wire up, nothing to maintain. Launch scope is infrastructure and hosts: cloud VMs and bare metal, plus the checks around them — URL, Port and Process. Kubernetes is on the roadmap, not in launch scope. Ask where a specific one stands →
A single Agent, any environment
For whoever has to approve it
A Single Agent per host. Low resource load.
One service per host, one connection out. That is the whole architecture. The signal leaves on a connection the Agent opens itself, the approved action set comes back down the same connection, and the fix runs inside your own boundary. Nothing listens for inbound traffic, and no cloud provider API sits on the path.
Your environment
Any host — cloud VM · bare metal · on-prem
Virca Agent
collects — and executes
the fix runs right here
not in a console, not through a cloud API
1the signal, going out
2the approved action set
one outbound TCP connection, opened by the Agent
Virca · US region
Event rules
ActionBooks
built from Builtin Functions — one can chain to the next
Ledger
every run, on the record
reported to team chat, written to the Ledger
Agent
On each host, the Agent collects data and runs approved commands over one connection it opens itself. Credentials stay on the Agent side, never on the SaaS server.
One outbound connection
The Agent opens a single outbound TCP connection to Virca. No inbound ports, no VPN tunnel — cloud or on-prem, it is one outbound rule.
ActionBooks
Your engineer names the commands, AI writes the order, your team approves it, and the real parser checks it at registration. A rule binds the book it runs, and whatever runs was registered and parser-checked first. Today nothing is composed at the moment of the incident.
Audit Log
Every execution records its trigger, decision, action and outcome.
Integrations are the easy part, and we are not going to dress them up. They change how much Virca can see. They do not change the boundary around what it may run — the part worth reading twice.