Solutions · Enterprise IT
A platform you can evaluate
on architecture, not assurances.
Enterprise IT teams judge productivity platforms on identity integration, governance, auditability, recovery and how they behave under load. Office Unbound is being designed to be examined on those terms — with its source, architecture and limits open to inspection.
Project status Office Unbound is in architecture and evaluation. There is no release to test; this page sets out what is being designed and what evidence exists for each claim today.
Where this fits in an enterprise
Large organizations rarely replace a productivity platform in one step, and none should replace one on the strength of a marketing site. The realistic enterprise interest in Office Unbound at this stage is threefold: tracking a candidate platform for workloads where control of infrastructure and data is a requirement rather than a preference; influencing its design while that is still possible; and planning a pilot for a defined group — a subsidiary, a division in a particular jurisdiction, a sensitive project — once core services exist.
Microsoft 365 and Google Workspace bring mature compliance tooling, large partner ecosystems and years of operation at a scale Office Unbound will not match for a long time. The difference Office Unbound offers is architectural: an open-source platform that runs on infrastructure the organization chooses, integrates with the identity systems it already operates, is updated on its schedule, and can be read line by line by its own security team.
Evaluation criteria
The questions an architecture or security review would ask, what Office Unbound intends in each case, and what you could actually verify today. The third column is deliberately blunt.
| Criterion | What to ask | Design intent | Evidence today |
|---|---|---|---|
| Architecture transparency | Can we see how the platform is composed, and what runs where? | Published target architecture; modular services in separate workloads; public source and component inventories. | Conceptual architecture published. No code released. In development |
| Identity integration | Does it use our identity provider and directory, or impose its own? | SSO over OIDC and SAML; LDAP and directory integration; Active Directory interoperability where validated. | Keycloak and Samba AD/LDAP are candidates. Under evaluation |
| Security governance | Who can change what, and how are policies enforced? | Role-based administration, delegation, authentication and session policy, organization-wide security policies. | Design work only. Planned |
| Auditability | Can we reconstruct who did what, across every service? | One audit trail for administrative actions across mail, files, chat and identity; exportable logs. | Design work only. Planned |
| Data control | Where is data stored, who can reach it, and can we take it out? | Customer-chosen infrastructure and location; data access policies; export in open formats. | Architectural property of self-hosting; tooling Planned |
| Independent deployment | Can we run it without any dependency on the project or a vendor? | Self-hosted deployment from published software and documentation, operable by your own team or a provider you choose. | Intent. Depends on final component licensing. Under evaluation |
| Recovery planning | How is it backed up, restored and failed over? | Documented backup and restore per service; recovery testing; high availability in a later phase. | Recovery testing and high availability are in the hardening phase. Planned |
| Capacity planning | What does it need for our user count and usage pattern? | Workloads scaled separately; sizing guidance from performance testing. | No performance testing yet; no sizing figures exist. Planned |
| Testing and validation | Can we stage updates and test before production? | Staging, update approval, release documentation, regression and tenant-isolation testing. | Process design only. Planned |
“Evidence today” will be updated as phases complete. Until a capability is released and verified, nothing on this site should be read as a statement that it works.
Identity first
In an enterprise, the productivity platform is a consumer of identity, not its owner.
Every Office Unbound service is intended to sit behind one identity layer, so that sign-in, MFA, group membership and session policy are defined once. For an enterprise, the more important question is how that layer connects to what already exists.
- Federation
- Office Unbound’s identity layer acting as a service provider to your existing identity provider over SAML or OIDC, so users authenticate where they already do and your MFA and conditional rules continue to apply. Planned
- Directory integration
- Users and groups read from an existing LDAP directory, so joiners, movers and leavers are handled by the processes you already run. Planned
- Active Directory
- Interoperability with Active Directory environments, stated only where it has been validated against real configurations. Under evaluation
- Provisioning and deprovisioning
- Automated account creation and removal from the directory or through the management API, including what happens to mail and files when an account is removed. Planned
Existing Entra ID or Google passwords and MFA secrets cannot be transferred by migration. Federation with an identity provider you keep is one way to avoid re-enrollment; where that is not possible, enrollment has to be planned as part of the move.
Recovery and capacity are your design decisions.
A cloud subscription hides storage design, redundancy and capacity behind a service level agreement. Running Office Unbound puts them in front of you. That is the point for organizations that want control — and it means availability is a property of the deployment you build, not of the software alone.
The architecture separates workloads — mail storage, file storage, databases, collaboration data — so each can be sized, backed up and recovered on its own terms. The project will not publish scalability claims it has not measured.
- Storage design. Mail and file stores grow at different rates and fail in different ways; they are planned as separate concerns.
- Backup strategy. Per-service backup and restore, with restores tested rather than assumed.
- Redundancy. High availability and failover are planned for the hardening phase, after core services are stable.
- Capacity planning. Sizing guidance will come from performance testing on the Proxmox VE target, not estimates.
- Operational expertise. The platform needs people who understand mail, storage and identity — your own team or a provider.
How an enterprise pilot could run
Once core services exist. Not before.
Architecture and security review
Your team reads the published architecture, source and component inventory, and raises questions while they can still change the design.
Isolated test deployment
A deployment on your own infrastructure, federated to a test instance of your identity provider, with no production data.
Assessment of a real source tenant
The planned assessment engine inventories a defined group in Microsoft 365 or Google Workspace and reports what would and would not transfer.
Pilot group
A small group uses the platform for real work, with the source platform kept fully available.
Decision with evidence
Compatibility findings, operational effort, incident history and user feedback from the pilot, rather than vendor claims.
Office Unbound holds no certifications and has completed no independent security audit. It makes no claim to HIPAA, SOC 2, ISO 27001 or any other compliance standard, and does not claim parity with Entra ID, Microsoft Purview or Google Workspace administration. Retention, legal hold and discovery workflows are planned compliance-oriented features; whether a deployment meets a given obligation depends on how it is configured and operated.
Evaluating platforms for your organization?
Tell us your scale, identity environment and the workloads you would want to test first. Enterprise requirements feed the MSP and enterprise phase of the roadmap.