Skip to content

Control

Your team approves what runs, and where.

Your team settles what runs, and where, before an alert fires. After each run, you can read what ran, where, and who or what started it.

Illustration: your team approves fixes, and Virca runs them on the servers your team assigned.

At a glance

Before anything runs, change review can read the approved set.

Your team approves the fixes and the servers each one runs on. After each run, your team or whoever reviews changes can read the record in Virca.

Illustration: your team sets the line, and every run on the server reports the result.
  • Off until approved.Library actions wait for your team's approval.
  • Only functions already on the Worker.Unknown functions are rejected.
  • Who approves.Today someone on your team with approval rights approves a request in Virca.
  • No inbound ports.Virca needs no inbound port.
  • A record for every run.Each step, the result, and who or what started it.
  • US region.Virca is served from a US region.

Your team's line

Is it safe to let AI run commands on production servers?

A fix can only call functions already on the Worker. It runs only on the servers you assigned.

Your engineer sets the scope. AI works within it. Your team approves it. When nothing approved fits, Virca stops and tells your team.

Illustration: AI drafts an ActionBook, and the ActionBook waits for your team. This ActionBook runs only after your team approves it.

Alerts and their fixes

  • Disk almost full Off Clear logs older than 7 days
  • nginx stopped On Restart nginx
Not linked to the alert: Virca checks and tells your team

Only functions already on the Worker

What can Virca run?

Each function was declared with its own limits and grade.

An ActionBook that calls an unknown function is rejected before the run starts. There is no shell escape.

Illustration: ActionBooks that call only functions already on the Worker pass through to the server. An ActionBook that calls an unknown function is stopped before it starts.

Before an ActionBook starts

  • Functions already on the Worker Can run
  • An unknown function Rejected
  • A raw shell command No shell escape

Grades

The grade decides what your AI client can run.

Every function carries a grade. When your AI client or another fix starts a step, a routine step runs, a second look waits for approval, and high risk is refused. When an alert starts a fix, approval mode decides.

Approval mode is a setting in Virca. With it off, a linked fix runs as soon as its alert fires, at any grade.

Illustration: your AI client starts a step that needs a second look. It waits for approval in Virca, then the Worker runs it on the server.

Three grades

How it works: When your AI client or another fix starts a step:

  • Routine Runs
  • Needs a second look Waits for approval
  • High risk Refused

Grades

With approval mode on, every run an alert starts waits for approval in Virca.

No approval in 10 minutes, no run. Today someone on your team with approval rights approves a request in Virca.

Illustration: with approval mode on, every run an alert starts waits for approval in Virca before the Worker runs it.

Record

What does each run report?

Each run reports its steps and its result.

Who or what started it, what was checked and run, the server, the result, and who approved the fix.

Illustration: an alert, the server it points to, and the record every run leaves.

Record

What Virca holds back

When does Virca hold back?

Library actions check before acting, and a failed fix goes on the record.

Illustration: a fix checks the alert first, and the run stops there if the alert is not real. When a step fails, the reverse steps run in reverse order.
  • Fixes check the alert first.If the alert is not real, the fix stops there.
  • No restart for a service that's back.A recovered service skips the restart.
  • SIGTERM only.Library actions leave init, systemd and sshd alone. SIGKILL stays with your team.
  • A failed fix is recorded.The reverse steps its author wrote run in reverse order. If there are none, recovery is manual, and the record says so.

On your servers

What gets installed on my servers?

The Virca Worker is a process on your server. It watches the server and runs the fixes your team approves.

Installed with sudo. Runs as root by default, or as another user you choose. Some functions may need root.

A fix can only call functions already on the Worker.

  • One TLS connection to Virca. No inbound port, no VPN.
  • Credentials stay on your server.
  • Virca reaches only the servers with a Worker installed.
Illustration: Cancel stops fixes that have not started yet. A fix already running on the server runs to completion.

Stopping a run

Can we stop a run?

Cancel stops what has not started yet. A fix already running on a server runs to completion, bounded by its timeout.

  • Not started yet Cancelled
  • Already running Runs to completion
  • Worker can’t reach Virca No new fix starts
Illustration: the run records and charts are stored with Virca, in the US region.

Data location

Where is our data stored?

Your data is stored in the US. Virca is served from a US region. AI requests may be processed outside the US. Our affiliate in Korea may access data to develop and support Virca. Details are on the Subprocessors page.

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.

US region

Security review

Reviewing Virca for your company?

Start on one non‑critical app server. Email your questions to ask@virca.ai with the subject “Security review.”

Illustration: an email marked Security review, and the checklist it covers.