Self-hosted Microsoft Teams alternative for EU sovereignty

Why a self-hosted Microsoft Teams alternative for EU digital sovereignty is a different question from EU data residency

For a public body or regulated buyer, the question is not only where the data sits but who can administer the system that holds it. Microsoft's EU Data Boundary keeps customer data for in-scope services within the EU and EFTA, but the service still runs on Microsoft's cloud, under Microsoft's operations and support model. A fully self-hosted stack changes that arrangement: the organization decides who holds administrator rights, where the servers run, which patches are applied and when, and what happens if a vendor relationship ends. openDesk, which bundles Element, Jitsi and Nextcloud on Kubernetes, and Matrix with Element, or Mattermost, can all be run inside the organization's own cloud accounts, data centers or air-gapped networks, so administration can stay inside the organization.

Operational control is a different test from residency, and it has to be checked separately. A data residency answer tells you where storage sits. A sovereignty answer also has to cover the people and processes that operate the platform: who can read logs, who can open a support session into a running cluster, which vendor or upstream project ships security fixes, and whether a foreign authority could compel a provider holding keys or access. Remote access from a third country, even only displaying data on a screen for support, is treated as a transfer under the EDPB's guidance, so support paths belong in the assessment alongside storage locations. Confirm with your own counsel and data protection officer how these questions apply to your processing.

Decide early which control matters most for your organization, because it determines the stack. If the requirement is that no vendor holds administrative access, plan for in-house or partner-run operations with no external support path left open by default. If the requirement is that the platform must run without internet access, check each candidate's offline model before shortlisting, since openDesk expects production-grade external services such as PostgreSQL, an SMTP relay and object storage that you must provide. Ask each vendor, in writing, which support tiers and access paths they offer, and map those answers to your own control framework rather than to a residency label.

What the sovereignty constraint requires of a chat platform

A chat platform that holds employee messages, files and metadata falls under the same transfer and access rules as any other personal data system. The cards below set out what the controller must assess before choosing a stack, and what each rule means for where the servers run, who can reach them and how the organization can leave later.

Remote access counts as transfer

Under GDPR Article 44, every transfer of personal data to a third country, including onward transfers, must meet the Chapter V conditions. EDPB Guidelines 05/2021 treat remote access from a third country as a transfer, even when data is only shown on a screen for support or administration. For a chat platform, this covers vendor engineers, managed service staff and remote troubleshooting sessions, not only where the database sits. Check who can log in to the servers, from which countries, and under which support contracts.

Foreign law reaches EU-held data

The US CLOUD Act provision at 18 U.S.C. 2713 requires electronic communication and remote computing service providers to preserve or disclose data in their possession, custody or control, wherever that data is located. A provider headquartered outside the EU can therefore receive a demand for EU-hosted chat history. Under GDPR Article 48, a third-country court order is enforceable in the EU only if it rests on an international agreement, so the controller should ask each provider how it handles such requests and whether it has contractual notice obligations.

Data Privacy Framework and pending appeal

Commission Implementing Decision (EU) 2023/1795 finds adequate protection only for US organizations on the Data Privacy Framework List. Following Schrems II, where the Privacy Shield was invalidated but standard contractual clauses survived, the transfer basis for a US vendor rests on that list or on clauses backed by a supplementary assessment. An appeal against the General Court's September 2025 judgment is pending as Case C-703/25 P. Record the transfer mechanism for each vendor and set a review date tied to the outcome of that case.

Supplementary measures for cloud access

EDPB Recommendations 01/2020 state that where a cloud provider needs access to data in the clear and the destination's public authority powers go beyond what is necessary and proportionate, no effective technical supplementary measure can be identified. Encryption helps only when the key stays with the controller and the provider never sees plaintext. For a self-hosted chat stack, this means deciding where encryption keys live, whether the operator needs clear-text access, and whether the platform has end-to-end encryption on for sensitive rooms. Document the assessment before go-live.

Switching rights under the Data Act

Article 32 of Regulation (EU) 2023/2854 requires data processing service providers to take technical, organisational and legal measures against third-country governmental access to non-personal data held in the Union where that access would conflict with EU or national law. The Data Act has applied since 12 September 2025 and gives customers a right to switch to another provider or to on-premises infrastructure, with a maximum two-month notice period and a 30-day transition. Switching charges are banned from 12 January 2027. Ask any SaaS vendor for its exit terms in writing before signing.

Which open-source option meets the constraint and what it gives up

This table compares openDesk, Matrix with Element and Synapse, and Mattermost on sovereignty fit, components, licensing, production requirements and gaps. Read each row against your own operating model, since the strongest option depends on whether you need a full suite, a chat-only server or a team-sized tool.

