More servers mean more configurations and updates to coordinate.
Working on each machine individually takes time; updating everything together increases operational risk.
A fleet of servers, one console and safe updates.
Manage dozens of agents from a single point: each server runs a lightweight agent in Go, connected to the central server via gRPC mTLS. Updates start on a canary subset and continue on the rest of the fleet only if the canary remains healthy → so a faulty update doesn't bring all your servers down.
Anti-brick CanarymTLS end-to-endWatchdog
Bring status and updates to a single console.
Each agent communicates in an authenticated way and new versions are deployed first on a canary group.
Easier management, low-impact rollouts.
If the canary does not return healthy, the distribution stops before reaching the rest of the fleet.
Guided onboarding
From the new server to the first heartbeat, without rebuilding the procedure.
From the panel create the server, assign a recognisable name and get the agent's credential. The installation tab prepares the command to be copied and keeps the operating instructions in the same place.
- Agent credentials visible only to authorised roles.
- Installation command ready and guide for service, log, firewall and configuration.
- Status of registration and last contact immediately visible in the console.
One console
The whole fleet, in one view.
Each protected server runs a lightweight agent in Go connecting to the central server via gRPC mTLS and sends a heartbeat every 30 seconds. The dashboard collects everything at a glance: hostname, agent version, connection status and update status.
- Server Status: active, offline or pending, in real time.
- Version and update_state of each agent: idle, updating, updated or failed.
- CPU, RAM, disk and uptime of the system and the agent in the server card.
- No invisible agents: Any agent that stops sending heartbeats is immediately visible.
Linux and Windows
A single console, with capabilities adapted to the system.
Linux is the complete platform for reverse-proxy WAF, web watchers, antivirus and FIM. The Windows agent covers inventory, heartbeat, authentication events and blocking through Windows Firewall.
Linux · Full protection
WAF, rate-limit, geo and reputation, SSH, Nginx/Apache, custom watchers, file scans, FIM and firewall iptables/ipset.
Windows · host monitoring
Event Log security, logon attempts, inbound/outbound blocks with Windows Firewall, status and connection to the central server.
Same control plan
The identity of the agent, heartbeat, events and central management remain consistent; the availability of individual modules depends on the operating system.
Anti-brick canary updates
First a canary group, then the fleet—or stop.
When you publish a new version, Sentinel does not update everything at once. It selects candidate online agents that are connected and not yet on the target version, then divides them: a canary equal to ceil(canaryPercent%) (default 20%, minimum 1). The rest of the fleet is promoted only if all the canaries reach the target version and re-register with the new version. Otherwise the rollout is aborted and the rest is not touched.
- Deterministic split: default 20%, always at least one canary.
- Explicit timeouts: 15 minutes for the canary, 30 minutes for the rest.
- Anti-brick: If the canary fails, the rest of the fleet remains on the previous version.
How Canary Works
Four steps, one goal: avoid disruption.
The rollout always follows the same deterministic sequence, wave after wave.
01
Split
Sentinel selects online, connected candidates that are not yet on the target version, then creates the canary group: ceil(canaryPercent%), default 20%, minimum one agent.
02
Canary
The canary receives the update first. Each agent downloads, checks and installs locally, then re-registers with the central server with the new version.
03
Health check
Sentinel waits for all canaries to reach the target version within the 15 minute timeout. If even one fails, the rollout is aborted.
04
Promotion or stop
Healthy canary: the rest of the fleet is updated (timeout 30 minutes). Canary failed: the rollout stops, and the rest remains on the previous version.
Watchdog & auto-recovery
A watchdog that restores the agent.
Each update passes mandatory checks while a watchdog monitors the agent. A SHA-256 checksum and Ed25519 signature are required; unsigned manifests are rejected. Downloads use HTTPS with a 200 MiB limit. The agent performs an atomic backup and replacement and automatically rolls back if the new release does not start within 60 seconds.
- Mandatory verification: SHA256 + Ed25519, otherwise the update does not start.
- Watchdog every 30s: After three failures, it restarts the component and marks it "recovered."
- Local rollback: protection is restored automatically if an update fails.
mTLS communication
Every agent is authenticated in both directions.
The channel between each agent and the central server uses mutual TLS authentication: the server checks the certificate of each agent (RequireAndVerifyClientCert) and the agent verifies the server. No anonymous clients, no commands from a server that is not yours.
mTLS bidirectional
The server accepts connections only from agents with a valid certificate; the agent only talks with the central server it recognises. Authentication is reciprocal, not one-way.
TLS 1.2 minimum
The gRPC channel imposes TLS 1.2 as a minimum version: no downgrades to obsolete protocols between agent and central server.
Reconnecting with backoff
If the connection drops, the agent tries with progressive backoff, without hammering the server and without being orphaned by the console.
Failover HA
With multiple configured endpoints, the agent fails over for high availability: if a central server doesn't respond, it switches to the next one.
How to scale
From a server to a fleet, without changing method.
The model is the same for 3 or 30 agents: one rollout at a time, shared protection and redundancy on the central server. Some limits are stated openly. The rollout status is in-memory, so a central-server restart loses the in-memory monitor: after restart, reconciliation marks stalled agents as "failed" and the rollout must be restarted. And no rollback at fleet level: the rollback is local to the agent.
One rollout at a timeCollective defenceFailover HA
Frequently asked questions
What they usually ask about the fleet.
Can an update disrupt my servers?
This is exactly what the canary avoids. The update starts on a subset (default 20%, minimum 1 agent) and continues on the rest of the fleet only if all the canaries reach the target version within 15 minutes. If the canary fails, the rollout is aborted and the rest of the servers are not touched.
How are canaries chosen?
The candidates are the online agents, connected and with a version other than the target. From there, Sentinel selects the canary group with ceil(canaryPercent%), default 20% and at least one. The others remain in the queue until the canary is checked healthy.
Is there a fleet rollback?
No, and let's say it clearly: the rollback is local to the agent if a new release does not start within 60 seconds, that single agent restores the previous version automatically. At fleet level there is no centralised rollback: the protection is to avoid promotion, not to undo it later.
What happens if I restart the central server during a rollout?
The state of the rollout is in-memory, so the monitor is lost. After restart, reconciliation marks stalled agents as "failed" and the rollout should simply be re-launched. No agent is silently left in a partial state.
How can I trust the update being delivered?
Each update has a SHA-256 checksum and Ed25519 signature of the manifest: an unsigned manifest is rejected. Download is only done via HTTPS with a limit of 200 MiB, with backup and atomic replacement before the switch.
Do you want to see the fleet in action?
We show you Sentinel live on your infrastructure: single console, anti-brick rollout and watchdog, calibrated on your servers.