Cenvero Fleet - Self-hosted fleet management with files & Ai agentic control

by
Cenvero Fleet is an open-source, self-hosted platform for engineers who want full control — one Go binary, no SaaS lock-in, no cloud. It manages Linux, macOS & Windows nodes over encrypted SSH (direct or reverse), even behind NAT with no VPN. v2 adds a secure file manager (CLI, dual-pane TUI & web GUI) with resumable transfers, live directory sync, and agentic control so AI agents like Claude Code can drive your fleet — plus RBAC, encrypted secrets, tamper-evident audit log, and much more.

Add a comment

Replies

Best

The agentic control angle is interesting.

How are you handling permission boundaries for AI agents? For example, can an agent be restricted to specific hosts, directories, or actions so it can’t accidentally make fleet-wide changes?

  Yes — that's exactly what the RBAC layer is designed for, and it's the recommended way to run an AI agent against the fleet. Rather than giving an agent admin access, you hand it a scoped token (passed via an environment variable). The

  token is stored only as a hash, and enforcement is fail-closed: a scoped token is denied everything by default and is granted only what its scope explicitly permits, so anything outside that scope is rejected at the controller before it

  ever reaches a host. 

  

  A token can be constrained on several independent axes at once. You can pin it to specific hosts — either named servers or tag-based groups like role=web — so an agent scoped to the web tier simply cannot touch the database tier, and

  fleet-wide operations like exec --all just fail. You can restrict it to specific actions with an allow-list and/or deny-list of commands (for example, an agent gets exec, file, and logs and nothing else). You can lock it down to specific 

  secrets with a per-secret allowlist, where a scoped token with no secret grant is denied all secret access. And destructive operations — removing a server, rotating keys, pushing a controller update, disabling a firewall, bootstrapping —

  are denied by default for scoped tokens unless you explicitly opt the token into them, with read-only-by-default available as well. So a token scoped to two web servers, limited to exec/file/logs, and read-only literally cannot make a

  fleet-wide change, and every attempt is recorded.

  

  Directory confinement is handled by a separate, host-level layer: each agent runs with a --file-root sandbox that confines all file reads, writes, and listings to a chosen subtree on that host, enforced on the agent side so even an

  otherwise-authorized controller can't escape it. The one nuance worth being upfront about is that this directory restriction is set per-agent at install time rather than per-token — so host, action, and secret scoping live on the token,

  while directory confinement is a property of the host.

  

  On top of all that there are additional guardrails that apply even within an agent's granted scope: a command policy that can deny or require confirmation for dangerous patterns, an approval workflow that stages an action for human

  sign-off instead of running it, a guard/dead-man's-switch that blocks changes which could lock out the controller and can auto-revert unconfirmed changes, output redaction that scrubs secrets, and a tamper-evident, hash-chained audit log

  that attributes every action to the token that performed it — so you can always prove exactly what an agent did. The honest boundary is that this protects against an agent exceeding its grant; it assumes the controller host itself is

  trusted.

 We're actively improving Fleet and genuinely welcome outside input — if you have suggestions, spot a gap, or want to open a PR, we'd love that, and it helps us make it better for everyone. Thanks for the thoughtful question!