Criterion	openDesk	Matrix with Element and Synapse	Mattermost
Scope of what it replaces	Full digital workplace: chat, files, office, groupware, wiki, project tools and video	Chat, calls and federation; files and office are separate choices	Team chat and collaboration; calls and files rely on integrations
Deployment model	Kubernetes with Helmfile and Helm, inside your own cloud or data center	Synapse on your servers, usually PostgreSQL and Redis for scale	Self-hosted server, with Team Edition aimed at teams under 250 users
Core licensing	Apache-2.0 for deployment; each bundled component keeps its own license (AGPL-3.0, GPL-3.0, MPL-2.0)	Synapse under AGPL-3.0, with commercial exceptions from Element	AGPL v3.0 for source, Apache 2.0 for admin tools, or a commercial license
Production support path	ZenDiS recommends openDesk Enterprise Edition for production, with SLA-backed support	Element Server Suite editions, including paid Pro and Sovereign options	Paid Professional, Enterprise and Enterprise Advanced plans for SSO and compliance
Single sign-on	Nubus identity and portal, with federation to an external identity provider	OIDC, SAML2 and CAS in Synapse configuration	Paid editions add SSO and AD/LDAP sync; confirm for your edition
Infrastructure prerequisites	Kubernetes 1.33 or later, ingress, cert-manager, and external PostgreSQL, MariaDB, Redis and object storage	PostgreSQL 14 or newer for recent Synapse, plus Redis when running workers	Standard server and database, with clustering and high availability in paid editions
Main gap to confirm	Enterprise-only features such as Element AdminBot and GroupSync are needed for some operating models	Calls depend on a separately operated video backend; confirm your scale targets	Free tiers cap history at 10,000 messages in Entry and lack compliance export
Operational burden	Highest: a full suite with many services to patch, back up and upgrade	Moderate to high: federation, workers and schema upgrades need planned change control	Lowest of the three for a chat-only deployment

Where Microsoft's EU Data Boundary stops short of operational control

The EU Data Boundary answers where data is stored and processed, but it does not answer who operates the platform or which law can compel access to it. Microsoft's commitment keeps customer data for in-scope services within the EU and EFTA, which addresses one part of a sovereignty requirement. The remaining questions are operational: who has administrative access to the cloud control plane, where support staff are located, and whether Microsoft's obligations under third-country law could require disclosure of data it holds, wherever that data sits. Those are questions for the written contract and the support model, not for the marketing description of the boundary.

EDPB Guidelines 05/2021, in Example 12, address this exposure directly. Using an EU processor that is subject to third-country law with extraterritorial effect is not in itself a transfer, but complying with a third-country authority's request would be one, so the controller should assess that exposure before engaging the processor. Read the EDPB Guidelines 05/2021 with your data protection officer and ask Microsoft in writing which in-scope services, support channels and telemetry fall inside the boundary, which entities can access data in the clear, and how government access requests are reviewed and notified.

A fully self-hosted stack moves those answers into your own change records. With openDesk, for example, the operator runs the Kubernetes cluster, holds the keys and decides which administrators and vendors have access, so the remaining exposure is the one your organization chooses to accept. That does not remove obligations, since patching, backup and access review then become your responsibilities, and any commercial support contract still needs its own access terms. Record the decision with the legal basis, the list of parties with access and the review date, and confirm each vendor's support access in writing before you compare costs.

Choosing a deployment path by team size and operating model

openDesk is a full workplace suite, so its footprint is the largest of the three paths. It is deployed with Helmfile and Helm onto a CNCF-certified Kubernetes cluster at v1.33 or later, with an ingress controller, cert-manager and an RWO volume provisioner. The evaluation minimum is 12 x64 CPU cores, 32 GB of RAM and more than 10 GB of disk, with ARM not yet supported. Production expects external services that you operate or buy separately, including PostgreSQL 15, MariaDB 10, Redis 7, Memcached, Cassandra, an SMTP relay, ClamAV over ICAP, object storage and a TURN server.

Evaluation hardware: the 12-core, 32 GB minimum is for a trial, not for the user population you plan to serve.
Production services: each external database, cache and relay is a separate component with its own backup, patching and failover.
Upgrades: only the latest minor version is supported, and skipping minor versions may require intermediate steps.
Enterprise Edition: ZenDiS recommends it for production, and it adds SLA-backed support and patches, sold as SaaS or for on-premises installation.
Staffing: plan for people who already run Kubernetes, Helm and the database services, not only for chat administrators.

Confirm with ZenDiS or your integrator which cluster distribution, storage classes and external services your environment will supply before you size the team.

