Resources · Architecture
Target architecture
Five layers (access, identity, productivity services, administration and data), built as separate workloads on Linux virtual machines and managed from one administration layer. This is the design Phase 1 is refining, and the frame every component is evaluated against.
Project status Conceptual target. The architecture is being designed in Phase 1; nothing described here is deployed or tested yet.
Why layers
Each layer has one job, one owner and one way to fail.
Office Unbound joins several independent open-source systems (a mail server, a file platform, a document editor, a messaging homeserver, a media server) into something users experience as one product. The risk in that kind of platform is coupling. If every service knows about every other, one upgrade becomes everyone’s upgrade and one failure becomes everyone’s outage.
The architecture prevents that by giving each concern its own layer with a defined interface. Clients only ever talk to the access layer. Every service trusts the same identity layer instead of keeping its own passwords. Productivity services keep their data in the data layer and do not reach into each other’s storage. The administration layer is the only part that configures all of them, through their own APIs. A service can then be replaced, upgraded or scaled without the rest of the platform needing to know.
The five layers
Clients at the top, Proxmox VE hosts at the bottom. Administration sits beside the stack because it manages every layer below the access layer.
Layer by layer
What each layer is responsible for, and the candidate technology being evaluated for it. See technology and licensing for each candidate.
- 1 · Access
The one front door. A reverse proxy terminates TLS for every service, routes requests, and applies access policies, for example restricting the admin console to certain networks, before anything reaches a workload. The unified web experience is served from here, so mail, files, documents, chat and meetings share one navigation and one look rather than five. Client authentication starts here and hands off to the identity layer.
Desktop sync clients, mobile apps and standard mail clients (IMAP, SMTP, CalDAV, CardDAV) are intended to connect through the same layer, with mail protocols passed through at the connection level, so there is one set of certificates and one place to see who is connecting.
- 2 · Identity
Single sign-on and MFA for every service, directory integration and user and group policies. A user exists once, in one place, and every service learns who they are and which groups they belong to from here. Disabling an account here disables it everywhere. Keycloak (OpenID Connect, SAML) is the leading candidate, with Samba AD or an LDAP directory where an organization needs one or already has Active Directory to integrate with.
- 3 · Productivity services
The workloads people use: email and calendars, office documents, file collaboration, chat and channels, and meetings and calling. Each is a separate service built on an established open-source project: grommunio or Stalwart for mail, Nextcloud for files, Collabora Online or ONLYOFFICE Docs for documents, Matrix for chat, LiveKit and MatrixRTC for meetings, FreeSWITCH for telephony. They integrate with each other at defined points, such as a document opening from the file service in the editor, or a meeting created from a calendar invitation, rather than by sharing internals.
- 4 · Administration
Office Unbound’s own services, and the layer that makes the components one platform. Tenant provisioning creates an organization’s users, mailboxes, storage and chat spaces across every service in one operation. The management API exposes the same operations to MSP tooling such as clientst0r. Policy management applies authentication, retention and sharing rules consistently. The migration control center runs assessments and migrations from Microsoft 365 and Google Workspace. Monitoring, update control and auditing cover every service, with one audit trail of administrative actions.
- 5 · Data
Mail storage, file storage, databases, collaboration data such as chat history, and configuration, together with backup and recovery for all of them. Keeping data in its own layer means storage can be sized, replicated and backed up according to what it holds. Mail and file storage grow very differently from configuration databases. It also means that exporting an organization’s data is a defined operation rather than an archaeology project.
On Proxmox VE
The initial deployment target: Linux virtual machines on Proxmox VE. Initial target
Each service in the diagram is intended to run in its own Linux virtual machine, or a small group of them. Proxmox VE was chosen as the first target because it is open source, runs ordinary Linux VMs that need no special packaging, and is already common among MSPs and smaller hosting providers who are the platform’s likely operators. It brings clustering, live migration between hosts, shared and replicated storage options and built-in backup, which a deployment can use rather than reinvent.
Separating workloads into their own VMs is a deliberate trade: more machines to run, in exchange for these properties.
| Property | How the design provides it |
|---|---|
| Independent updates | The mail server can be patched, snapshotted and rolled back without touching file storage or chat. Update control in the administration layer schedules each service on its own. |
| Independent scaling | A service under load, often meetings or document editing, can be given more resources or more instances without resizing everything else. |
| Contained failure | A fault or resource exhaustion in one service stays in its VM. Users may lose meetings for a time without losing mail. |
| Security boundaries | Each VM exposes only the ports its service needs, on network segments the access layer controls. A compromise of one service is not automatically a compromise of all. |
| Targeted backup | Backup schedules and retention match the data: frequent for mail and files, less frequent for stateless services that can be rebuilt from configuration. |
| Replaceable components | If a component is replaced, for instance one mail server for another, the change is confined to that service and the administration layer’s connector for it. |
No architecture scales without limit. How many users a deployment supports depends on hardware, storage design, network capacity, media configuration for meetings, and operational expertise. Capacity guidance will be published once it has been measured. Redundancy, meaning more than one host, replicated storage and tested recovery, is a choice each operator makes and pays for. Several hosts in a diagram are not, by themselves, a high-availability design.
Central administration
Each component comes with its own admin interface, its own user model and its own logs. Left that way, an administrator onboarding one employee would visit five consoles. The administration layer replaces that with one set of operations, such as “create user”, “add domain”, “apply retention policy” or “offboard user”. These are carried out against every service through each component’s own API, and recorded in one audit trail.
The components’ own admin interfaces remain available for deep troubleshooting, but they are not where routine work happens. Configuration is held by the administration layer as the source of truth, so a service can be rebuilt from it, and a deployment can be documented, exported and moved to another operator. See ownership and independence.
Multi-tenant considerations
Most deployments will serve more than one organization, whether an MSP’s customers or an enterprise’s subsidiaries. That shapes the architecture from the start.
Tenancy in every layer
A tenant is an organization with its own domains, users, policies and administrators. Each layer has to know which tenant a request belongs to: the access layer routes by domain, identity keeps tenants in separate realms or directories, services keep tenant data apart, and administration scopes every action to a tenant.
Uneven support in components
Candidate components differ in how well they handle many tenants in one instance. In some, multi-tenancy is native. In others it is limited, or sits in a commercial edition. Where a component cannot isolate tenants reliably, the fallback is separate instances per tenant, which costs more resources but is simpler to reason about.
Delegated administration
An MSP technician, a customer’s own IT lead and a platform operator need different powers. The role model is designed so customer administrators see only their tenant, and MSP roles are granted per customer, not platform-wide by default.
Isolation is tested, not assumed
Cross-tenant authorization testing, trying to reach one tenant’s data with another’s credentials, is part of the planned security verification for every release. A tenant boundary that has not been tested is treated as not existing.
What is still open
Phase 1 is meant to settle these questions. The answers will be recorded in project updates.
- Which mail server, and therefore how far Exchange protocol compatibility can go
- Which document editor, given the licensing and edition differences
- Per tenant, which components can share an instance and which need their own
- How the unified interface embeds or wraps each component’s web interface
- The connector model between the administration layer and each component’s API
- Reference storage and backup designs for single-host and clustered deployments
Reviewing the architecture?
If you are evaluating Office Unbound for an enterprise or a hosting business, tell us what you would need to see. It shapes what we document and test first.