FleetOS Manager
One console for every CryptOS node you
FleetOS Manager is the optional control plane for a CryptOS fleet. It shows every linked node, carries requests to the node that holds the CA, and records who did what. The nodes keep working without it, and it never holds a CA private key.
Marked Next release: on main and in the next release candidate, not in v0.1.0-rc.1.
What it is
A Go service with the console built
One binary, one TLS listener: the fleet API and the web console are served from the same port.
One listener
The fleet API speaks Connect, gRPC and gRPC-Web on the same TLS listener that serves the web console. The console is built from cryptos-web and embedded in the binary.
The node signs, not the manager
Every certificate is issued and revoked on the CryptOS node that holds the CA key. The manager forwards the request and the CSR; it holds no CA private key.
Certificates, not passwords
Operators sign in with a client certificate from your own operator CA, at viewer, operator or admin level. It is re-checked on every request against the manager's denylist, the CA's CRL and, where set, OCSP.
A hash-chained audit log
Every change is recorded with the operator who made it, in a log where each entry is chained to the one before.
How a node joins
Both sides check each other before a node
A node is never trusted on its word. An admin confirms what the node presents, and the node accepts only the credential the manager made for it.
- An admin points the adopt wizard at a node waiting in maintenance mode. The manager shows the certificate fingerprint the node presents, and the admin confirms it.
- The manager mints an admin credential for that node and installs CryptOS to a disk the node reports.
- The node reboots into its installed system and presents a new management certificate. The adoption pauses until an admin matches its fingerprint against the Mgmt SHA-256 line on the node's console.
- The manager runs the first-boot ceremony and registers the node.
- An operator gives the manager the node's address, an admin credential for it and the CA certificate its management certificate chains to.
- The manager connects and refuses the node unless its certificate verifies against that CA.
- The node signs a random challenge with its CA identity key. The manager checks the signature and pins the key's fingerprint.
- The link waits as PENDING until an admin approves it. On approval the manager checks the node again against the pin, and the node's own operator surface becomes read-only.
- An operator asks for a child CA to be signed by a parent CA in the fleet, under a named profile.
- The request waits as PENDING until an admin approves it.
- The manager carries the child's CSR to the parent node and the signed certificate back. The parent signs; the manager only carries.
Removing a node is explicit. Decommission wipes the node's identity and data and reboots it into maintenance, and only goes ahead when the admin types the node's Root CA name. Remove drops the node from the inventory and leaves the node alone.
Approvals
Requests wait for a
Approvals are one person's decision today, and nobody approves their own request.
Certificate requests
A viewer can file a CSR against a profile an admin has marked requestable. An operator or admin approves or denies it, never the requester. A request that isn't decided expires after 30 days.
Agent step-ups
When an AI agent on the optional MCP endpoint asks for something sensitive, such as a revocation or a profile change, it gets an approval link instead. Each approval covers that one exact request, runs once and expires after 15 minutes.
Link and subordinate requests
Linking a running node and signing a subordinate CA both wait as PENDING until an admin approves them.
Issuing and revoking
Issue and revoke through the node that holds the
The manager is a window onto the fleet, not a CA of its own.
Issue
An operator issues an end-entity certificate from a node's profile. Only the CSR crosses to the node; the key stays with whoever made it.
Revoke
An operator revokes by serial. The node that issued the certificate revokes it, and its CRL and OCSP responder carry the change where you have turned them on.
Inventory
The certificate list gathers every linked node's certificates in one place, with chain validation and per-node detail.
Rekey and protocols
An admin can rekey a node's CA and switch ACME or EST on or off per node. A protocol switch applies at the node's next reboot, and the manager shows it as waiting until the node reports it running.
Console and CLI
A web console and a command
The same checks apply to both: your client certificate decides what you can do.
The web console
- Dashboard and fleet topology
- Nodes, with each node's config, profiles, certificates and rekey
- Root CAs
- Adopt a node
- Enrollment requests
- Certificates
- Profiles
- Protocols
- Approvals
- Operators and operator CAs
- Agent keys
- Audit log
cryptos-managerctl Next release
An operator command line for the same API, for Linux, macOS and Windows, with JSON or YAML output for scripts.
$ cryptos-managerctl whoami $ cryptos-managerctl nodes list|get $ cryptos-managerctl certs list|get|issue|revoke $ cryptos-managerctl enrollments list|approve|reject $ cryptos-managerctl approvals list|approve|deny $ cryptos-managerctl profiles list
Storage
Bring your own database, or
The manager connects to storage you run; it never ships or manages a database. With no storage configured it refuses to start, rather than fall back silently.
| Mode | Setting | Use it for | Persists |
|---|---|---|---|
| PostgreSQL | database_url | The default, for any real deployment. | Yes |
| Key-value (Valkey or Redis) Next release | storage.mode: kv | When you already run Valkey or Redis. The server must persist with AOF; without persistence the manager won't start. | Yes |
| Memory | storage.mode: memory | Trying it out. One replica only, first run and MCP are off, and health reports degraded. | No, everything is lost on restart |
Ways to run it
Three ways to run
One self-contained image or binary, wherever suits you.
Kubernetes
The Helm chart, published on every release to oci://ghcr.io/cryptos-pki/charts/fleet-manager.
A container
docker run, or the compose file with a PostgreSQL you own on the same host. Images are published to ghcr.io/cryptos-pki/cryptos-manager.
A binary under systemd
Standalone on a VM, with no container runtime at all and a PostgreSQL you provide.
amd64 and arm64 Next release
The image is built for linux/amd64 and linux/arm64, so the same tag runs on an x86 host or an ARM board.
The deployment guide is in the FleetOS Manager docs: Deploy with Helm · First run · All FleetOS Manager docs