Video conferencing for EU data sovereignty

Why self-hosted video conferencing for EU data sovereignty starts with transfers

An EU organization that wants meetings off US-operated SaaS gets sovereignty only when every data path stays under its control. Self-hosted Jitsi Meet or BigBlueButton keeps media and recordings in infrastructure the organization runs, but only if the media relays, TURN servers, recording storage and any transcription backend also sit in the EU. The video codec is not the issue. The issue is where each path runs and who can reach it. A TURN relay hosted in a third country carries the media of an EU call, and a transcription service that sends audio to an external API moves personal data just as a cloud recording bucket does. Map each path before choosing a platform: signaling, media, relay, recording, transcript, chat logs and support access.

Support access deserves particular attention. EDPB Guidelines 05/2021 state that remote access from a third country counts as a transfer, even when the person only views data on a screen for support or administration. A vendor engineer in a third country who troubleshoots a live bridge or opens a recording is therefore a transfer under Chapter V of the GDPR. Ask any partner or hosting provider where their administrators sit, which accounts can reach production, and whether support sessions are logged. Put those answers in the contract and the architecture document before go-live.

For the platform choice, Jitsi Meet fits ad hoc and embedded meetings, where users join from a browser, a web page or an intranet link and recording is a secondary need. BigBlueButton fits structured sessions that need recording, polling, a multi-user whiteboard and breakout rooms, and it needs more server capacity per session. Confirm the feature set and deployment requirements against the current documentation before you commit, since both projects change between releases.

Which GDPR and sovereignty requirements shape the build

This table maps each GDPR and sovereignty requirement to what it means for TURN placement, recording storage, support access and provider selection. Read each row as a design constraint to settle before choosing a platform, and confirm the legal reading with counsel or your data protection officer. The main takeaway is that where media, logs and recordings sit, and who can reach them, matters as much as the software license.

Requirement	What it means for the build	Where it usually fails
GDPR Article 44: transfers, including onward transfers	Every transfer of personal data to a third country must meet Chapter V conditions. Map where media relays, TURN, logs, recordings and backups physically sit, plus any sub-processors.	A hosted TURN relay or CDN outside the EEA is overlooked because the meeting server itself is in the EU.
GDPR Article 83(5)(c): fine level	Infringements of Articles 44 to 49 can reach EUR 20 million or 4% of worldwide annual turnover, whichever is higher. This sets the level of diligence expected for transfer decisions.	Teams treat transfer mapping as a one-off legal task rather than a standing design control.
EDPB Guidelines 05/2021: remote access and storage	Remote access from a third country, even only displaying data for support, and cloud storage outside the EEA are transfers. Restrict vendor and administrator access paths and storage locations.	Vendor engineers troubleshoot from outside the EEA, or recordings are synced to a foreign backup bucket.
Schrems II and Data Privacy Framework status	Privacy Shield was invalidated, while standard contractual clauses remained valid. The DPF adequacy decision applies only to US organizations on the DPF List, and an appeal in Case C-703/25 P is pending. Treat DPF reliance as a legal risk to monitor, not a settled basis.	A US-owned SaaS or support contract is assumed compliant because it cites the DPF without a transfer assessment.
CLOUD Act reach under 18 U.S.C. 2713	US providers must preserve or disclose data in their possession, custody or control, wherever it is stored. Check the legal control of the provider, not only the data location.	An EU-hosted service run by a US parent company is treated as outside US reach.
GDPR Article 48: foreign disclosure orders	A third-country order to disclose personal data is recognized only under an international agreement such as a mutual legal assistance treaty. Ask providers how they respond to foreign requests and whether they notify you.	Provider contracts promise notice of requests but have no defined process for handling conflicting foreign orders.
EDPB Recommendations 01/2020: supplementary measures	Where a provider needs data in the clear and foreign public authority powers exceed what is necessary and proportionate, the EDPB cannot envision an effective technical supplementary measure. Favor designs where the operator holds keys and data stays under your control.	Encryption is claimed as a fix while the provider still holds the decryption path or the media server is operated remotely.
EU Data Act Article 32 and switching rights	Providers must prevent third-country governmental access to non-personal data held in the Union where it conflicts with EU or national law. Customers can switch to on-premises infrastructure, with switching charges banned from 12 January 2027. Use these terms to set exit and portability clauses.	Contracts omit exit assistance, so moving recordings and user data back in-house becomes a costly project.

