All docs

The agent

Remote actions (opt-in)

Remote actions let the dashboard run a command on a server: restart a service, free a disk, approve an AI fix, open a terminal. They are off on every server until you switch them on, and every command is signed, recorded and shown with its output. This page explains how to enable them and what the guardrails are.

Off by default

A freshly installed agent is read-only. It reports facts and never runs anything. Remote actions are switched on per server, in the dashboard, by a person. An agent update cannot switch them on, and the fleet-wide switch takes effect on a server only once its agent supports actions.

Remote actions need the Growth plan or higher. On the Free plan the switch is refused with an upgrade prompt. See Plans and billing.

Enabling remote actions on a server

  1. 1.Open the server, then the Automation tab. The Remote actions row shows *disabled*.
  2. 2.Click Enable on this server. A dialog explains that the server will be able to run any command dispatched from the dashboard, as the agent’s user, and that every command is recorded. Confirm.
  3. 3.You may be asked to verify your identity first (the workspace’s step-up policy). The toggle is audited as actions_enabled with your user and IP.

You can also flip the switch in the Remote actions column of the fleet table, or choose Enable on all servers to enable every server at once. The terminal dock shows an Enable remote actions button when you open a tab on a server that is still off. Disable in the same places puts the server back to read-only; a command already running finishes, nothing new is accepted.

A local kill-switch

If a server must never accept commands no matter what the dashboard says, add this to /etc/infrapilot/config and restart the agent. The agent then stops polling for commands entirely, and the dashboard shows it as not supporting actions.

OPSERVO_ENABLE_ACTIONS=false

How a command reaches the server

  • •The agent pulls. Every 5 seconds it asks the API for pending commands over the same outbound HTTPS connection it uses for heartbeats, signed with its secret key. Nothing connects in; there is no inbound port. While you have a terminal open the API asks the agent to poll once a second so results feel immediate.
  • •The API returns nothing for a server whose remote actions are off, even to an authenticated agent.
  • •Each command is Ed25519-signed by the API at dispatch. The agent verifies the signature before running it and reports an error instead of running a command that does not verify. A command not picked up within 10 minutes expires.
  • •The command runs through sh -c as the user the agent runs as (root on a standard install), in its own process group. The default timeout is 60 seconds and the maximum is 600; on timeout the whole process group is killed. Output is capped at 64 KB each for stdout and stderr.

Who can run what

  • •Quick actions (Restart, Logs, Status next to a service, Reboot, Update agent, the fixes on the Security tab) are open to every role in the workspace.
  • •Free-text commands (the command box on the Automation tab, the terminal) are limited to owners and admins, and are subject to the workspace step-up policy. Other roles get a clear refusal and are pointed to a quick action instead.
  • •The command box is hidden behind *Custom commands are for command-line users* until you click *I know Linux — show the command box*. Everything the quick actions and AI can do works without it.

Each dispatch is recorded in the audit log and in the server’s command history under the Automation tab: the command text, who ran it, when, exit code, stdout and stderr. History is kept, so you can scroll back months.

sudo and the scoped sudoers grant

Commands run non-interactively, so a server whose sudo asks for a password cannot run privileged fixes. When Opservo hits that wall it stops and tells you exactly what to add, once, replacing <user> with the OS user the agent runs as and the command with the one it needs:

echo '<user> ALL=(root) NOPASSWD: /usr/bin/systemctl restart nginx' | sudo tee /etc/sudoers.d/opservo-actions && sudo chmod 440 /etc/sudoers.d/opservo-actions && sudo visudo -c

The grant names one command, in a file called /etc/sudoers.d/opservo-actions. The security scanner knows this file and does not count a scoped line in it as a finding. A blanket NOPASSWD: ALL — in that file or anywhere else — is still flagged and still costs security score, because it turns any compromise of the command channel into unrestricted root.

What remote actions unlock

With the switch on, the same server page gains: browsing, editing and uploading files; deploys and rollbacks; service restarts and process kills; firewall and port changes; reboot; Resolve-with-AI fixes that run real commands; autonomous fix policies such as auto-restart and disk cleanup; and the tabbed terminal. AI chat can run commands in act mode, and fleet runs can target the server.

Last updated 2026-10-01. Found a mistake? Email hello@getopservo.com.