Office Unbound

Infrastructure · Overview

More than a productivity suite.
Operations designed in from the start.

Office Unbound is being designed with an infrastructure operations module for operators, intended to monitor services, detect failures, run approved recovery actions, manage updates, forecast capacity and help administrators scale their environments.

Project status Planned. The Infrastructure Control Server is in the roadmap’s Infrastructure Operations track; nothing described here has been built.

Beyond the applications

One platform. One coherent operational experience. Infrastructure you own.

Replacing email, documents, files and collaboration tools is the core of Office Unbound. Running them reliably is the other half of the job, and it usually falls to the people who host them.

The planned Infrastructure Control Server (ICS) is designed as the operational control plane for an Office Unbound deployment: an administrative module for operators, not an application end users see. It is intended to watch the hypervisors, hosts, virtual machines, containers and services the platform runs on; tell the right person when something is wrong; repair what it has been authorized to repair; schedule updates; and show where capacity is heading.

It is separate from the sign-in service and from tenant administration. Users and tenant administrators never reach it directly.

The tools administrators assemble today

Most self-hosted productivity platforms deliver the applications and leave operations to the operator. A typical deployment ends up with a separate tool, or a separate set of scripts, for each of these:

  • Virtualization management
  • Container monitoring
  • Service monitoring
  • Alerting and notifications
  • Incident escalation
  • Patch management
  • Performance analytics
  • Capacity planning
  • Recovery automation
  • Infrastructure scaling

Each one has its own configuration, its own credentials, its own upgrade cycle and its own idea of what the platform looks like. None of them knows that a failing mail queue matters more than a busy log volume.

Fewer tools. Less complexity. More control.

Office Unbound aims to bring the everyday operational workflows for these responsibilities into one management experience that understands the platform it is managing: which services depend on which, what healthy looks like for each, and who is responsible for them.

That does not mean rewriting monitoring or orchestration engines. The ICS is designed to integrate established open-source components (metrics collection and storage, alert routing, hypervisor APIs) and to present them as one coherent system. Which components are used is part of the evaluation.

What this is not

The ICS is not intended to replace every external tool or to run without administrators. It does not make outages impossible. Optional external notification providers remain available, and some of them require their own accounts or fees.

Twelve feature categories

The planned scope of infrastructure operations. Each links to where it is described in detail.

  • 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

What the overview is designed to show

Hypervisors, VMs, containers and service health on one screen, with active alerts, upcoming maintenance and capacity forecasts beside them.

Proposed interface concept Not released · example data · subject to change

The deployment on one screen: hosts, VMs, containers, service health, open incidents, maintenance and a capacity estimate. Open this concept

Four systems, kept separate

Infrastructure control, identity, tenant administration and the user workspace have different jobs, different users and different risks. They are designed as four systems with defined interfaces between them.

  • Infrastructure Control Server

    Hypervisors, hosts, VMs, containers, infrastructure monitoring, service health, updates, recovery, alerts, capacity planning and scaling.

  • Identity and authentication

    Login, single sign-on, MFA, user authentication, the identity lifecycle and authentication policies.

  • Tenant administration

    Organizations, users, groups, tenant settings, account provisioning, quotas, service entitlements and administrative roles.

  • User workspace

    Mail, calendars, contacts, documents, files, chat, meetings, telephony and personal settings.

Four systems, kept separate (planned) Four planned Office Unbound systems in layers. At the top, identity and authentication handles login, single sign-on, MFA, the identity lifecycle and authentication policies, and signs in both users and administrators. Below it, side by side, are the user workspace (mail, calendars, contacts, documents, files, chat, meetings, telephony and personal settings) and tenant administration (organizations, users, groups, quotas, account provisioning, service entitlements and administrative roles). Tenant administration sends authorized requests down to the Infrastructure Control Server through a restricted internal API that is scoped and audited. Tenant administrators hold no hypervisor credentials. The Infrastructure Control Server manages hypervisors, hosts, VMs, containers, monitoring, service health, updates, recovery, alerts, capacity and scaling. Below it are the hypervisors and hosts, Proxmox VE first, reached with scoped API tokens and agents whose credentials are held only by the Infrastructure Control Server. Planned design; nothing here is built. Office Unbound · planned Identity and authentication login · SSO · MFA · identity lifecycle · authentication policies signs in users signs in administrators User workspace mail · calendars · contacts · documents files · chat · meetings · telephony Tenant administration organizations · users · groups · quotas provisioning · entitlements · roles restricted internal API authorized · scoped · audited No hypervisor credentials tenant administrators act only via the API Infrastructure Control Server (ICS) hypervisors · hosts · VMs · containers · monitoring · service health updates · recovery · alerts · capacity planning · scaling scoped API tokens · agents Hypervisors and hosts Proxmox VE first · credentials held only by the ICS Planned design. Separate responsibilities and permissions; not necessarily separate hardware.
Conceptual Four planned systems. Tenant administration reaches the ICS only through a restricted internal API; hypervisor credentials stay with the ICS.
The boundary between tenants and infrastructure