Where meeting media, TURN relays and recordings actually go

Media flows through the servers you deploy, so the sovereignty question is where those servers and their relays sit. In a self-hosted Jitsi Meet deployment, a web server (nginx or Apache) serves the web app, Prosody handles XMPP signaling, Jicofo assigns conferences to videobridges, and one or more Jitsi Videobridge instances route the audio and video streams. Jibri, which is optional, records or streams a meeting by joining it as a participant. Every one of these components should run in EU infrastructure you control. BigBlueButton works the same way in principle: one server carries signaling, media, the presentation pipeline and recording. The installation guide asks for at least 16 GB of RAM with swap, 8 CPU cores with high single-thread performance and 250 Mbit/s symmetrical bandwidth, and it requires TCP 80 and 443 plus UDP 16384 to 32768 to be reachable. Confirm that every host in that path, including any load balancer, is in a location your data processing records allow.

A TURN relay or public STUN service outside the EU can move personal data across a border even when your own servers are in Frankfurt or Paris. When a participant sits behind a restrictive firewall, traffic may be relayed through a TURN server. The BigBlueButton install documentation recommends TURN for such users. If that relay is a public or vendor-hosted service in a third country, media packets from your meeting pass through it, and EDPB Guidelines 05/2021 treat such processing as a potential transfer that needs a Chapter V basis. Public STUN lookups can also reveal participant IP addresses to a third party. Ask your partner to deploy TURN on your own EU hosts, list every STUN and TURN address in the client configuration, and check that none point to services you have not contracted. Jitsi also needs a valid domain certificate for working audio and video, so a self-signed certificate on an internal name is a practical blocker, not only a warning.

Recording storage sizing and location are decisions you must confirm in writing before go-live. The BigBlueButton install guide lists 500 GB of disk for a server that keeps recordings, against 50 GB without recording, so recording roughly multiplies the storage requirement by a factor of ten on that baseline. Actual growth depends on meeting length, the number of recorded sessions and the retention period your policy sets. Confirm with your partner where recordings land (local disk, a network volume, or object storage), whether that storage is replicated, who can access it, and how deletion works when a retention period ends. Jibri recordings follow their own storage path, so the same questions apply. Recordings are personal data when participants are identifiable, and the storage location is a transfer question in its own right.

Jitsi Meet or BigBlueButton: which fits an EU sovereignty brief

For an EU sovereignty brief, the deciding questions are where media servers, TURN relays, recordings and login data sit, and who can compel access to them. Both Jitsi Meet and BigBlueButton can run entirely inside infrastructure you control, but they differ in licensing, authentication and fit for classes versus open meetings. The cards below cover each option and the adjacent choices to confirm.

Jitsi Meet for open meetings

Jitsi Meet is licensed under Apache-2.0 and deploys as a web server, Prosody XMPP server, Jicofo and one or more Jitsi Videobridge media routers. The official Docker setup runs these as separate containers, and since stable-11146 they run rootless with read-only filesystems. For authentication, JWT tokens are the recommended route because the handbook deprecates the older secure domain method, and LDAP and Matrix verification are also documented. Check that the handbook's HTTPS requirement can be met with a certificate from your own CA. Jitsi is a trademark of 8x8, Inc. JaaS is 8x8's hosted service, so it does not meet a self-hosted sovereignty goal.

Jitsi horizontal videobridge scaling

