Why Office Unbound · Hosting & deployment
Choose where it runs.
Know who runs it.
Office Unbound is being designed to run on infrastructure the customer owns or on infrastructure an MSP operates for them, with the same software in both cases. Choosing between them is mostly a decision about who carries which responsibility.
Project status Deployment design is part of Phase 1. Linux virtual machines on Proxmox VE are the initial deployment target; no installable release exists yet.
One platform, several operating models
A subscription platform has one operating model: the vendor runs everything. Office Unbound separates the software from the operator. The software is the same whoever runs it; what changes is where the hardware sits, who watches it, and who answers the phone when something breaks.
Model 1 Planned
Customer-hosted
The organization runs Office Unbound on its own servers — on premises, in colocation, or on a private cloud it administers.
This is the model with the most control and the most work. It suits organizations that already operate infrastructure, have staff who can run Linux services, and have a specific reason to keep the platform under their own hands: data-location requirements, network isolation, integration with systems that cannot be exposed to the internet, or a policy decision not to depend on an outside operator.
What you gain
- Direct ownership of the hardware and the data on it.
- Network policies you design — segmentation, firewalls, VPN-only administration.
- Operational procedures you define, including change windows.
- Control over the physical and legal location of data.
- Freedom to integrate with internal systems directly.
What you take on
- Hardware, storage and their replacement cycle.
- Monitoring, alerting and someone to respond to alerts.
- Backups, and regular tests that they restore.
- Security maintenance: OS, platform and firmware patching.
- Incident response, including out of hours.
- Availability planning: power, connectivity, spare capacity.
Model 2 Planned
MSP-hosted
A managed service provider runs Office Unbound on its infrastructure and delivers it to several customers.
For most small and midsize businesses this is the realistic way to use Office Unbound. The MSP brings the operational expertise and the infrastructure; the business gets a service operated by people it knows, with the option of changing provider without changing platform.
The platform is being designed for this from the start rather than adapted to it. One MSP installation is intended to host many customers as separate tenants, each with its own domains, users, policies and administrators, and with tenant isolation tested on every release. The MSP can delegate day-to-day administration — adding users, resetting MFA, managing shared mailboxes — to a customer’s own staff, while keeping infrastructure, updates and backups under its control.
- Professional management: monitoring, patching and backup handled by a team that does it for many customers.
- Repeatable deployments: standard builds and provisioning APIs, so customer number twenty is configured like customer number two.
- Customer-specific service plans: storage quotas, enabled workloads, update rings and support levels set per customer.
- Delegated administration: customer staff administer their own tenant within limits the MSP sets.
- Service flexibility: a sensitive customer can be placed on dedicated virtual machines or hardware.
Model 3 Under evaluation
Managed hosting
A commercially managed offering through approved hosting providers is a possible future option, for organizations that want Office Unbound without choosing or managing an operator themselves. Nothing of the kind is offered today, no providers have been approved, and there is no commitment that it will exist. It is mentioned here only so that the absence of a vendor-run service is not mistaken for an oversight.
Who is responsible for what
The division of work the platform is being designed around. In an MSP arrangement the contract decides the details; this table shows the usual split. It scrolls sideways on narrow screens.
| Responsibility area | Customer‑hosted | MSP‑hosted | Office Unbound project |
|---|---|---|---|
| Hardware, storage and network | Customer | MSP | Publishes sizing guidance |
| Virtualization platform and OS | Customer | MSP | Documents supported versions |
| Office Unbound updates | Customer stages and approves | MSP, by policy agreed with the customer | Publishes releases, notes and SBOMs |
| Security advisories | Customer acts on them | MSP acts on them | Publishes advisories and fixes |
| Monitoring and alerting | Customer | MSP | Provides health checks and metrics |
| Backups and restore tests | Customer | MSP | Documents what must be backed up |
| Incident response | Customer | MSP, with customer for user-side issues | Fixes software defects |
| Availability planning | Customer | MSP | Documents redundancy options |
| Domains, DNS and mail reputation | Customer | Shared: customer owns domains, MSP runs records and sending | Documents required records |
| Users, groups and policies | Customer | Customer, MSP, or both through delegation | Provides the tools |
| End-user support | Customer | Usually MSP | Not offered; support arrangements not yet defined |
| Regulatory compliance | Customer | Customer, with MSP evidence | Provides controls; no certifications |
The project column describes intended practice once releases exist. Today the project publishes nothing but this website.
Infrastructure Initial target
Proxmox VE and Linux virtual machines
The initial deployment target is Linux virtual machines running on Proxmox VE, the open-source virtualization platform. It provides KVM virtual machines, clustering, live migration between hosts, high-availability features and integration with Proxmox Backup Server, and it is already familiar to many infrastructure teams and MSPs.
Choosing one target lets the project test, document and automate a single path properly before widening it. It does not mean Office Unbound will only ever run on Proxmox VE — the services are ordinary Linux workloads — but other hypervisors and cloud platforms will be described as supported only once they have been tested.
Why virtual machines first
- Workloads can be separated cleanly, each with its own resources and failure domain.
- Snapshots and VM-level backups give a simple recovery baseline before updates.
- MSPs can place a customer on dedicated VMs without a different deployment design.
- Container-based deployment may follow where it suits a workload; it is not the initial target.
Modular by workload
Each service runs separately, so it can be maintained, sized and scaled on its own.
- Identity
- Small in resources and critical in importance: every other service depends on it. Candidates for redundancy first.
- Storage-heavy and sensitive to disk performance; grows steadily with mailbox history. Needs a clean, reputable outbound IP address.
- Files
- Usually the largest storage consumer. Capacity and backup design are dominated by it.
- Documents
- CPU and memory scale with concurrent editors rather than with stored data.
- Chat
- Database-heavy; grows with message history and the number of rooms.
- Meetings
- Bandwidth- and CPU-bound during calls, idle otherwise. Capacity is a function of concurrent participants, network and media configuration.
- Administration
- The console, provisioning, update and migration services. Light in normal use; heavier during migrations.
Because workloads are separate, an organization can add capacity where it is needed — more storage for files, more CPU for meetings — and update or restart one service without taking the others down. Exact sizing guidance will be published once it has been measured.
What determines how well it runs
Software is only part of a reliable service. These are the decisions that matter most, whoever operates the platform.
Storage design
Mail and files make up most of the data, and both need storage that is fast enough for interactive use and protected against disk failure. Local, shared and replicated storage each change the cost, performance and recovery picture.
Backup strategy
At least one copy off the primary hardware, ideally off site, with retention long enough to recover from mistakes noticed late. A backup that has never been restored is an assumption, not a backup.
Capacity planning
Storage grows every month; meeting load peaks at the top of the hour. Monitoring trends and adding capacity before it runs out is routine work, not a one-off sizing exercise.
Redundancy
Clustering hosts, replicating storage and running redundant instances of critical services reduce downtime, at the cost of more hardware and more complexity. Not every deployment needs all of it.
Operational expertise
Someone has to understand Linux, networking, DNS, certificates and mail delivery, and be reachable when something fails. For many businesses that someone is their MSP.
Network
Upload bandwidth, latency and a reputable public IP address matter more for self-hosted mail, file sync and meetings than for most other workloads.
Office Unbound does not claim unlimited scalability, any uptime figure, or any maximum number of users or meeting participants. Capacity depends on the hardware, storage, network and configuration of each deployment, and on the operator’s practices. Performance and high-availability testing are part of the hardening phase of the roadmap, and limits will be published from measurements, not estimates.
Planning where Office Unbound would run?
Tell us whether you would host it yourself or through a provider, and on what infrastructure. It helps decide which deployment paths are documented first.