How to deploy and operate the stack under the constraint

The sequence moves from a signed legal position and a fixed hosting location to a running openDesk instance with external identity, controlled federation, a documented upgrade cadence and tested recovery. Each step ends with a check that the previous one held.

Confirm the legal assessment and hosting location
Before any installation, the data protection officer, legal counsel and the security lead agree in writing which data categories will be processed, where the servers and backups will physically sit, and which operators or support staff can reach the systems from outside the EU or EEA. The assessment should address the transfer questions raised by EDPB Guidelines 05/2021, including remote access from a third country, and the third-country access exposure discussed in the same guidelines. The output is a signed hosting and access decision that the deployment design must follow. Ask your legal team to confirm the conclusions with your own supervisory authority guidance, since DeployOpen prepares evidence but does not give legal opinions.
Provision a conformant Kubernetes cluster
The platform team builds a CNCF-certified Kubernetes cluster at v1.33 or later inside the approved location, with an ingress controller (haproxy-ingress, since Ingress nginx is deprecated), cert-manager, a provisioner for RWO volumes, Helm 3.17.3 or later below v4, and Helmfile 1.0.0 or later. Openshift is not a tested target, so plan for a kubespray-style cluster or another conformant distribution and confirm that choice with ZenDiS documentation. Production also needs external PostgreSQL 15, MariaDB 10, Redis 7, Memcached, Cassandra, an SMTP relay, ClamAV over ICAP, object storage and a TURN server, all provisioned in the same boundary. The check that closes this step is a cluster that passes version and tooling checks and reaches each external service from inside the cluster.
Install openDesk with Helmfile
The deployment engineers clone the openDesk deployment repository, set the domain, storage classes and secrets for each bundled component, and run the Helmfile-based installation against the cluster. Evaluation sizing starts at 12 x64 cores, 32 GB of RAM and more than 10 GB of disk, but production should be sized from the expected user count and the external services above rather than from that minimum. Decide early whether the production build will use the Enterprise Edition, because ZenDiS recommends it for production and it adds closed-source modules, Enterprise-only features such as Element AdminBot and GroupSync, and SLA-backed support. The step is complete when every component reports healthy and the Element chat, Nextcloud and Jitsi endpoints answer over TLS on the internal test name.
Connect an external identity provider
Identity is connected to the organization's own directory rather than to local accounts that drift. Follow the openDesk federation guidance to link the external IdP, then confirm that the Nubus portal and IAM issue the expected roles to a test group. For the Matrix side, map the same identities through Synapse's oidc_providers, saml2_config or CAS settings, or through the Matrix Authentication Service upstream identity provider setup, so chat and file access share one login. Record which group maps to which openDesk role, because that mapping is the first thing auditors and the security team will ask for. The check is a successful login for a test user in each group and a denied login for a user outside them.
Configure federation and firewall the listener
Federation in Synapse lets users on other servers talk to your users, which is often unnecessary for a closed public body. Set the federation_domain_whitelist key in the Synapse configuration to the explicit list of partner domains, or to an empty list if no federation is needed, and add firewall rules that block the federation listener, which uses port 8448 by default, from unlisted networks. Confirm the server_name value before any user IDs are issued, because it fixes how users and rooms are identified and is difficult to change later. The check is a test from a non-whitelisted server that fails to join a room, and a firewall scan that shows the federation port closed to unapproved networks.
Set the upgrade cadence and staging path
The operations lead adopts the openDesk release cadence as the operating rule: major releases annually in Q3, minor releases monthly, and patches on demand, with only the latest minor version supported. Keep a staging cluster that receives each minor release first and runs the same identity and federation tests. Plan for in-place upgrades between majors not being guaranteed, and for skipping several minor versions needing intermediate steps, so do not let the production instance fall behind the supported window. For Synapse, check the upgrade notes before each change because rolling back can be difficult after schema changes, and because support for Python and PostgreSQL versions ends with upstream end of life. The check is a dated upgrade calendar signed off by the owner and a staging run recorded before each production change.
Plan backups and test recovery
Backups must cover every stateful service, not only the chat database. Inventory the PostgreSQL, MariaDB, Redis, object storage and configuration secrets used by the stack, then choose backup tooling that writes copies inside the same jurisdiction and keeps encryption keys separate from the copies. Run a restore into the staging cluster, confirm that chat history, file shares and logins work, and time the restore so the recovery objective is based on evidence. Repeat the restore test after each major upgrade. DeployOpen can plan, implement and document this in your infrastructure, and the retainers cover recurring tests, but the recovery targets must be set by your business owners. The step closes when a restore test passes and the results are filed with the change records.