Jitsi scales by adding Jitsi Videobridge instances, and the default install is already set up for horizontal scaling. The scalable setup guide suggests a 4 CPU, 8 GB machine for the central server and 4 or 8 CPU with 8 GB RAM for each videobridge. Media ports, including 10000/UDP, must be reachable on every bridge, so firewall and NAT planning comes before capacity. Ask your implementer how bridges are added, drained and monitored during a peak, and how recording is handled, since Jibri records one meeting per instance.

BigBlueButton for virtual classrooms

BigBlueButton is licensed under LGPL-3.0 and covers audio, video, annotated slides, polling, a multi-user whiteboard, shared notes and breakout rooms. It is embedded in major learning management systems, which makes it the stronger choice when lessons, grades and attendance live in an LMS. Version 4.0.0 installs on Ubuntu 24.04 and does not support direct upgrades from 2.6, 2.7 or 3.0, so plan a clean server build and a data migration. Confirm the sizing requirements early: 16 GB RAM with swap, 8 high-performance CPU cores, and 500 GB of disk if recording is enabled.

Greenlight OpenID Connect sign-in

Greenlight v3, the BigBlueButton front end, supports external authentication through OpenID Connect configured with environment variables. The docs suggest Keycloak to add other login methods such as SAML, which lets you keep identity inside your directory. Confirm that the identity provider sits in the same jurisdiction as the meeting servers. Also confirm how guest access and room moderators are assigned, since these settings decide who can join a session with a link alone.

API checksum and shared secret rules

Every BigBlueButton API call carries a checksum computed with a secret shared with the server. The default is SHA-256, SHA-1 is kept for legacy use, and SHA-384 or SHA-512 are available since version 2.5. The docs warn never to place the shared secret in a web page, so any custom integration with an LMS or intranet must compute checksums on the server side. Ask your partner to show where the secret is stored, how it is rotated, and which checksum algorithm each integration uses.

Nextcloud Talk and Matrix options

If your organization already runs Nextcloud or a Matrix homeserver such as Synapse, both can host calls as adjacent choices to Jitsi and BigBlueButton. Nextcloud Server is licensed under AGPL-3.0, and Synapse is licensed under AGPL-3.0. Confirm which call features, participant limits and TURN requirements each one supports at your expected meeting size, and whether it fits the rest of your collaboration stack. Treat these as options to evaluate against your requirements, not as drop-in replacements for a virtual classroom.

Deployment patterns for EU-only media, TURN and recording

Six patterns cover where media, relay servers, recordings, transcription, identity and capacity sit when meetings must stay under EU control. Each pattern names the integration point and the question to put to your hosting provider before the design is fixed, because a single US-operated dependency in any one of them can move data outside the EU.

EU data center with on-premises TURN

Place the Jitsi Meet or BigBlueButton media servers in an EU facility you contract directly, and run the TURN relay on hosts you control so participants behind restrictive firewalls do not route media through a public relay outside the EEA. Jitsi needs ports 443/TCP and 10000/UDP open, with 5349/TCP as TCP fallback, and BigBlueButton needs UDP 16384 to 32768. Confirm with the hosting provider which regions, backup sites and support staff can reach the servers, since remote administration from a third country counts as a transfer under EDPB guidance.

Dedicated recording storage with retention

Write recordings to a storage volume that sits only in your EU environment and is separate from general server disks, with a retention period set in policy and enforced by a scheduled deletion job. BigBlueButton 4.0 asks for 500 GB of disk for recordings, or 50 GB without recording, so size the volume before go-live. Confirm with the provider that backups of this volume are also held in the EU and that deletion propagates to replicas. Recordings containing personal data need a lawful basis, notice to participants and a documented erasure process.

Transcription backend on your own hosts

