What can Bayqus do on a host besides monitor it?

With the RMM & Patch add-on, the same agent can perform a small set of curated actions on the host: apply security patches, restart an allowlisted service, install an allowlisted package, and update itself. These are named verbs against allowlists — not an open remote shell — so a dispatched job can only do one of the actions you've permitted.

Can Bayqus patch my whole fleet automatically?

Optionally, and off by default. An account owner can opt in to scheduled security-patch auto-apply that runs only inside a maintenance window you define — chosen days, a start and end time, in your own timezone. It rolls out to a limited number of hosts per run rather than the whole fleet at once, and any host that already has a recent patch job is skipped. Until you opt in, patching is fully manual.

How do I keep a patch from breaking a machine at the wrong time?

Auto-patching only fires inside the maintenance window you set, and the recommended path is a dry-run on a pilot host before any real apply. Long-running package operations get an extended timeout so a slow apt or dnf transaction is never killed halfway through, and every job is recorded for audit.

Who is allowed to run these actions?

Dispatching and approving actions is a dedicated capability, separate from ordinary access. Account owners always have it; a team member needs it granted explicitly. The maintenance-window auto-patch policy is owner-only. It comes with the Secure plan ($29/month, alongside the security sensor), or can be billed per endpoint at $3/endpoint per month at scale.

Patch management & RMM · Add-on

See a machine fall behind on patches — then fix it, from the same console.

Q: Is this a remote shell into my servers?

No. There is no arbitrary command execution. Each action is a specific verb — patch-apply, service-restart, pkg-install, agent-update — and services and packages are checked against allowlists on both the backend and the agent. Every dispatched command is HMAC-signed and replay-protected, so a host only ever runs an action that was authorised for it.

Monitoring finds the problem; usually someone still has to SSH in and fix it. Bayqus' RMM & Patch add-on closes that gap on the hosts you already run the agent on: apply a security patch, restart a service, install a curated package — as named, allowlisted actions, never an open remote shell. Every command is signed and recorded, and opt-in fleet auto-patching runs only inside a maintenance window you define. It comes with the Secure plan ($29/mo — everything in Pro plus this and the security sensor), with per-endpoint pricing ($3/endpoint) available at scale.

Curated verbs, not a shell HMAC-signed & replay-protected Auto-patch in your window

01 — Curated actions, not a back door

A short list of verbs — each one thing, against an allowlist.

The whole point of RMM here is that it can't do anything you didn't permit. There is no "run this command" box. The agent understands a fixed set of verbs, and the ones that touch services or packages are checked against allowlists held on both the backend and the agent. A dispatched job either matches an allowed action for that host, or it's rejected — so the blast radius of the feature is bounded by design, not by trust.

Action	Does	Guardrail
patch-apply	Apply available security patches	Runs the host package manager's security update; long transactions get an extended timeout so a slow apt/dnf is never killed mid-flight.
service-restart	Restart a service	Only services on the allowlist (e.g. nginx, postgresql, docker, sshd) can be targeted.
pkg-install	Install a package	Only packages on the curated allowlist can be installed — not arbitrary software.
agent-update	Update the Bayqus agent	Rolls the host agent to a target version through the same signed path.

Every dispatched command is HMAC-signed with a timestamp and a one-time nonce; the agent enforces a skew window and refuses replays, and the backend records the nonce on the job for audit correlation. Allowlists are configurable per deployment.

02 — Manual first, automatic when you're ready

Opt-in fleet auto-patching — inside a window you define, off by default.

Patching starts fully manual: someone dispatches a patch-apply and it runs. When you trust it, an account owner can opt the fleet into scheduled security-patch auto-apply. It only ever fires inside your maintenance window — the days, start and end time you pick, in your own timezone — and it rolls out to a limited number of hosts per run rather than the whole estate at once. Hosts that already have a recent patch job are skipped. Turn the policy off and everything is manual again.

STAGE 1

Manual apply

Dispatch a patch-apply to a host; the recommended first run is a dry-run on a pilot.

STAGE 2

Set a window

The owner picks days, a start/end time and a timezone under Settings → Patching.

STAGE 3

Opt in

Switch the fleet policy to security auto-apply. It stays off until you do.

STAGE 4

It runs in-window

Inside the window, a limited batch of eligible hosts is patched; the rest wait their turn.

03 — Who can act, and what's recorded

Signed, scoped and logged — every time.

Who can dispatch

Running and approving actions is a dedicated capability, separate from ordinary access. Account owners always have it; a team member must be granted it explicitly. The maintenance-window auto-patch policy is owner-only.

Signed & replay-safe

Each command is HMAC-signed with a timestamp and one-time nonce. The agent enforces a skew window and rejects anything it has already seen, so a captured command can't be replayed against a host.

Won't break a slow apply

Package operations get a longer, per-action timeout than quick verbs, so a real patch transaction on apt, dnf or dpkg finishes cleanly instead of being killed halfway and leaving the package database in a bad state.

Audit trail

Every job — who, what, which host, the signing nonce and the outcome — is recorded, and jobs that never land are reconciled rather than left hanging.

04 — Questions

The things people ask first.

Q. Is this a remote shell into my servers?

No. There's no arbitrary command box. The agent runs a fixed set of verbs — patch-apply, service-restart, pkg-install, agent-update — and the ones that touch services or packages are checked against allowlists on both the backend and the agent. A job can only ever do an action you've permitted.

Q. Can I patch the whole fleet automatically?

Optionally, and it's off by default. An owner opts the fleet into scheduled security-patch auto-apply, which runs only inside a maintenance window you define and rolls out to a limited batch of hosts per run. Until you opt in, every patch is a manual, dispatched action.

Q. How do I avoid patching at a bad time?

Auto-patching only fires inside your chosen window — days, start/end time, timezone — and the recommended first real apply is a dry-run on a pilot host. Long package operations get an extended timeout so they aren't killed mid-transaction, and every job is logged.

Q. How is a command kept from being forged or replayed?

Every dispatched command is HMAC-signed with a timestamp and a one-time nonce. The agent enforces a time-skew window and refuses any nonce it has already seen, and the backend stores the nonce on the job for audit. A captured command can't be reused.

Q. How is it priced?

The simplest way to get it is the Secure plan — $29/month for everything in Pro plus RMM/Patch and the security sensor across your fleet. At larger scale it can be billed per endpoint ($3/endpoint per month). Your base Pro plan (a flat monitoring price for up to 100 devices) is unchanged.

More on how it fits together

Endpoint securityThreat detection on the hosts you monitor

All monitoring capabilitiesUptime, device health, SNMP, clusters

Security & trustEncryption, signing and access model

Get startedInstall the agent in a minute

Stop context-switching to a terminal to fix what you just monitored.

Add RMM & Patch to the hosts you already run the agent on — signed, allowlisted, and automatable on your schedule.

Start free Talk to us

Verified against the RMM engine (backend/src/rmm-core.js · routes/rmm.js · agent/command.go) — 2026-08-01