FAQ
Teams ask these before they say yes.
How Virca works, what your team controls, what Virca runs on and the tools you keep.
How it works
How a fix gets written and run.
What Virca is, what an ActionBook holds and where your team fits.
What is Virca?
Virca runs the fixes your team already knows, on your servers. Your team approves each fix once, for every server. The Virca Worker is a process on your server. It watches the server and runs the fixes you approve. When no approved fix fits, Virca stops and tells your team. Virca is AgenticOps for IT infrastructure.
So Virca acts on every alert?
No. Virca acts on an alert only when your team linked it to an approved fix. Your team can also start a fix itself. Noise closes with what was checked. A real event with no approved action goes to your team with the facts gathered.
What exactly is an ActionBook?
The steps your team runs by hand, written down: check that the alert is real, gather context, act, then re‑check. Your engineer sets the scope, AI works within it, and your team approves the ActionBook.
An ActionBook can only call the functions already on the Worker, so that list is everything the ActionBook can touch.
What if the process using the most CPU is our main app?
Then link that alert to a restart of your app’s service. That fix checks the service, restarts it and runs a health check.
The fix that stops a runaway process leaves init, systemd and sshd alone. It also skips any process your engineer lists as off-limits.
Is an ActionBook a runbook?
Not quite. A runbook is written for a person to follow at 2:30 AM. The Worker runs an ActionBook, and only after your team approves it. An ActionBook can only call the functions already on the Worker.
Will Virca replace our SREs?
No. Virca runs the fixes your team has typed before. Your engineers’ hours can go to the alerts that need a person.
Control and safety
Your team approves what runs, and where.
Approval comes first, and anything outside the approved set stops.
What can it run on my servers, and who decides?
A fix can only call functions already on the Worker. It runs only on the servers you assigned. An alert can’t start a fix until your team turns the fix on for that alert.
Today someone on your team with approval rights approves a request in Virca. The record shows who gave each approval.
What can change review read?
Is Virca autonomous?
In one sense: an approved fix runs with no one at a terminal. With approval mode on, every run an alert starts waits for approval in Virca. A log cleanup with no alert linked runs only when your team starts it. Your team approves in advance, in daylight, which fixes may run and on which servers. Anything outside that set still stops at runtime.
Does this turn into its own approval bureaucracy?
No new team and no queue to staff: your team approves a fix once, when it is written. After that, no one types it. With approval mode on, every run an alert starts waits for approval in Virca. No approval in 10 minutes, no run.
What happens when no approved fix fits the situation?
Virca stops and tells your team, with the server and the facts already gathered.
With approval mode on, a fix an alert starts ends differently. An approval request shows in Virca, evidence attached.
What if the action doesn’t fix it?
The action re‑checks its own target. If a step fails, the reverse steps its author wrote run in reverse order. If there are none, recovery is manual, and the record says so.
The limit, plainly: Virca runs the check the action’s author wrote. Virca does not measure the outcome.
Does Virca learn from what worked?
No. Virca keeps no measured history of whether a fix worked, and does not tune itself. What the Worker did stays on the record: trigger, decision, commands and outcome.
What stops it from touching the wrong server?
Actions run only on the servers your team assigns. The record shows who gave each approval.
Library actions also ship off. Your team approves each one deliberately.
What can you put in front of a security reviewer?
The architecture: one outbound connection, credentials stored only on your servers, an approval boundary agreed before anything runs, and a record of each run.
Virca sends data to a model only when your team uses an AI feature, such as drafting a fix or a rule that asks for analysis.
Two limits to know: the Worker runs as root by default, and some functions need root even if you choose another user. And one approval is enough: today someone on your team with approval rights approves a request in Virca.
On a team of one, who approves the fix?
You do, when the fix is written. You approve it once, for every server you assign. Then you turn it on for its alert. When that alert fires, Virca runs the fix with no one at a terminal. With approval mode on, every run an alert starts waits for approval in Virca.
Setup and scope
Your team installs one service on each server.
One service per server, one outbound connection, and a first pass with your engineer.
What gets installed, and does it need inbound ports?
The Worker runs on each server as one system service that collects and acts. On Linux, it is installed with sudo and runs as root by default or as another user you choose. Some functions may need root. On Windows, it is installed from PowerShell as Administrator. It opens one outbound connection to Virca; nothing listens for inbound traffic, and no VPN is needed. Credentials stay on your servers.
Where did your AI learn my environment?
Virca reads the live state of your servers at setup. Your engineer supplies what AI cannot see, such as a process never to touch. This setup happens once, in daylight. Your team already knows the fix; Virca gives the fix a way to run.
How much work is the setup, honestly?
General patterns, such as a filling disk or a stopped service, need very little input. Patterns specific to your stack need an engineer for a first pass. The work happens once per pattern, not once per incident.
What does day one look like?
Start on one non‑critical app server. Install the Worker there and connect email or Slack. Let Virca look into the alerts on that server. Those checks are read-only. Read the runs. Then your team approves one fix and turns it on for its alert. After that, the alert can start the fix. Later, your team assigns the fix to the rest of your servers.
Can we try it before we install it on a server?
What does it cover at launch?
Virca fits web and app services on Linux or Windows servers your team runs itself, with a URL or health endpoint to check. Not a fit today: PaaS or serverless-only.
Linux and Windows servers on cloud VMs and bare metal, plus URL, Port and Process checks around them. Kubernetes is outside launch scope.
Who is using it today?
No customer is public yet. Virca is new, and your team can create an account and install the Worker today.
Start on one non‑critical app server. Questions first? ask@virca.ai. Tell us which fix your team keeps typing.
What does Virca cost?
$20 per server per month. A server is any machine you install the Worker on.
Tools you already use
Your team keeps the tools already in use.
Virca runs alongside what you already have — and doesn't depend on it.
Do I have to replace my monitoring stack?
No. Keep your monitoring, retention and alerting. Virca brings the data its own actions need, so nothing migrates.
Which alerts you still need stays your call.
One known gap: a server that goes silent returns no data, so detecting silence still belongs to your monitoring today.
Does my phone still ring when an alert fires?
Yes. Your current alerts still reach the same people as today. When an alert fires, your monitoring may see it too. The record shows whether the fix already ran.
We already have systemd Restart=always and cron. Why add Virca?
Keep them. Virca asks you to retire nothing. Restart= on its own brings back a process that exits. It doesn’t check that the service answers or tell your team. A cron cleanup runs on a schedule. The disk can fill between runs. A playbook run from a laptop needs a person at that laptop.
An ActionBook checks that the alert is real, acts, re-checks its target and reports each step. It runs only after your team approves it, and one approval covers every server your team assigns.
We already have configuration management and playbooks. Why add Virca?
Keep them. Configuration management sets up your servers. When the alert fires, Virca runs the checks your team approved. If they match, it runs the fix and re-checks the target. It runs only on the servers your team assigned. Every run goes on the record.
Can Virca reach my cloud provider’s control plane?
Today, Virca acts on the server itself: services, processes, files, mounts, packages and the server’s firewall rules.
Autoscaling groups, load balancers and cross‑region traffic are outside launch scope. An approved action can still steady the server while your team handles the rest.
Can I work with Virca from my own AI tools?
Yes. Through MCP, your team can work with servers, alert history, event rules and ActionBooks from the AI client your team already uses.
Requests from that client run through the same Worker, which can only call the functions already on it. The record shows that the request came through MCP.
Why not my AI agent?
Keep it. With Virca, your team approves the fix once, before the alert. Then it runs on the servers you assigned, at any hour. With approval mode on, every run an alert starts waits for approval in Virca. Every run is on the record. If no approved fix fits, Virca stops and tells your team.