Run speech-to-text on GPU or CPU hosts inside your network so audio captured from meetings is never sent to a commercial transcription API. The integration point is the recording or caption pipeline, which must call an internal endpoint and never an outbound one. Confirm with the vendor of the speech model that its weights can be used offline and that no telemetry or model updates reach third-country servers. Plan for the extra capacity this consumes, because transcription competes with media processing on the same hardware.

Identity federation with your directory

Connect Jitsi authentication to your own directory so room creation and moderator roles follow staff records, using JWT tokens or LDAP as described in the Docker guide, and avoid the deprecated secure domain method for new installations. BigBlueButton Greenlight v3 accepts OpenID Connect, and the docs suggest Keycloak as a broker for SAML or other sign-in methods. Confirm that the identity provider, its logs and its administrators are also located and operated under your EU control, because an external IdP sitting outside the EU would move personal data with every login.

Horizontal videobridge pools

Add Jitsi Videobridge nodes in the same EU sites as the central server, so media capacity grows without moving any session to a cloud burst pool outside your control. The Jitsi scalable guide notes the default install is already configured for horizontal scaling, and suggests 4 or 8 CPUs with 8 GB RAM per bridge. For BigBlueButton, pool servers behind Scalelite. Confirm with the provider that every node in the pool, including any temporary capacity, is in an approved EU location and covered by the same processing terms.

Hosting contract and access controls

Write the sovereignty requirements into the hosting agreement: named EU locations for compute, storage, backups and logs, a list of sub-processors with their locations, and a commitment to refuse or challenge third-country disclosure requests. Ask how the provider handles a US CLOUD Act demand for data in its possession, custody or control, because that statute applies regardless of where the data sits. Confirm administrator access is restricted to EU-based staff and that remote sessions are logged for audit.

Rollout from transfer mapping to a tested EU-only meeting service

This sequence moves a meeting service from an inventory of where data flows today to a piloted, documented deployment in which media, recordings, transcripts and support access stay within the EU and the records of processing reflect what was built. Each phase ends with a named output that a DPO, security lead or auditor can review.

Map transfers and processors
Start by inventorying every flow the current meeting tools create: media relay, TURN traffic, recordings, chat, calendar integrations, telemetry, support access and any sub-processor that can view data in the clear. Privacy and legal owners review the inventory against the transfer rules in Chapter V of the GDPR, including remote access from a third country, which counts as a transfer even when data is only displayed. The output is a transfer inventory with each flow marked as stays in the EEA, transfer with a documented mechanism, or removed. Confirm with each vendor where support staff sit and whether any third-country law could compel access.
Select platform and hosting location
Choose between Jitsi Meet and BigBlueButton based on the meeting types in the inventory, such as ad hoc calls, large classes or LMS-linked sessions, and confirm that the chosen hosting provider, data centers and backup locations are in the EU. Record the decision, the rejected options and the reasons in an architecture decision record. Ask the hosting provider in writing where administrators and support engineers connect from, because remote administration from outside the EEA is itself a transfer that the record must address.
Build and harden the core services
Deploy the web, signaling and media components on EU infrastructure with a valid domain certificate, since the Jitsi handbook states that working audio and video depends on HTTPS with a proper certificate. Configure authentication, disable anonymous creation of rooms where policy requires it, and separate guest access from staff access. Restrict administrative access to named accounts and log it. The output is a hardened build sheet and a configuration baseline stored under version control.
Configure TURN, recording and transcription in the EU
Place TURN relays in the EU so that media for users behind restrictive firewalls does not detour through a third country, and confirm which public STUN or TURN services the client software contacts by default. Set recording storage to EU locations with retention and deletion rules defined before the first recording. If transcription is needed, run the speech model on your own servers rather than sending audio to an external API. The output is a data-flow diagram showing every media and storage path with its location.
Test with external and mobile clients
Test the service with guests on unmanaged networks, mobile browsers and native apps, and users behind corporate firewalls, since these paths determine whether TURN is actually used and whether certificates are accepted. Verify in network captures that no media or signaling reaches endpoints outside the approved locations. Include a negative test that tries to join a room from a guest domain and confirm the lobby and authentication rules hold. The output is a test report listing each scenario, the observed route and the pass or fail result.
Document GDPR records
Update the records of processing activities for each meeting purpose, including categories of participants, recording and transcript data, retention periods, recipients, the hosting location and any transfer safeguards. Confirm that data processing agreements with the hosting partner and any support vendor match the inventory from the first step. Obtain legal sign-off for the transfer position of each remaining flow. The output is a records of processing entry per purpose and a signed-off list of open legal questions.
Pilot with a limited group
Run a pilot with a defined set of internal teams and a small number of external guests for a fixed period agreed in advance. Collect feedback on join reliability, audio quality, recording behavior and guest onboarding, and check logs and monitoring for unexpected connections. Fix configuration issues and re-run the affected tests from the previous step. The output is a pilot report with issues, fixes and a go or no-go decision recorded by the service owner.
Operate and review on a schedule
Move the service to operations with named owners for patching, certificate renewal, capacity and access reviews. Re-run the transfer inventory whenever a feature, sub-processor, support model or hosting location changes, and repeat the network checks after each upgrade. Keep the evidence from every earlier phase in one controlled repository so it can be shown to auditors or a supervisory authority. The output is an operations runbook and a change log that links each change to the updated records of processing.