When a tenant action needs infrastructure, for example more storage for a growing organization, tenant administration is designed to send an authorized request to the ICS through a restricted internal API. The ICS checks it against policy, carries it out and records it. Tenant administrators are never given hypervisor credentials, and the user workspace has no path to the ICS at all.

ICS design principles

A control plane that fails must not take the platform with it.

One logical system
One place to see and change infrastructure, with one audit trail, whether a deployment has one host or several clusters.
Optional high availability
A standby controller can be added where the operator needs it. A single controller is a valid deployment; a standby is a choice with its own cost.
Not a single point of failure
The ICS observes and manages workloads; it is not in their request path. Mail, files and meetings are served by their own services, not through the controller.
Workloads keep running
If the controller is unavailable, production services keep operating with their own restart policies. What stops is monitoring, alerting and automation until the controller returns.
The controller is monitored too
An external heartbeat (dead-man) check, running outside the platform, raises an alert when the ICS stops reporting.
Recoverable on its own
Controller configuration and state are backed up off-host, with a documented procedure to rebuild the controller.
Protecting the Infrastructure Control Server (planned) On the left is the Infrastructure Control Server, which holds monitoring and policy and backs up its configuration off-host, with an optional standby controller beside it that keeps a replica of the controller state. The controller manages three hosts through agents and collects their metrics; each host runs workloads. The workloads keep running, with their own restart policies, if the controller is unavailable. The controller sends a regular heartbeat to a heartbeat monitor that runs outside the platform. It sends alerts through an independent notification provider that does not depend on the platform’s own mail. If the heartbeats stop, the heartbeat monitor alerts through the same provider. The provider reaches the on-call administrator by SMS, Pushover or push notification. Planned design; the standby controller is optional. Control plane Outside the platform heartbeat Control Server (ICS) monitoring · policy config backed up off-host Standby controller optional replica of controller state Heartbeat monitor separate host or service alerts if heartbeats stop alerts that do not depend on platform mail Notification provider independent of platform SMS · Pushover · push On-call administrator manage · collect metrics Host A agent mail identity Host B agent files documents Host C agent chat meetings Workloads keep running, with their own restart policies, if the controller is unavailable. Planned design. Standby controller optional; monitor and provider run outside the platform.
Conceptual The ICS with an optional standby. Workloads on each host keep running if the controller is down; an external heartbeat monitor and an independent notification provider sit outside the platform.

Control without dependence.

Core infrastructure monitoring and management are designed to run on the operator’s own infrastructure, with no mandatory vendor-operated cloud service. The project does not intend to require an account with anyone to see whether your own servers are healthy.

External services remain an option where they add something: an SMS gateway, a push notification service or an incident-management platform the operator already uses. They are connected by choice, and the ICS is designed to keep working without them.

Built for the people who run it.

From businesses running their own infrastructure to MSPs operating many customer environments, the ICS is designed to make complex operations easier to understand and control.

  • A business with one or two hosts gets monitoring, alerting and update control without building a monitoring stack first.
  • An MSP sees every customer environment in one place, with per-customer alert policies, maintenance schedules and reports, including separately hosted customer deployments through authorized connections.

Office Unbound for MSPs

In detail

  • Infrastructure control

    Hypervisor and VM management, containers and services, and how credentials are kept to the minimum.

  • Monitoring and alerting

    Alert conditions, severity levels, notification channels and escalation, including when the platform’s own mail is down.

  • Recovery and maintenance

    Three automation modes, approved recovery actions, and updates on the operator’s schedule.

  • Capacity and scaling

    Forecasts with stated assumptions, scaling recommendations and controlled implementation.

Operating infrastructure for others?

If you run hosting or managed services, tell the project which operational problems cost you the most time. That shapes what the Infrastructure Operations track builds first.

MSP partnership inquirySee the roadmap
Share