Infrastructure · Control
Hypervisors, VMs, containers
and the services on them.
The Infrastructure Control Server is designed to manage the hosts, virtual machines, containers and services an Office Unbound deployment runs on, starting with Proxmox VE, using only the access an operator explicitly grants.
Project status Planned. The Infrastructure Control Server is in the roadmap’s Infrastructure Operations track; nothing described here has been built.
What “control” covers
Three layers, each with its own integration.
- Hypervisors and VMs
- Clusters, hosts and the virtual machines on them, through the hypervisor’s own API with a restricted token.
- Containers
- The Docker containers and Compose stacks that make up each Office Unbound service, through a management agent on each host.
- Services
- Mail, identity, files, documents, chat, meetings and the dependencies under them, checked the way a user would use them.
Proxmox VE is the initial hypervisor target Initial target. The integration layer is designed so other hypervisors can be added later without changing how the rest of the ICS works.
Proposed interface concept Not released · example data · subject to change
Quorum 3 of 3ceph-a healthy
- CPU38%
- Memory77%
- Storage52%
Quorum 3 of 3 votesceph-b write latency
- CPU31%
- Memory37%
- Storage71%
ics@pve!office-unboundAPI token
- Scope
- Pool office-unbound · 18 VMs · storage ceph-a
- Granted
- VM.AuditVM.PowerMgmtVM.MigrateVM.Allocate pool onlyDatastore.AllocateSpace ceph-a onlySys.Audit read-only
- Not granted
- rootSys.ModifyPermissions.ModifyUser.Modify
- Expires
- in 62 days · last rotated 14 Sep · stored encrypted
Access to 14 other VMs on this cluster: none (not in scope)
Rack 1Failure domain · own power feed
pve-a1Cluster A
mail-01db-01files-01+4
pve-a2Cluster A
mail-02docs-01id-01+3
Rack 2Failure domain · own power feed
pve-a3Cluster A
db-02search-01proxy-01+2
pve-b1Cluster B
meet-01chat-01+1
pve-b2Cluster B
calls-01backup-01+1
- mail-01 and mail-02 on different hosts
- db-01 and its replica db-02 in different racks
- Rack 2 holds all of cluster B: one power fault stops it (as in INC-2031)
| VM | Host | State | vCPU · memory | CPU | Last backup | Actions |
|---|---|---|---|---|---|---|
| mail-01Mail, IMAP | pve-a1 | Running | 4 · 16 GB | 9% | Today 01:12 | |
| mail-02Mail, SMTP relay | pve-a2 | Running · service failing | 4 · 16 GB | 2% | Today 01:14 | |
| db-01PostgreSQL primary | pve-a1 | Running | 8 · 48 GB | 22% | Today 01:30 | |
| search-01Search and indexing | pve-a3 | Running | 4 · 24 GB | 41% | Today 01:41 | |
| docs-01Document engine | pve-a2 | Running | 6 · 16 GB | 12% | Today 01:20 | |
| meet-01Meetings | pve-b1 | Running | 8 · 32 GB | 6% | Today 00:58 |
Waiting for approval: migrate search-01 from pve-a3 to pve-a2 · requested by D. Okafor 01:10 · second approver S. Reyes · runs only if the target has room and the VM’s backup is less than 24 hours old.
Hypervisor and VM management
The planned Proxmox VE integration, grouped by what an operator does with it.
- Concept An idea or design direction; not yet committed to the roadmap
- Under evaluation Being assessed; no choice made yet
- Planned Committed to the roadmap; work not started
- In development Being worked on now
- Implemented Code exists in a public repository
- Tested Passed published tests
- Production-ready Shipped in a supported release
| Capability | What it means | Status |
|---|---|---|
| Clusters and hosts | Multiple Proxmox VE hosts and clusters connected to one controller, each with its own credential. | Planned |
| Discovery and inventory | VMs found and recorded with their resources, host and role, so the inventory matches what is actually running. | Planned |
| Provisioning | Authorized creation of new VMs for Office Unbound services, within the resource pools the token allows. | Planned |
| Lifecycle and power | Start, stop, reboot and snapshot, with each action recorded. | Planned |
| Resource monitoring | CPU, RAM, disk and network utilization per VM, and the resources still available on each host. | Planned |
| Hypervisor and cluster health | Host health, cluster quorum and redundancy checks: whether the cluster can lose a host and keep running. | Planned |
| Storage | Health and capacity of the storage each VM depends on. | Planned |
| Migration and resizing | Moving a VM between hosts where the cluster supports it, and changing its CPU, memory or disk allocation. | Planned |
| Topology and failure domains | Which VMs share a host, a storage pool or a rack, so redundant services are not placed where one failure takes both. | Planned |
| Hardware monitoring | Disk, temperature and power data through supported integrations, where the hardware exposes it. | Planned |
| Change history | Every operational change to a VM or host, with who requested it, who approved it and the result. | Planned |
| Proxmox VE API | The initial integration path, using the hypervisor’s documented API and token permissions. | Under evaluation |
Infrastructure security & credential control
Powerful control.
Limited privileges.
Office Unbound is designed to manage only the infrastructure you explicitly authorize. Restricted credentials, scoped permissions and auditable actions keep operational control where it belongs.
The ICS has to hold credentials for the hypervisors it manages. That makes it a sensitive system, and it is designed on the assumption that those credentials are the most valuable thing an attacker could take from it. The aim is that a compromised controller can affect only what it was explicitly given, and that every use of its access is on record.
When a hypervisor is connected, the setup wizard is designed to recommend restricting the credential to the hypervisors, clusters and resources Office Unbound actually needs, and to show what the token can reach before it is saved.
Least-privilege tokens
API tokens with only the permissions the ICS uses, not a general administrator login.
Resource-level scope
Permissions limited to specific pools, VMs or storage. No access to unrelated virtual machines.
No root by default
Unrestricted root credentials are not used by default, and the wizard warns explicitly before broad privileges are granted.
Encrypted storage
Credentials encrypted at rest and never shown back in the interface once saved.
Rotation and expiry
Tokens with expiry dates, rotation reminders and an alert before a credential lapses.
Revocation
Access to a hypervisor or cluster withdrawn in one step, from the ICS or the hypervisor itself.
Approvals
High-impact actions, such as deleting or migrating a VM, can require a second administrator’s approval.
Audit trail
Every action taken with a credential recorded with the requester, the approver and the outcome.
Separation from tenants
Tenant administrators never receive hypervisor credentials; their requests reach the ICS through a restricted internal API.
Docker and container management
The ICS is intended to manage every registered Office Unbound container and supporting service across the infrastructure it is authorized for.
| Area | What it covers |
|---|---|
| Inventory | Container discovery, Docker Compose stack inventory, image and version tracking |
| Health and usage | Status and health checks, CPU and memory, network activity, disk and storage consumption |
| Failure | Failed container detection, restart history, dependency monitoring, container logs |
| Security | Vulnerability information for images, update availability |
| Change | Controlled updates, scheduled maintenance, backup and rollback coordination |
| Recovery | Automated recovery policies, within the limits described under recovery |
Docker Compose describes and runs containers on a single host; it does not orchestrate across several. Deployments that span multiple hosts are designed to be managed through an agent on each host and, where an operator uses one, integration with an orchestration system. Which agent design and which orchestration integrations to support is part of the evaluation Under evaluation.
Service monitoring
A running process is not the same as a working service.
A mail server process can be up while every login fails because the identity service is unreachable, the certificate has expired or the mailbox storage is read-only. Checking only that the process exists would report it healthy.
The ICS is designed to use application-level health checks: an IMAP login with a dedicated test account, a test message through SMTP to a probe mailbox, a file uploaded and read back, a document session opened in the editor, a sign-in through the identity service. Each check is tied to the components it exercises, so a failure points at a cause rather than just a symptom.
| Group | Services |
|---|---|
| SMTP and IMAP, mail delivery queues, spam filtering | |
| Identity and data | Identity and SSO, databases, search and indexing |
| Productivity | Calendar and contacts, file storage and synchronization, Collabora Online and alternative document engines, chat and collaboration, meeting servers, telephony and SIP |
| Platform | Reverse proxies, APIs, DNS, TLS certificates, internal platform dependencies |
| Protection | Backups, storage replication |
Inventory and configuration
The ICS is intended to keep one infrastructure inventory: hosts, VMs, containers, services, their versions and the relationships between them. That inventory is what the monitoring, update and capacity features work from, so it has to match reality. Discovery reconciles it against what is actually running and flags differences.
Configuration for the infrastructure layer is held in the ICS and changes are recorded, so drift from the intended configuration can be detected and reported.
Operational audit
Every action the ICS takes or is asked to take is designed to be logged: what was requested, by whom or by which policy, whether it was approved, what was done and what happened. The same log records credential changes, policy changes and access to the controller itself.
The ICS audit log is separate from the tenant audit trail described under security controls, because the people and risks involved are different.
Running Proxmox VE today?
Tell the project how your clusters are organized and how you restrict access to them. That informs the first hypervisor integration.