Evidence a DPO or auditor will ask for and which component produces it

This table maps the evidence a data protection officer or external assessor typically requests to the Jitsi or BigBlueButton component or configuration that produces it. Read each row as a question to answer with a document, a setting or a log export. DeployOpen prepares this evidence, but auditors and certification bodies are the ones who assess it.

Evidence item	What it shows	Component or setting that produces it
Records of processing	Purposes, categories of data, recipients and retention for meetings and recordings	Your own register, populated from the deployment inventory of Jitsi or BigBlueButton services and their hosting locations
Transfer inventory	Every place media, recordings or metadata leave the EEA, including support access	Infrastructure inventory per server, plus provider and support access records; confirm no third-country relay is configured
Data location statement	Where media servers, TURN relays, recordings and transcripts are physically stored	Server and storage inventory for the Jitsi videobridges or BigBlueButton hosts, TURN servers and recording volumes
Provider assessment of third-country law exposure	Whether any hosting or support provider is subject to third-country access powers	Documented assessment by the controller covering the hosting provider, managed services and support contracts; not produced by the platform
Recording retention settings	How long recordings are kept and when they are deleted	BigBlueButton recording retention configuration and storage cleanup jobs; Jibri output directory policy for Jitsi
Access logs	Who joined, administered or downloaded recordings and when	Prosody and Jicofo logs for Jitsi; BigBlueButton server logs and Greenlight or LTI user records
TURN configuration	Which relay handles traffic for users behind restrictive firewalls and that it runs in the EU	TURN server settings and firewall rules; confirm relay host location and that credentials are time limited
Certificate records	Valid certificates for the meeting domain, issuer and expiry dates	Web server TLS configuration for Jitsi web or BigBlueButton SSL hostname, plus the certificate inventory
API checksum configuration	Proof that API calls are signed with a server-held secret and that the secret is not exposed	BigBlueButton API secret and checksum algorithm settings; for Jitsi, JWT signing key and token configuration

What EU organizations ask before self-hosting meetings

What does self-hosting Jitsi or BigBlueButton cost, and what drives it?

Cost comes from four places: the servers and bandwidth that carry media, the TURN relay capacity for users behind firewalls, the storage that holds recordings, and the people who run the platform. Most of the spend is recurring (cloud or data center capacity, bandwidth, storage growth and support hours), with a smaller one-time portion for design, installation and integration. The biggest driver is peak concurrency, meaning how many meetings and participants run at once. The BigBlueButton install docs list a 4.0 server at a minimum of 16 GB RAM with swap, 8 CPU cores with high single-thread performance, 500 GB of disk for recordings (50 GB without recording) and 250 Mbit/s symmetrical bandwidth. Jitsi's scalable setup guide suggests a 4 CPU, 8 GB machine for the central server and 4 or 8 CPU with 8 GB RAM per videobridge. Ask any partner for a quote that shows sizing per peak load, recording retention and TURN capacity as separate lines.