Evidence auditors and data protection officers ask for

Auditors and data protection officers judge a self-hosted stack by the records it can produce, not by its architecture alone. The six items below connect the technical deployment to the transfer analysis, contracts and operating history that an assessment will request. DeployOpen prepares this evidence inside your environment, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations.

Data flow maps

A data flow map shows where chat messages, uploaded files, call metadata and identity records are created, stored, replicated and backed up across the openDesk components or Matrix services. For each hop, record the hosting location, the operator and the network path. Check whether any logging, monitoring, mail relay or ClamAV scanning step sends content to a service outside your own boundary, because those hops are often missed in the first draft.

Transfer register entries

Record every transfer to a third country, including remote administrative access from outside the EEA and any cloud storage located abroad. Under GDPR Article 44, onward transfers also count. Where the answer is no transfer, document the reasoning so the file shows the analysis was done. Each entry should name the data category, the recipient, the legal basis and the review date.

Processor contracts and sub-processor lists

Obtain the signed data processing agreement from every supplier in the chain, including any hosting provider, managed Kubernetes service, SMTP relay or object storage vendor. Ask for the current sub-processor list and the notice period for changes. If you buy openDesk Enterprise Edition or a Matrix commercial license, the support and patch terms belong in this file too, because they define who can access your systems during an incident.

Access logs and admin role reviews

Keep records of who holds Kubernetes cluster access, Helmfile deployment rights and Synapse or openDesk administrator roles, along with periodic reviews that confirm each role is still needed. Export authentication and admin action logs to storage you control. Check how the external identity provider federation is configured, because a stale account in the upstream directory can keep access alive in the suite.

Upgrade and patch records

Maintain a dated log of every openDesk and Synapse upgrade, the version deployed, the test result and any rollback decision. openDesk supports only the latest minor version and does not guarantee in-place upgrades between majors, so auditors will ask how you stayed on a supported release. Synapse upgrade notes warn that rollback can be hard because of schema changes, so record the database backup taken before each step.

Supplier answers on third-country law

Ask each supplier in writing whether it or its parent company is subject to third-country laws with extraterritorial reach, such as the US CLOUD Act, and how it would respond to a government access request. Under EDPB guidance, using such an EU processor is not itself a transfer, but complying with a third-country request would be, so the written answer is central to your risk assessment. Keep the supplier's answer, its date and any follow-up questions with the transfer file.

How much effort and cost does a sovereign chat migration involve?

What drives the cost of a self-hosted sovereign chat migration?

The cost is driven by four components: the infrastructure you run, the people who operate it, the external implementation work, and the migration of existing history. Infrastructure is a mix of compute, storage and networking in your own cloud account or data center. For openDesk, the supplied evaluation minimum is 12 x64 CPU cores, 32 GB of RAM and more than 10 GB of disk, but production expects separate managed services such as PostgreSQL 15, MariaDB 10, Redis 7, an SMTP relay, ClamAV over ICAP, object storage and a TURN server, and each of these adds cost. Staff time is recurring, covering patching, backups and user support. One-time costs include design, integration with your identity provider, testing and data migration. Ask any quote to split these components so you can see which ones recur and which ones you can reduce by reusing existing platforms.

How long does a sovereign chat migration take?

No duration can be stated as a general rule, because the timeline depends on the number of users, the number of teams and channels, the size of the history you must move, and how many external systems must integrate. The openDesk requirements list a Kubernetes cluster at v1.33 or later, an ingress controller, cert-manager and Helmfile 1.0.0 or later as prerequisites, so platform readiness is often the first milestone. Your identity provider integration, the production services listed above, and your cutover approach add further phases. Ask for a written schedule that shows each phase, the dependencies on your own teams, and the point at which a pilot group moves. Fixed-scope engagements are agreed in writing before work starts, so the timeline should follow from that agreed scope.

What does our own team need to supply before a migration starts?

Your team supplies the decisions and access that no implementer can make for you. Expect to provide: a Kubernetes cluster or cloud account where the platform will run, network and DNS plans, certificates, an identity provider with single sign-on details, a named business owner for each team's channels, and a list of data retention rules. You should also confirm which Microsoft 365 data is in scope, because the Teams Export APIs in Microsoft Graph require admin-approved application permissions and an active Teams license on each user being exported. Agree early who approves those permissions, since that approval often gates the extraction work. A sign-off list from your security and compliance leads reduces rework later.

Can our internal team run a sovereign chat migration without an implementation partner?

