Why it matters
For whoever picks the tools
Reaching your hosts stopped being rare. Three things still separate Virca.
Plenty of tools can touch a host now. What they cannot do is compose the action, own the data it runs on, and account for it afterward. Those three are the argument.
Why teams choose Virca
For whoever picks the tools
Compose the action, own the data it runs on, account for it afterward.
Authorship — your engineer names it, your team signs it
Your engineer names the commands that fix it. AI writes when they run and in what order, against the incident in front of it. Your team reads it back and approves it. Nothing has to exist as automation first.
How everyone else gets there
The tools that reach a host get there one of three ways: they launch automation you already wrote, run a script an admin registered ahead of time, or go through one cloud provider's own control plane. Some of them do compose the command themselves.
None of them composes the action from commands your engineer named and hands it back to be read and signed before it can run. So either something had to exist already, or nobody reviewed what got composed. The first path also assumes your team already runs an automation platform.
Foundation — the automation doesn't rent its data
The agent that collects is the agent that executes, so the data the fix runs on is Virca's own, not borrowed from your stack. Everyone else: almost nothing in this category brings its own monitoring — the few that do are Kubernetes-only — so the rest inherit whatever stack you run, blind spots included.
Accountability — nothing runs off the record
Trigger, decision, action, outcome — every run is logged. Outside the approved set, the agent stops and comes to your team as one tap in team chat. The approval button itself is no longer rare — what separates us is what runs and who wrote it, not the tap.
Configuration management builds the car.
Virca is cruise control — you set the direction, it holds the line.
What it takes to run one fix
For the engineer who has to approve it
Six things to set up, not twenty-five.
Take one ordinary requirement — when p95 latency crosses the line, restart the service, check it recovered, roll back if it didn’t — and count what your team has to create, wire together and keep current before it runs once. Not the vendor’s engine; the parts that land on your team.
The usual shape
An alert raised elsewhere crosses a tier of four components before a change reaches the service on your host: a workflow engine, a connection and runner, an inventory of targets, and a credential store. Each one is configured, and each one has to keep matching reality.
Here
That separate platform and that whole tier are never built — the agent that noticed the event is the one that acts, on the same machine as the service. Nothing has to carry intent across, because nothing sits in between.
1The usual shape
the alert
raised elsewhere
the tier between them
workflow engine
connection + runner
inventory of targets
credential store
the service
on your host
each one configured, and kept matching reality
2Here
never built
no platform noticing elsewhere, no tier carrying its intent across
the agent that noticed
is the one that acts — on your host, the same machine as the service
One service observes and acts.
That is why the tier above it is missing.
Counts are for a single host-level fix on a non-Kubernetes fleet, taken from published vendor documentation. The ratio is the point, not the digits — your own number moves with your environment.
See exactly what's being counted
The usual shape: a workflow graph, a connection, a runner on every target host — or a job template in an automation platform you already run — plus its inventory, its credentials, an allowlist, a sudoers entry, an approval step, and the script itself, which lives somewhere the platform can't read.
Virca: the action bound to an event, the action script, the Builtin Functions it calls, a host group, an approval policy — and the agent that was already installed. No runner tier, no inventory, no second set of credentials.