How long does a self-hosted video conferencing rollout take?

The timeline depends on scope, which is agreed in writing before work starts, so no fixed duration applies to every organization. The main variables are the number of environments (test and production), the identity integration, whether recording and transcription are included, the certificate and DNS work, and the firewall changes that your network team must approve. Fixed-scope engagements list deliverables and milestones in the statement of work, so ask the partner to break the timeline into design, build, integration, load testing and cutover. Confirm in scope whether the plan includes a load test at expected peak concurrency and a rehearsal before any live meeting depends on the system.

What must our team provide before a self-hosted meeting platform can go live?

Your team usually supplies four inputs. First, a directory or identity source, such as LDAP, OpenID Connect or a JWT signing process, so users can sign in without shared accounts. Second, a domain you control, with DNS records that point to the media servers. Third, a valid certificate for that domain, because the Jitsi handbook states that HTTPS with a proper domain certificate is necessary for working audio and video and warns that self-signed certificates cause problems, especially on mobile. Fourth, input from your data protection officer on lawful basis, retention periods for recordings, guest access rules and the transfer assessment. Network and firewall owners also need to open the ports the platform requires, so put them in the design review early.

Can our IT team run Jitsi or BigBlueButton without an outside partner?

Yes, a capable internal team can install and run either platform, since both are open source and both publish installation and operations documentation. The work that tends to stall internal teams is ongoing: applying security updates, testing upgrades before classes or meetings depend on the system, tuning bandwidth and TURN, monitoring capacity and handling incidents at odd hours. Some organizations keep operations in-house and buy a fixed-scope design, hardening and handover from a partner. DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted platforms in your own infrastructure, and ongoing support is available as a retainer. Decide which parts you will own, and write that split into the scope before work begins.

Does a US-owned hosting provider create a problem under the CLOUD Act and GDPR Article 48?

It can, and the answer depends on what the provider can reach, not only on where the servers sit. The 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, whether it is inside or outside the United States. GDPR Article 48 allows a third-country court or administrative order requiring disclosure to be recognized or enforced only if it rests on an international agreement, such as a mutual legal assistance treaty. Under the EDPB Guidelines 05/2021, remote access from a third country, even only displaying data on a screen, counts as a transfer, so support access matters too. Ask the provider to show which entities hold keys, who can access logs and media, and how they respond to foreign requests, then document the transfer assessment with your DPO.

How do Data Act switching rights apply to our hosting contract?

Under Regulation (EU) 2023/2854, customers of a data processing service have the right to switch to another provider or to on-premises ICT infrastructure, and that right has applied since 12 September 2025. The Data Act sets a maximum two-month notice period and a 30-day transition, and it bans switching charges from 12 January 2027 (Articles 25, 29 and 50). Check whether your hosting or managed service contract is a data processing service under the Act, because that determines which switching terms apply. Also check the export format for configurations, recordings and user data, and confirm that your contract names the transition assistance you need. Have your legal team confirm how these articles apply to your specific arrangement.

Which records and recordings does GDPR require us to manage?

Recordings that contain personal data are processing activities, so they need a documented purpose, a lawful basis, a retention period, access controls and a deletion route. Record the processing in your records of processing activities, set a retention period for each meeting type, and make sure participants receive notice before recording starts. Where recordings or transcripts are stored or processed outside the EEA, including by a hosting provider's support staff, Chapter V transfer rules apply, and infringements of Articles 44 to 49 can reach EUR 20 million or 4% of worldwide annual turnover under Article 83(5)(c). Ask your partner how recordings land on disk, how they are encrypted and how deletion is verified.