Some organizations do this in-house, but the question is whether your team has the skills and capacity for the whole stack at once. The openDesk stack is a Helm and Helmfile deployment with many bundled components, each with its own license, such as AGPL-3.0 for Nextcloud and Nubus and GPL-3.0 for OpenProject. Running it also means owning Kubernetes operations, backups, upgrades and security hardening. Matrix with Element adds a Synapse homeserver that recommends PostgreSQL for production and is harder to roll back after database schema changes. Be realistic about skills before choosing. If you do use a partner, DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted platforms in your infrastructure under a written, fixed scope, and offers retainers for ongoing support.

When do we need the openDesk Enterprise Edition instead of the open-source release?

ZenDiS recommends openDesk Enterprise Edition for production. It uses the same open-source core licenses but adds closed-source modules, an Enterprise-only registry and license file, and SLA-backed second and third level support and patches, sold as SaaS or for on-premises installation. Some features are only available in the Enterprise edition, including Element AdminBot, GroupSync, the Admin Console, Nextcloud Enterprise security patches and the Guard app, and OX S3 storage with advanced full-text search. Decide whether you need those features and whether you require contractual support levels. Ask the vendor to state in writing which components and patches are covered and how the license file is delivered into an air-gapped or restricted network.

How do EU Data Act switching rights affect migration planning?

The Data Act, applicable since 12 September 2025, gives customers the right to switch from a data processing service to another provider or to on-premises ICT infrastructure. Under the supplied terms, the notice period can be at most two months and the transition period is 30 days, and switching charges are banned from 12 January 2027 (Articles 25, 29 and 50 of Regulation (EU) 2023/2854). For planning, this means your contract with a current provider cannot lawfully hold you past these limits for the switch itself. Check your contract's notice clauses now, record the date you give notice, and make sure your target stack is ready within the 30-day transition window. Confirm the exact obligations with your legal counsel, since the Data Act's application to your specific contract is a legal question.

What to confirm with your legal team and vendors before you commit

Start with the open legal questions that could change the transfer analysis. The Latombe appeal, Case C-703/25 P, is pending against the General Court's September 2025 judgment that upheld Commission Implementing Decision (EU) 2023/1795. Ask counsel how the outcome would affect any Microsoft service that relies on EU-US data transfers, and which fallback position applies if the decision is set aside. Ask them also to confirm the current Microsoft contract terms that govern your tenant, including the Data Protection Addendum, the EU Data Boundary commitments and the customer-managed key options, because those terms and product scopes change over time and may not match the sales deck. Keep a written record of the version you reviewed. Next, decide whether each shortlisted supplier is subject to third-country law with extraterritorial reach. The CLOUD Act provision at 18 U.S.C. 2713 applies to providers in possession, custody or control of data, wherever it is stored. Under EDPB Guidelines 05/2021, support access from a third country is itself a transfer, so ask vendors whether any support engineers, subprocessors or telemetry pipelines sit outside the EEA. Ask which Synapse, openDesk and Element services would be engaged, and who signs the support contract, since an EU-incorporated entity under foreign control can still face foreign disclosure orders. Finally, verify the technical capabilities in your own environment rather than relying on feature lists. For openDesk, confirm the Kubernetes version, ingress controller, external PostgreSQL 15, MariaDB 10, Redis 7 and ClamAV services, and whether your public body needs the Enterprise Edition for support and patches. For Synapse, test oidc_providers or saml2_config against your identity provider, confirm federation_domain_whitelist and firewall rules for the federation listener, and check that backups support the rollback limits described in the upgrade notes. Record each result as evidence for your assessment.

How DeployOpen works on this

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including cloud accounts, data centers or air-gapped networks. For a sovereign chat and meeting stack, that means the written scope fixes where every component runs and who operates it before any build work starts.

How we scope

The written scope names the chat, meeting and file components, and which of them run in your own infrastructure.
We record the hosting location, operator access and data flows that the sovereignty requirement depends on.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

We deploy the chosen stack, such as openDesk or a Matrix and Element setup, on the Kubernetes or server platform you operate.
We configure single sign-on, federation settings and external services like SMTP, object storage and TURN as agreed.
We test the deployment against the scoped requirements and document the configuration for your own administrators.

How we hand over

You receive runbooks, configuration records and evidence that controls described in the scope are in place.
We document the upgrade path, including how to move between minor and major releases of the platform you chose.
We prepare material for your compliance assessment, while independent auditors and certification bodies issue any formal opinion.

How we support

Ongoing support, upgrades, backups and continuous testing are available as retainers after handover.
Retainers can cover patch cycles for the platform components and for the database and cache services they depend on.
Ask for the support boundaries, response arrangements and upgrade responsibilities to be written into the quote.

Self-hosted Microsoft Teams alternative for EU digital sovereignty