Self-hosted video conferencing: when owning the meeting platform makes sense
Organizations that need meetings and webinars where recordings, participant data and access logs stay under their own control should consider running the meeting platform themselves. Jitsi Meet suits ad hoc, meeting-style calls, while BigBlueButton suits structured webinars and LMS-linked classes. Both can run in the client's own cloud account, data center or air-gapped network, so the choice depends on how the sessions are used rather than on where the data must live.
Jitsi Meet is licensed under Apache-2.0, which allows broad internal use and modification without copyleft obligations on your own changes. BigBlueButton is licensed under LGPL-3.0, and its v4.0.0 release was published on October 14, 2026, according to the project's GitHub repository. The license difference matters less for most buyers than the operating model: both platforms need media servers, signaling, TURN relays for participants behind restrictive firewalls, storage for recordings and integrations with identity and learning systems. Regulated firms, public sector bodies, universities, and healthcare providers typically ask who can access a recording, where it is stored, and how long it is kept. A self-hosted deployment answers those questions in your own environment. DeployOpen plans, implements and supports the stack inside your infrastructure and prepares the configuration and evidence your assessors will ask for, but it does not issue audit reports or certifications. Those come from independent auditors and certification bodies.
Before committing, confirm three things with your own teams and the vendors. First, which sessions must stay internal and which need guest access from outside, because that drives TURN design and identity decisions. Second, how long recordings must be retained and who may review them, since storage and access controls follow from that answer. Third, whether a hosted service with contractual data residency and audit terms would meet the requirement at lower operating effort. If the answer is yes, a hosted option may be the better fit. If recordings, logs and participant data must remain in your control, self-hosting becomes the practical path.
What to agree before choosing Jitsi or BigBlueButton
Jitsi Meet and BigBlueButton solve different meeting problems, and the right choice depends on decisions made before any server is sized. The six requirements below set the participant counts, network paths, recording rules and integrations that drive the architecture. Agree them in writing with the business owners, then test them against a sample of real users.
Concurrent participants and meeting types
Start with the peak number of people in the largest meeting and the number of meetings running at the same time, not the total headcount. Separate small internal calls from all-hands sessions, because a few large rooms change the media server and bandwidth design far more than many small ones. Ask each department which meeting types it runs, how long they last and how many run in the busiest hour. Confirm the figures with a usage sample from your current tool before sizing anything.
Webinar versus meeting use
Decide whether you need open participation among peers, a presenter-led broadcast to a large audience, or both. Broadcast-style sessions usually need controlled roles, moderated Q&A and a clear way to watch without joining the media stream. Confirm whether external attendees need to join from a browser without an account, because that affects authentication, lobby handling and moderation settings. Also confirm whether webinars need registration, polling or attendance reports.
Recording and retention rules
Recording creates stored media that is subject to access control, retention and deletion, so decide who may record and who may download before the server is built. Set how long recordings are kept, where they are stored and who approves deletion. Ask legal and records owners whether recordings are business records under your own retention schedule. Check the storage growth from a pilot, because video grows much faster than text, and confirm whether recordings must be encrypted at rest.
Identity and single sign-on
Decide whether staff sign in through your identity provider, whether guests join anonymously and whether moderators need stronger authentication than attendees. Both platforms can be set up to limit who creates meetings, but the exact options depend on the version and the authentication method you choose, so confirm them against the current documentation. Map which groups may host, which may record and how departures are handled. Ask your identity team which protocols the provider supports for the integration.
Network locations of users
List where participants join from: head office, branches, home networks, mobile data and partner networks. Users behind strict corporate firewalls or symmetric NAT often need a TURN relay, and that relay carries real media traffic and its own bandwidth cost. Confirm which ports and protocols your firewalls allow, whether you can open UDP for media and whether mobile users will be routed through the relay. Test from each location before the rollout, since these paths determine call quality more than server size.
Integration needs with chat or LMS
Identify whether meetings must start from your chat tool, your learning management system or a calendar, and whether attendance or recordings must return to those systems. Each integration adds a service account, a token or secret to manage, and a version to test after upgrades. Ask the owners of each system for the exact actions they need, such as creating a room, joining from a link or reading attendance. Confirm each action with the vendor's integration documentation before committing to a design.
Jitsi Meet or BigBlueButton: which open-source platform fits
This table compares Jitsi Meet and BigBlueButton on fit for ad hoc meetings, scheduled webinars, LMS-centred teaching and mixed use, plus recording, integration and operating effort. Use it to shortlist a platform, then confirm each feature against the current project documentation and a test deployment before committing. The main takeaway is that the choice follows the meeting pattern more than the license.
| Criterion | Jitsi Meet | BigBlueButton |
|---|---|---|
| License | Apache-2.0 | LGPL-3.0; v4.0.0 published October 14, 2026 |
| Ad hoc meetings | Strong fit: quick browser-based rooms with minimal setup for participants | Workable, but heavier than needed for casual calls |
| Scheduled webinars | Possible with added configuration; confirm broadcast and attendee controls for your scale | Designed around presenter, viewer and moderator roles; confirm current webinar features |
| LMS-centred teaching | Usually reached through LTI or plugin integrations; confirm current support for your LMS | Commonly integrated with Moodle and other LMS platforms; confirm the connector version you need |
| Recording approach | Recording depends on a separate component; confirm the storage and processing design | Built-in recording with playback; confirm storage growth and retention settings |
| Integration model | Lightweight APIs and embedding; suits custom portals and chat tools | Richer API and LMS integration; suits institutions running a learning platform |
| Operating effort | Lower component count for basic use; still needs TURN and bandwidth planning | More components to run and patch; plan for capacity and upgrades |
| Mixed use | Good when most sessions are informal and a few need recording | Good when teaching and formal webinars dominate the workload |
| Confirm before choosing | Current recording, moderation and SSO options against the project documentation | Current scaling guidance, LMS connectors and hardware needs against the project documentation |
How the media server, TURN and recording components connect
In a self-managed deployment, the web front end, signaling service and media server (the videobridge in Jitsi Meet, or the BigBlueButton media services) run in your data center or private cloud account. Participants load the web client over HTTPS, the signaling channel carries session setup and room state, and the media server forwards audio and video streams. When a participant connects directly, media flows peer to media server over UDP where possible. Participants behind strict corporate firewalls or symmetric NAT often cannot open that path, so a TURN service on TCP or TLS port 443 becomes the fallback. Recording runs as a separate worker that captures the session and writes files to object or block storage, which then needs its own retention and access controls.
- Signaling and media separation: Confirm which ports and protocols the web, signaling and media tiers each expose, and whether they can sit behind the same load balancer.
- TURN placement: Decide whether TURN runs on the same network as the media server or on a separate host closer to users, and confirm how the client is told which relay to use.
- Recording pipeline: Identify the recorder service, its CPU and disk needs, and where finished files land before they are moved to long-term storage.
- Bandwidth and CPU sizing: Ask the vendor for their tested participant and stream counts per media node, then validate those numbers with a load test on your own hardware and network.
- Recording storage growth: Estimate retention periods with your compliance lead, since recording volume depends on meeting length and resolution settings.
Before approving this design, check that the vendor's reference numbers match your concurrency peaks and that TURN and recording both work from a test user on a restricted network.
On an air-gapped network, the entire chain runs inside an isolated segment with no route to the public internet. Client software, container images, updates and any external STUN or TURN dependencies must be mirrored in before deployment, because the servers cannot fetch them later. Signaling and media still need internal DNS names and certificates from an internal certificate authority, since public certificate issuance will not work. Because all participants sit on the same controlled network, TURN is usually needed only for clients on separate VLANs, VPN segments or behind an internal firewall. Recording stays inside the enclave, and its output must follow the same access rules as other sensitive data.
- Offline artifact pipeline: List every package, container image and model or library the platform pulls at runtime, and confirm each one can be transferred and verified offline.
- Internal name resolution and certificates: Plan internal DNS records and certificates for the web, signaling and TURN endpoints before installation.
- Network segmentation rules: Map which VLANs or VPN segments need TURN access and which ports must open between them.
- Recording and storage locality: Confirm where recordings are stored, who can retrieve them, and how they are backed up inside the enclave.
- Capacity testing without outside traffic: Run load tests inside the enclave, since results from a connected lab may not reflect constrained internal links.
Ask the vendor which features depend on external services, such as hosted telephony gateways or cloud speech tools, and confirm that each one has an offline alternative before purchase.
In a hybrid setup, the media server and recorder stay on your infrastructure, while an external TURN relay handles traffic for users who cannot reach the media server directly. The external relay is placed in a location that participants can reach, often a provider region or a separate edge host, and it forwards encrypted media to your media server over a path you control. Signaling still runs in your environment, so user identity and meeting metadata stay under your management. The relay adds a second network hop, which affects latency and consumes bandwidth you pay for, so the sizing question shifts from the media server alone to the relay path as well. Recordings are still written locally or to your storage, not to the relay.
- Relay ownership and data path: Confirm who operates the relay, where it runs, and whether media passes through it unencrypted at any point.
- Credentials and access control: Ask how short-lived TURN credentials are issued from your identity or signaling service, and how they are rotated.
- Egress bandwidth cost: Ask the relay provider how traffic is metered and billed, and model peak concurrency with them before committing.
- Latency and regional placement: Test round-trip time from the regions where your users sit to both the relay and the media server.
- Recording isolation: Verify that recordings never traverse the relay and that the recorder has no dependency on the external service.
Before signing with a relay provider, confirm the contractual data processing terms and whether the provider's logs can be disabled, since audit evidence for communications may depend on them.
Connecting SSO, chat and LMS to the meeting platform
A self-hosted meeting platform is only useful when people can sign in, join from the tools they already use and find recordings afterward. The cards below cover the integrations that most often decide whether a Jitsi Meet or BigBlueButton rollout works in practice, and what to confirm in the version you choose.
Single sign-on through your identity provider
Decide whether users sign in to the meeting platform through your identity provider using SAML or OpenID Connect, or whether guests join anonymously through links. Jitsi Meet supports token-based authentication and moderator roles that depend on how your JWT claims are issued, while BigBlueButton handles authentication through its API and any front-end portal you place in front of it. Confirm which protocol your chosen version and deployment method support, how group membership maps to moderator rights, and what happens to sessions when an account is disabled.
Chat platform links and meeting invitations
Most meetings start as a message in a chat tool, so the link format, room naming and access rules matter as much as the video itself. Decide whether room URLs are predictable, whether they can be generated by a bot or integration, and whether lobby or waiting-room controls apply to links posted in shared channels. Test the join flow from a mobile browser and from a desktop client, because chat previews and link unfurling can change how a link is opened.
LMS integration for classes and grades
Where the platform supports classes, scheduled sessions need to appear in the learning management system and attendance or participation needs to reach the gradebook. BigBlueButton is commonly connected to LMS platforms through LTI, which lets the LMS launch sessions with the user's role and context. Confirm which LTI version your BigBlueButton release supports, how the LMS passes instructor and student roles, and whether grade passback is available or whether grades must be entered by hand. Treat this as a scoped integration project, not a checkbox.
Calendar invitations and scheduling
Calendar invitations are the most common way to schedule recurring meetings and webinars. Confirm whether the platform can generate a stable meeting address per user or per room, how time zones and recurring series are represented in invitations, and whether your calendar system can send these links without manual copy and paste. Check that invitations do not expose internal room names or allow unauthorized users to join before a moderator arrives.
Recording storage and retrieval
Recordings are stored on the server or in an attached store, so capacity, retention and access must be planned from the start. Decide where files are kept, how long they remain available, who can download or delete them, and how they are backed up. If recordings may contain regulated content, your retention schedule and access logging must match the policies that apply to that content. Ask the implementation partner to show how a recording is located, retrieved and removed in your chosen version.
Monitoring and audit evidence
Operations teams need to know whether the media servers, TURN relays and recording workers are healthy during a live meeting, and compliance teams may need records of who accessed a session. Plan metrics for concurrent participants, bandwidth and failed joins, and decide where logs go and how long they are kept. Where the meeting platform holds protected health information, the HIPAA Security Rule requires audit controls that record and examine activity in systems containing that information, so logging scope should be agreed early.
How a self-hosted video rollout runs in phases
The sequence moves a video platform from a scoped design to a tested, documented service that your own operations team can run. Each phase closes with a written output that gates the next one.
Hold the requirements and sizing workshop
DeployOpen runs a working session with IT, security, and the business owners of meetings and webinars to capture concurrent participant counts, meeting size, webinar audience, recording needs, and the systems video must connect to. The team decides between Jitsi Meet and BigBlueButton based on whether the priority is ad hoc meetings or structured webinars with breakout rooms, recording, and LMS use. The output is a scoped design covering server and bandwidth sizing assumptions, TURN and network placement, identity and retention requirements, and the hosting location inside your own cloud, data center, or air-gapped network. The step closes when the sponsor signs off the design and the open questions have named owners.
Build and load test the proof of concept
The team deploys a non-production instance on the chosen platform in your environment and validates the network path. It tests TURN relay behavior for participants behind restrictive firewalls, measures media server load at the concurrency levels from the design, and checks audio and video quality from representative locations. Decisions made here include the number of media nodes, the TURN deployment model, and whether recording runs on the same host or a separate worker. The output is a load test report with measured results against the design assumptions and a list of changes to the sizing. The step closes when the design is confirmed or revised in writing.
Build production with SSO, recording, and backup
DeployOpen builds the production environment with the identity provider integration, certificates, monitoring, and the chosen recording storage path. The team configures authentication, room and moderator policies, and the integrations with chat or the LMS that the design requires. It also sets backup and restore for configuration and recording storage, and tests a restore before go-live. Decisions include who may create rooms, how long recordings are retained, and where encrypted recordings are stored. The output is a production system with a tested restore and a configuration baseline. The step closes when the security review of the build findings are resolved or accepted by the owner.
Run a pilot with a defined user group
A bounded group of users, such as one department or one training cohort, uses the production system for real meetings and webinars for an agreed period. The team collects feedback on join experience, audio quality, screen sharing, recording access, and sign-in behavior, and watches monitoring data for capacity and network issues. Decisions cover which fixes are made before rollout and which are documented as known limitations. The output is a pilot findings log with the agreed changes applied and retested. The step closes when the pilot owner confirms the service meets the criteria written in the design.
Complete the full rollout and runbook handover
The team extends access to the full user population in stages, monitors load and support requests at each stage, and adjusts capacity where needed. Before handover, DeployOpen delivers a runbook covering monitoring alerts, scaling steps, certificate renewal, TURN and media node maintenance, backup and restore procedures, upgrade steps, and escalation paths. Your operations staff walk through the runbook and perform a restore or failover exercise under supervision. The output is a documented service with named operators and a support model. The step closes when your team runs the exercise without assistance and accepts the handover in writing.
Build in-house, partner, or choose a hosted service
The first decision is who will run the stack after go-live. Build in-house means your own platform or network staff install, configure and operate Jitsi Meet or BigBlueButton, including the media servers, TURN relays, reverse proxy, certificates, database and storage for recordings. This keeps every control inside your organization: where media transits, where recordings sit, who can download them and when the servers are patched. The cost is mostly staff time, and it recurs. Someone must own on-call response for a meeting that fails at 9 a.m., track upstream security releases, and rehearse restores of the recording store. Confirm that your team has the Linux, WebRTC and network skills for these tasks before committing to this path. A partner build uses an implementation partner to design the deployment in your environment, install it, integrate it with your identity provider and chat or LMS, document the runbooks and hand over operations. The one-time work is architecture, hardening, integration and knowledge transfer, usually agreed as a fixed scope in writing. Recurring costs then depend on whether you keep patching and monitoring in-house or buy a retainer for upgrades, testing and support. Ask the partner who holds the administrator credentials at handover, which recording access roles are configured, and how patch windows for the media tier will be coordinated with your change process. A commercial hosted service moves operations, and most of the patching and media scaling, to the vendor. This often makes more sense for small teams with no data residency rule, no requirement to keep recordings under your own retention and access controls, and no need for deep LMS or SSO integration. Compare the vendor's contractual data location, recording storage and deletion terms, and subprocessor list against your obligations. Hosted pricing is usually per user or per host, so the cost grows with headcount, while a self-hosted deployment costs more up front and then depends on staff capacity and infrastructure.
Build, partner or hosted: control, effort and cost structure
This table compares running Jitsi Meet or BigBlueButton in-house, with an implementation partner, or on a commercial hosted video service. Read each row as a question to answer before committing: who holds the recordings and participant data, who upgrades and patches the stack, and which costs repeat each year. The main takeaway is that self-hosting shifts cost from per-user subscriptions to infrastructure and people, so the right choice depends on your scale and staffing.
| Dimension | In-house open source | Open source with a partner | Commercial hosted SaaS |
|---|---|---|---|
| Control over recordings | Full: recordings stay on storage you define, in your region and under your retention rules | Full, if the partner deploys into your accounts or data center and hands over admin rights | Shared: the vendor stores recordings in its environment; confirm regions, export and deletion terms |
| Control over participant data | Full over call metadata, logs and identity records | Full, subject to the partner's access model and written data handling terms | Depends on contract, sub-processors and vendor logging; request the data processing terms |
| Upgrade ownership | Your team tracks Jitsi or BigBlueButton releases and tests them before rollout | Partner plans and executes upgrades under the agreed support scope | Vendor applies upgrades on its schedule; you control timing only through contract terms |
| Operating effort | Ongoing staff time for TURN, certificates, media servers, monitoring and capacity | Lower internal staff time, with retainer or support hours for operations | Lowest internal effort for infrastructure; admin work shifts to tenant settings and access |
| Integration depth | Full access to APIs, SSO, LMS and chat hooks, built and maintained by your team | Full access, with integration built to a written scope and handed over | Depends on the vendor's connectors and plan tier; confirm LMS and SSO support before buying |
| One-time cost | Architecture, build, load testing and documentation, mostly internal labor | Fixed-scope design, deployment, integration and hardening, quoted from written scope | Typically onboarding and configuration; confirm any professional services fees |
| Recurring cost | Servers, bandwidth, storage, backup and internal staff time | Infrastructure plus support or retainer hours, plus your own storage and bandwidth | Per-user or per-host subscription, plus add-ons for recording storage or extra features |
| What drives cost | Peak concurrent participants, bandwidth per stream, recording volume and retention length | Same drivers, plus the number of environments and the scope of integrations | Licensed seats, recording minutes, webinar attendee tiers and premium features |
| What to request in a quote | Ask for a sizing model, TURN design, backup plan and a named owner for each operating task | Ask for a fixed scope, handover list, support hours, upgrade policy and exit terms | Ask for a data residency statement, recording export format, sub-processor list and price change terms |
Evidence a self-hosted meeting stack supports for HIPAA and recordkeeping
A self-hosted meeting stack gives you control over where audio, video and logs live, which makes it easier to prepare evidence for HIPAA technical safeguards and, where recordings are business records, for SEC recordkeeping. The stack prepares this evidence, but independent auditors and your counsel decide whether it meets your obligations.
Transmission encryption configuration
Section 164.312(e)(1) of the HIPAA Security Rule requires technical measures that guard against unauthorized access to ePHI sent over electronic networks. For meetings, that means documenting TLS settings on the web front end, encryption of media streams, and whether any session can fall back to unencrypted transport. Keep the reverse proxy and certificate configuration under version control so you can show the setting in force on any date. Confirm with each vendor exactly which media encryption modes are enabled by default.
Access and administrative logs
Section 164.312(b) calls for audit controls that record and examine activity in systems containing ePHI. For a meeting platform, this means retaining logs of administrator actions, room creation, authentication events and configuration changes, and forwarding them to a central store your security team reviews. Define who reviews them, how often, and what they look for. Confirm which events each component logs natively and which need extra configuration.
Recording access trail
Recordings are often the most sensitive artifact a meeting stack produces. Record who started a recording, who viewed or downloaded it, and when it was deleted, and tie each event to an individual account from your identity provider rather than a shared login. Set a retention rule that matches your policy and confirm that deletion removes copies from backups on a schedule you can document.
Business communication retention
SEC Rule 17a-4(b)(4) requires broker-dealers to preserve originals of communications received and copies of communications sent relating to the business for at least three years, including inter-office communications. This applies only where meeting recordings or meeting chat carry business communications covered by the rule. Ask your compliance team to classify meeting content first, then decide whether storage must be write-once or otherwise protected from alteration.
Evidence packaging for assessors
Assessors ask for configuration baselines, change records, log samples and proof that controls operate over time, not only that they exist. DeployOpen prepares these artifacts from your deployment so your auditor can test them, but does not issue audit reports or attestations. Agree in writing which evidence set will be produced, how often it is refreshed, and who owns each artifact after the engagement ends.
Questions buyers ask before hiring a video conferencing partner
What drives the cost of self-hosting video conferencing?
Most of the cost comes from server capacity, network bandwidth, the people who run the platform, and the scope of the engagement. Media traffic is the main driver: every participant's audio and video passes through your media servers, so concurrent users and video quality set how much compute and bandwidth you need. Add TURN relay capacity for users behind strict firewalls, storage for recordings, and monitoring. Recurring costs include cloud or data center hosting, bandwidth, storage growth and upgrades. One-time costs include design, installation, SSO and integration work, and testing. Ask any partner for a quote that separates these items, states assumptions about peak concurrent users and recording retention, and names who pays for ongoing support.
How long does a self-hosted video conferencing deployment take?
The timeline depends on scope, environment and how many integrations you need. A single Jitsi Meet or BigBlueButton instance on infrastructure you already run is far simpler than a multi-region deployment with TURN relays, SSO, recording storage and LMS or chat integration. The stages are usually requirements and sizing, network and identity design, build and hardening, integration, load testing, and user rollout. Delays most often come from firewall change approvals, identity provider configuration, and decisions about recording retention. DeployOpen agrees timelines in writing as part of a fixed scope, so ask for a schedule tied to named deliverables and to the approvals your team must provide.
What does our team need to provide for a video conferencing deployment?
Your team needs to supply the infrastructure decisions and access that the platform depends on. Typical inputs include the cloud account, data center or private network where the servers will run, DNS names and TLS certificates, firewall and NAT rules for media ports, and a decision on TURN relay placement. You will also need an identity provider contact for SSO, a target for recordings (object storage or file server), expected peak concurrency, and a named owner for approvals and acceptance testing. Confirm in the scope which of these items the partner handles and which remain with your staff.
Can our own IT team run self-hosted video conferencing without a partner?
Yes, if your team already operates Linux servers, containers, reverse proxies and real-time network traffic. Jitsi Meet and BigBlueButton are both open source, so there is no license fee to pay for the software itself. The harder work is operational: keeping media servers sized for peak meetings, managing TURN for users on restrictive networks, patching, backing up recordings, and testing failover. Teams often bring in a partner for the initial build and hardening, then keep operations in-house or move to a retainer for upgrades and testing. Ask yourself whether you can staff on-call coverage for meetings and webinars during business hours across time zones.
When is a hosted video conferencing service a better choice?
A hosted service usually fits better when you need to start quickly, have few technical staff for real-time media, or do not have data residency, network control or recording storage requirements that rule out third-party hosting. It also suits organizations that want the vendor to carry scaling and availability for large webinars. Self-hosting makes more sense when meetings must stay inside your network or a specific jurisdiction, when you need tight control over recordings and retention, or when integration with internal identity, chat or LMS systems is central. Compare total cost over the period you plan to run the service, including staff time, not only the subscription or infrastructure line.
How are meeting recordings stored, secured and retained?
Recordings are written to storage that you choose, such as object storage or a file server inside your environment, and the retention rule should be set before go-live. Plan for three elements: where the files land, who can access them, and how long they are kept before deletion. Access should follow your identity provider groups, and transfers and storage should be encrypted. If recordings may contain regulated information, check the retention rules that apply to your sector. For example, the SEC's Rule 17a-4(b)(4) under 17 CFR 240.17a-4 sets a three-year preservation period for certain broker-dealer communications, which can apply to recorded client conversations. Ask your legal and compliance team to confirm which rules apply before the storage design is final.
How do TURN servers and network design affect meeting quality?
TURN servers relay media for participants whose networks block direct peer or server connections, so they decide whether those users can join at all. Without a reachable TURN service, some users on corporate or mobile networks will fail to connect or will see poor quality. Design points include public and private addressing, which UDP and TCP ports are open, TLS on the relay path, and how traffic is routed between sites. Relay traffic adds bandwidth cost and load to your servers, so size it from the share of users who need relaying, which you can estimate from a pilot. Confirm firewall and NAT details with your network team early, because they often set the schedule.
Questions to ask an implementation partner before signing
Start with sizing, because every other commitment depends on it. Ask the partner how they derived the server and bandwidth numbers for Jitsi Meet or BigBlueButton: which concurrent participant counts, how many simultaneous rooms, whether video is on by default, and whether screen sharing and recordings were included in the model. Then ask what load test they will run before go-live, which tool they will use to generate participants, which pass criteria they will apply, and whether the test runs across the TURN path that real users will take. A partner who cannot describe the test profile in writing has not sized the system.
Next, ask how TURN will be designed for restricted networks. Find out which TURN server they will deploy (for example, coturn is a common choice, but confirm it), where it sits relative to the firewall, which ports and TLS fallbacks are opened, and how they will test connectivity from guest networks, corporate proxies and mobile carriers. On recordings, ask where media is written, how long it is kept, who can download or delete it, and how retention interacts with any legal hold or records policy you already run. Ask them to confirm whether recording storage is encrypted at rest and whether access to recordings is logged. For SSO and LMS integration, request a written test plan covering login, role mapping, room permissions and any LTI or chat connector you need, and ask who owns the identity provider configuration after handover.
Finally, pin down operational responsibility and evidence. Ask who applies upgrades and security patches to the conferencing stack, on what cadence, and how a critical fix is handled outside that cadence. Ask for a backup and restore test that actually restores a meeting configuration and recording set into a clean environment, with the result documented. Then ask what evidence the partner will hand an assessor: configuration baselines, change records, test reports, access reviews and logs that show audit controls over systems that carry sensitive meeting content. DeployOpen works from a written fixed scope, so each of these items should appear as a named deliverable with an owner and an acceptance step before work begins.
How DeployOpen scopes, builds and supports self-hosted video conferencing
The sequence moves from a written scope to a hardened, tested and documented video conferencing service inside your own infrastructure, with support available afterward under a separate agreement. Each step ends with a named output so you can confirm progress before the next one starts.
Agree the scope in writing
Before any work starts, DeployOpen reviews your meeting volumes, participant limits, webinar needs, network zones, identity provider, chat or LMS integrations and recording retention rules with your team. The result is a written scope that names the platform choice between Jitsi Meet and BigBlueButton, the deliverables, the responsibilities on each side and the timeline. Work does not begin until your authorized approver signs that document.
Confirm the architecture and sizing
DeployOpen documents the reference design for your environment, including server and media capacity, TURN and firewall paths for users behind restrictive networks, recording storage location and the hosting accounts or data centers involved. Your infrastructure team reviews the design and confirms capacity assumptions against vendor guidance. The output is an approved architecture document that lists every component, network flow and open question.
Build the platform in your infrastructure
DeployOpen installs the chosen open-source platform inside your cloud accounts, data center or air-gapped network, then configures SSO, the agreed chat or LMS integrations, recording storage and access roles. Changes are tracked in version control so your team can see what was configured and why. The check at the end of this step is a test meeting and a test webinar completed from each network zone in scope.
Harden and security test the deployment
DeployOpen applies the hardening baseline agreed in the scope, covering transport encryption, host and container configuration, administrative access and logging. It then runs security testing against the deployed service, including its web interfaces, APIs and exposed media paths, and reports findings with severity and suggested fixes. Your team retests remediated items, and the step closes when agreed high-priority findings are resolved or formally accepted in writing.
Prepare compliance evidence
Where your organization must meet obligations such as retention of communications or audit controls over systems that handle regulated data, DeployOpen helps map those requirements to configuration settings, logs and recording retention settings. It prepares the evidence package your auditors or assessors will ask for. DeployOpen does not issue audit reports or certifications, so the step closes when your compliance lead confirms the evidence matches the requirements they own.
Hand over documentation and runbooks
DeployOpen delivers architecture diagrams, configuration records, administrator guides, backup and restore procedures, upgrade steps and incident runbooks for the video service. Your operations staff walk through the runbooks in a working session and perform at least one restore or failover exercise under supervision. The handover is complete when your team can run routine tasks without relying on the implementation team.
Support upgrades under a retainer
If you want ongoing help, DeployOpen offers retainers that cover platform upgrades, patch application, continued security testing and support requests on terms written into a separate agreement. Scope, response expectations and fees are set in that agreement, not assumed here. Your team keeps the final approval for production changes, and each upgrade is recorded in the runbooks and evidence package so the service stays documented between releases.