Is end-to-end encryption available for self-hosted meetings?

It depends on the platform and the client, so confirm it for your exact configuration before you commit. Transport encryption protects media between clients and servers, but it does not by itself stop the server from reading media, which matters for board, legal or patient calls. End-to-end encryption in Jitsi has its own browser support limits and disables some features such as server-side recording, so check the trade-offs before you promise it internally. For BigBlueButton, the API requires checksums signed with a shared secret, and the docs warn never to embed that secret in a web page, which is a basic control to verify in any design. Your partner should show a written test of the features you need under the chosen encryption setting.

Questions to put to an implementation partner before signing

Start with location. Ask the partner to name, for each component, the country and the operator of the machine where it runs: the TURN relay that carries media when clients sit behind restrictive firewalls, the Jitsi videobridges or BigBlueButton servers that route audio and video, the recording store, and any transcription backend. A TURN relay that sits in a third country still carries personal data, and the EDPB guidelines treat storage in a cloud outside the EEA as a transfer. Ask whether any component falls back to a public service, such as a public STUN server or a hosted transcription API, when a call misbehaves, and ask how that fallback is disabled and tested. Also confirm that the Jitsi Docker setup or BigBlueButton install on your chosen hosts is the only place recordings are written, and where the backup copies of those recordings go.

Next, ask who can reach the system and from where. Request a written list of every person and service account with root, database, container orchestration or hypervisor access, including the partner's own engineers, support staff and any managed monitoring tool. For each one, ask the partner to state the country of login, whether access is through a bastion inside your network, and whether session logs are kept in the EU. Remote support that only displays personal data on a screen from a third country is still a transfer under the EDPB guidance, so this question covers screen sharing during troubleshooting as well as file access. Ask how the partner documents an access request from a foreign authority, and how it would notify you, since the assessment the EDPB describes depends on that answer.

Then ask how the partner documents transfers and third-country exposure, and how upgrades and certificate renewal happen without moving data. Ask for the transfer assessment in writing, the list of sub-processors with their locations, and the process for checking whether any of them is subject to third-country law with extraterritorial reach. For upgrades, ask whether packages, container images and TLS certificates are pulled from mirrors you control, and whether the partner can run updates from inside your environment. Confirm how certificate renewal is performed, because a publicly trusted certificate for the domain is needed for working audio and video. Finally, make the fixed scope define location and deletion: the written scope should state where each dataset lives, how long recordings and logs are kept, the deletion method and the evidence you receive when deletion is done. Confirm the exit path as well, since the Data Act gives you a right to move to another provider or on-premises infrastructure.

How DeployOpen scopes and supports EU-only video conferencing

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For EU-only video conferencing, that means Jitsi Meet or BigBlueButton running on infrastructure you control, with media relay, TURN, recording and transcription placed where your transfer analysis says they belong.

How we scope

Map where media, signaling, TURN relays, recordings and transcripts would be stored and processed.
Record which third-country access paths you need to rule out, and which EU hosting providers are in scope.
Agree deliverables, timelines and responsibilities in writing before any work starts, as a fixed-scope engagement.

How we build

Deploy the chosen platform in your environment, with TURN servers and recording storage hosted inside the EU.
Configure authentication, such as JWT tokens or LDAP, with a separate guest domain for external participants.
Test audio, video and firewall traversal, then document configuration and the data flows behind each setting.

How we hand over

Deliver runbooks for operations, upgrades, backups and recording deletion, with the configuration kept under version control.
Provide records of processing and transfer evidence that your privacy and legal teams can review with their counsel.
Train administrators on user onboarding, guest access, retention settings and incident steps for your team.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover.
Re-test the deployment after platform upgrades, certificate renewals and changes to TURN or recording locations.
Confirm with your auditors or certification bodies which evidence they accept, since DeployOpen does not issue attestations.