Manager
Access Manager safely and understand its permissions, state views, and high-risk operation boundaries.
Manager is a dedicated administrative listener with an embedded Web console. It aggregates cluster state and operational tasks, but it does not replace change approval, backup verification, or product acceptance.
Safe access
Enable manager.auth_on in production, replace fixed-user passwords and manager.jwt_secret, expose manager.listen_addr only to an administrative network, and terminate TLS at the external boundary. Do not share an unprotected entry point with product HTTP APIs, client traffic, or public metrics.
With manager.auth_on=false, ordinary read and write groups install no permission middleware, so most administrative mutations can still reach their handlers. Only backup writes, restore, and MCP administration keep explicit fail-closed gates; /mcp uses a separate Bearer. Do not treat disabled authentication as read-only mode.
Main views
| Area | Purpose | What it does not prove |
|---|---|---|
| Nodes and realtime | Node health, readiness, roles, resources, and work queues | Sufficient capacity or safe removal |
| Controller and tasks | Consensus state, control tasks, and advancement results | Every product Channel has migrated |
| Slots | Replica, leader, ISR, and log state for all 256 physical hash slots | That the physical hash-slot count should change |
| Channels and product queries | Channel, subscriber, user, device, and message projections | Permission to bypass product data boundaries |
| Backups | Plan, repository verification, archives, and restore workflow | Recoverability immediately after saving settings |
The node configuration view is a bounded, redacted snapshot of effective startup configuration. It never returns raw Manager credentials, join tokens, or complete sensitive environment values, and it does not imply hot reload.
Least privilege
- Node and realtime reads generally require
cluster.node:r; Slot reads requirecluster.slot:r. - Node join, activation, onboarding, and scale-in reads and writes are guarded by
cluster.node:randcluster.node:w, respectively. Separate Slot inventory, log, leader-transfer, and compaction operations usecluster.slot:randcluster.slot:w; they are not additional gates on the scale-in routes. - Backup reads and mutations use
cluster.backup:randcluster.backup:w. - Restore requires the explicit
cluster.restore:w; wildcard permission does not substitute for it.
Product queries and mutations use their own fine-grained permissions. Avoid permanent broad access. Use separate roles for observation, scaling, backup, and restore.
Executing a mutation
- Record the operator, target node or task, current configuration/control revision, and expected result.
- Inspect
/readyz, Manager state, active control tasks, and affected Slots or Channels. - Use plan or preview first; confirm targets, blockers, and bounded batches.
- Execute one step, wait for terminal task state, then reread authoritative state.
- Advance only after product verification. Stop on conflicts, stale revisions, or unknown state.
A button is not safety evidence
Manager actions and status hints are operating entry points, not approval conclusions. Scale-in must wait for authoritative safe_to_remove=true (after which diagnostics recommends ready_to_remove); restore must complete full verification and confirmation.
Next, establish a baseline in Health & Monitoring, or continue with Scaling and Backup & Restore.