Self-hosted video conferencing for the public sector

Self-hosted video conferencing for the public sector: why the design starts with sovereignty and records

For most agencies, the choice of video engine is Jitsi Meet, either deployed on its own or as the meeting component inside openDesk, with BigBlueButton as the alternative when recording and classroom-style features dominate the requirements. The more consequential decisions come before the engine is selected: where the media servers sit, who holds the keys to the recordings, how long those recordings are kept, and which control catalog the system must be assessed against. Federal agencies work from the NIST SP 800-53 control catalog and its baselines, state and local bodies often apply their own security standards, and the accessibility rule for state and local government web content and mobile apps sets dated obligations that apply to meeting pages and embedded tools. These requirements shape the design more than the video software does.

Start by mapping the data flows. Identify where media is relayed, where recordings are written, which backups hold copies, and which external services a browser or client contacts during a call, such as public STUN or TURN relays and third-party fonts or scripts. Then document who the records owner is for each meeting type, since a council meeting, a public hearing and an inter-agency case review usually fall under different retention schedules. The Jitsi handbook says HTTPS with a proper domain certificate is necessary for working audio and video, so certificate authority and renewal belong on the same checklist as the records plan. Confirm these points with your records officer, security office and procurement team before any hosting contract is written.

DeployOpen plans, implements, hardens and documents self-hosted platforms inside your own infrastructure and prepares evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Those come from independent auditors and certification bodies, and the scope of any assessment should be agreed with them early. Ask an implementation partner to show how the design maps to the control families and accessibility criteria your organization must meet, and to state which items it will deliver as evidence and which your own teams must produce.

Which public sector requirements change the video build

This table maps each public sector requirement to what it changes in a self-hosted video build: hosting location, TLS, authentication, recording storage and procurement. Read each row as a question to settle with your legal, security and accessibility owners before choosing the hosting model. The main takeaway is that the scope of the system and the classification of the meetings matter more than the choice of platform.

Requirement	What it changes in the video build	What to confirm before design
NIST SP 800-53 baselines (low 149, moderate 287, high 370)	Baseline selection sets how many controls and enhancements the meeting platform, its logs and its operators must evidence. Moderate or high impact systems need more access, audit and configuration controls than an informal internal tool.	Which impact level your authorizing official assigns to meetings, and whether the video service inherits controls from a shared platform or must document its own.
FedRAMP scope for cloud-hosted meetings	A cloud-hosted meeting service that serves federal information for an agency, or is offered as a shared service, falls in FedRAMP scope. A system run only for one agency's own operations on cloud infrastructure may fall outside it, which pushes hosting toward agency-controlled infrastructure.	Whether the service is shared across agencies or customers, who operates it, and whether the hosting provider holds an authorization that covers the meeting function.
FBI CJIS Security Policy v6.1 encryption	For criminal justice information in transit and at rest outside physically secure locations, the policy requires FIPS 140-3 certified modules or FIPS 197 AES with keys of at least 256 bits, up from 128 bits. TLS endpoints, recording storage and backups must all use approved cryptography, and vulnerability scanning must run at least monthly.	Whether the TLS libraries in your Jitsi or BigBlueButton hosts use FIPS 140-3 validated modules, and where recordings and transcripts are stored and encrypted.
32 CFR 2002.14(h)(2) and CUI on non-federal systems	Agencies that share controlled unclassified information in meetings must apply NIST SP 800-171 requirements to non-federal systems that carry it, unless the CUI category sets other safeguards. Guest access, screen sharing and recordings then fall under the same protections as documents.	Whether meetings include CUI, whether external participants will join from non-federal devices, and how the agency's contract or agreement defines the safeguards.
ADA Title II and WCAG 2.1 Level A and AA	State and local government meeting pages, join pages and any web or mobile content delivered through contracts must meet WCAG 2.1 AA from 26 April 2027 for entities serving 50,000 or more people and from 26 April 2028 for smaller entities and special districts (28 CFR 35.200). Captions, keyboard operation and screen reader support become acceptance criteria for the video front end.	Your population served, the chosen client and join page, captioning or transcription options, and whether the hosting contract requires the vendor to deliver conformance evidence.
NIS2 scope and national security exclusions	NIS2 covers central government entities regardless of size and lists public administration as a high criticality sector, with Member States free to extend it to local administration. It does not apply to entities working in national security, public security, defense or law enforcement, so those teams need a different assessment of their meeting platform.	Whether your entity is central or local government in a Member State that extended scope, and whether any of your meetings fall in the excluded security or law enforcement work.
Procurement of hosting and support	Each requirement above becomes a clause in the hosting and support contract: control evidence, patch timelines, data location, personnel access and exit terms. Open-source licenses do not cover these obligations, so the agency pays for them through a support or implementation agreement.	Who signs the operating responsibility, what evidence the partner provides for each baseline and standard, and how upgrades and incident response are scheduled.

Which platform fits which agency meeting pattern

Jitsi Meet suits general government meetings and citizen guest rooms where an agency wants a browser-based meeting service without buying a full workplace suite. Jitsi Meet is licensed under Apache-2.0, so the agency can run it in its own cloud account, data center or isolated network. A standard deployment is built from several components: a web server (nginx or Apache) serving the web app, the Prosody XMPP server, Jicofo (the conference focus) and one or more Jitsi Videobridge media routers.

Component set: Plan for the web server, Prosody, Jicofo and Jitsi Videobridge as separate roles, each with its own patching and monitoring.
Guest access: Use JWT token authentication for staff and a separate anonymous domain for citizens, rather than relying on the deprecated secure domain method for new installations.
Production certificates: Plan for HTTPS with a proper domain certificate, since the handbook says self-signed certificates cause problems, especially on mobile clients.
Hosting boundary: JaaS and the public meet.jit.si instance are not sovereign hosting options, so the agency must run the stack itself.
Scaling: Videobridges scale horizontally by adding more, and the default install is already set up for that.

Confirm with the vendor or your integrator which Jitsi release line and Debian or Ubuntu version your environment will use before you write the operating procedures.

Deployment patterns for agencies with different hosting rules

Public bodies rarely get to choose their hosting model freely. Hosting rules, sovereignty expectations and existing procurement frameworks decide where media relays, recordings and logs land, and who can read them. The four patterns below differ mainly in who operates the infrastructure and who holds the keys, so each card lists what to confirm before a contract is signed.

On-premises data center

The agency runs Jitsi Meet on its own servers, with the web server, Prosody, Jicofo and one or more Jitsi Videobridge media routers inside its own facility. Media is relayed locally and the agency holds the keys, logs and any recordings. Jitsi's scalable setup is configured for horizontal scaling by default, so new videobridges can be added later, and the central server guidance is 4 CPU and 8 GB RAM. Confirm with procurement who signs for hardware, power and network upkeep, and whether the TURN service and public ports will be reachable by staff on external networks.

Sovereign private cloud in the country

The agency or a national cloud provider hosts the same Jitsi stack in virtual machines inside national borders, under a contract that names the data location. Media, recordings and logs stay in that jurisdiction, but the cloud operator has administrative access to the hypervisor and storage. Ask who holds the encryption keys for recording volumes, who can read host-level logs, and whether support staff access is logged and reviewed. Confirm that the hosting provider's staff vetting and incident notification terms match the agency's classification of the meetings.

openDesk on a Kubernetes cluster

openDesk bundles Jitsi with Nextcloud, OX App Suite, Element and Collabora, under one identity layer provided by Nubus. It is deployed with Helmfile and Helm on a CNCF-certified Kubernetes cluster at v1.33 or later, and ZenDiS recommends its Enterprise Edition for production. Confirm which cluster provider and ingress controller are used, where the database and object storage services sit, and whether the agency or ZenDiS holds the upgrade calendar. Recording storage and log retention are set by the cluster and the bundled components, so confirm them component by component.

Partner-operated hosted enclave

An implementation partner operates a dedicated, isolated environment for the agency, with Jitsi deployed in the agency's own cloud account or a dedicated tenant. Day-to-day operations, patching and monitoring are contracted, while the agency keeps the data and the approval of access. Ask for a written list of partner staff roles that can reach the environment, how privileged sessions are recorded, and where backups and recordings are stored. Confirm the support hours, escalation path and whether the contract covers upgrades on a fixed cycle.

Joint hosting with a shared service

Several public bodies share one Jitsi or openDesk instance under a common governance agreement, which lowers operating cost but mixes tenants. The main risk is that one agency's recordings, guest lists or logs become visible to another. Define separate tenants or rooms, separate recording storage and a named data controller for each participant body. Confirm how guest access from other agencies is authenticated and which body answers records requests for shared meetings.

Pattern selection checklist

Before choosing a pattern, record the classification of the meetings, the sovereignty requirement in the procurement, and the expected peak concurrency. Those three inputs usually decide whether the agency can use a national cloud, needs a dedicated enclave or must keep everything in its own facility. Confirm that the chosen pattern can produce the audit trail and retention evidence the agency's own assessors will request.

How citizen and inter-agency guests join without weakening authentication

The core rule for public sector meetings is that guests should never be able to create rooms on the authenticated side of the platform. The Jitsi handbook recommends JWT token authentication over the older secure domain method, which relied on username and password room creation and is now marked as deprecated for new installations. With JWT, your own application or portal signs a token that carries the user's identity and room permissions, and Jitsi Meet checks it before admitting the participant. The handbook also recommends a separate anonymous domain for guests, so citizens who join without an account reach a different, tightly scoped path. Before go-live, confirm in the Docker configuration (the .env file) which authentication mode is active, and test that a guest token cannot create or moderate a room on the authenticated domain.

Inter-agency participants usually belong to other administrations with their own identity providers. The openDesk federation documentation describes how an external identity provider can be connected to the suite, which is the natural route for staff from partner agencies to sign in with credentials their own organization controls. Decide in advance which agencies are federated, which roles they receive, and how accounts are removed when a secondment ends. Lobbies add a second control: the moderator admits each participant after seeing who is waiting, which is useful for public hearings and for citizen appointments where identity must be confirmed by a person. Guest identity for records should be captured at the point of entry, typically a display name and a reference such as a case or appointment number carried in the token, so that attendance logs can be linked to a file under your retention schedule.

Two practical limits apply. First, the handbook is clear that HTTPS with a proper domain certificate is required for working audio and video, and it warns that self-signed certificates cause problems, especially with mobile clients. A citizen who receives a certificate warning on a phone will often leave the meeting, so plan for certificates from a trusted authority or an internal authority that every managed device already trusts, and test on the mobile apps your public audience uses. Second, do not describe these sessions as end-to-end encrypted. Transport encryption protects media between clients and the servers, but the server still handles the streams, and end-to-end encryption in Jitsi comes with restrictions that must be assessed separately for each meeting type. Ask your implementation partner to document, for every guest path, which encryption mode applies.

How a public sector video rollout runs in phases

The sequence moves from agreeing which meetings the platform must serve to a handover that lets the agency's own operators run it. Each phase closes with a written artifact that the next phase depends on.

Classify meeting types and data
DeployOpen works with the agency's records officer, security lead and business owners to list every meeting type the platform must serve, such as internal staff meetings, public hearings, board sessions, inter-agency working groups and citizen consultations. Each type is tagged with the highest sensitivity of information it will carry and whether it will be recorded. The output is a classification register that sets the scope of the later phases. The phase is done when the agency signs off the register and the scope is agreed in writing.
Design identity and guest access
Using the register, the team defines who may create rooms, how staff authenticate against the agency's identity provider, and how external participants such as citizens, contractors and partner agencies join. Options include token-based authentication, a separate anonymous domain for guests, and lobby controls for public sessions. The design is checked against the agency's own identity policy and documented as a role and access matrix. The phase closes with an approved matrix and a list of the open questions that need an owner.
Size and build the environment
The team sizes the media servers from the concurrency and peak meeting numbers in the register, then builds the web, signaling and media components inside the agency's own cloud account, data center or isolated network. Certificates, TURN reachability and firewall rules are set up so that participants on restrictive networks can connect. The build is recorded in a configuration baseline and tested with load runs that simulate the expected peak. The phase is done when a test report shows the environment meets the agreed capacity targets.
Configure accessibility and records
The team checks the user interface, documentation and any published content against WCAG 2.1 Level A and AA, and records gaps in an accessibility remediation list with an owner for each item. In parallel, it configures recording storage, access permissions, retention periods and deletion steps according to the records schedule the agency's records office approves. Consent notices and recording indicators are set for each meeting type. The output is an accessibility findings report and a records retention schedule signed by the records office.
Run a pilot with named agencies
A small number of named agencies use the platform for real meetings of the types in the register, under a pilot plan that defines success criteria, support contacts and rollback steps. DeployOpen collects participant feedback, connection failures and any unexpected recording or access events, then fixes configuration issues and reruns the relevant tests. The pilot ends with a pilot report that lists resolved defects, open risks and the decision to expand. The agency confirms the report before the handover begins.
Hand over with operations runbooks
DeployOpen delivers operations runbooks covering monitoring, scaling, certificate renewal, backups, upgrades, incident response and recording deletion, and trains the agency's operators on each one. Support responsibilities are split clearly between the agency's staff and any external support retainer, and the upgrade process is scheduled around high-use periods. The handover is complete when the agency's operators run a documented test of a runbook procedure and the support model is signed. Ongoing support, if chosen, is agreed in a separate written scope.

Evidence auditors and oversight bodies ask for from meeting systems

This table maps each piece of evidence an assessor or oversight body typically asks for to the Jitsi or BigBlueButton component that produces it. Read it as a checklist for designing logging, retention and scanning before the first public meeting, not after. DeployOpen prepares this evidence for independent auditors and certification bodies, who issue any audit report or attestation.

Evidence	Component that produces it	What the assessor checks	Where it usually fails
TLS configuration and certificate records	Web front end (nginx or Apache) serving the Jitsi web app or BigBlueButton proxy	Certificate chain from a proper domain, protocol and cipher settings, renewal history	Self-signed or internal certificates not trusted by guest devices
JWT and LDAP authentication logs	Jitsi authentication configured in the .env file, or the LDAP or identity provider in front of BigBlueButton	Who was allowed to create or join rooms, token issuance records, directory source	Legacy secure domain still enabled, or guest access sharing the moderator path
Room access logs	Prosody XMPP server and Jicofo conference focus	Room creation, join and participant events tied to an identity or token	Logs rotated too quickly or not forwarded to a central store
Recording storage and deletion logs	Jibri (recording and streaming) or BigBlueButton recording storage	Where recordings land, who accessed them, deletion under the agency's retention schedule	Recordings copied to user devices or shared drives outside the retention rule
Vulnerability scan results	Scanner run against the meeting hosts and containers	Scans at least monthly where CJI is in scope under CJIS Security Policy v6.1, with findings tracked to closure	Scans run once at go-live, then stopped
SP 800-53 control mapping	Documented mapping of the deployed components to the chosen NIST SP 800-53 Rev. 5 baseline	Each selected control tied to a configuration, owner and evidence source; baseline chosen by the agency	Mapping written as narrative with no link to current configuration
WCAG 2.1 AA test results	Web front end, meeting UI and any agency-built pages, tested against WCAG 2.1 Level A and AA	Results for the agency's compliance date under ADA Title II, including contracted content	Third-party meeting client components never tested with assistive technology

What public sector buyers ask before hiring a video implementation partner

What does self-hosted video conferencing for a government agency cost, and what drives it?

Cost splits into one-time work and recurring running costs. One-time work covers architecture, installation, identity integration, hardening, testing and documentation. Recurring costs cover the servers or cloud capacity for the central server and videobridges, outbound bandwidth, storage for any recordings, TLS certificate management, monitoring, patching and support. Capacity scales with peak concurrent meetings, so the number of simultaneous rooms and participants matters more than total headcount. Recording storage grows with retention periods, which your records officer sets. Ask any partner for a quote that lists each component separately, states who pays for hardware and bandwidth (you or the partner), and names the support tier, including response expectations for patches. Jitsi Meet and BigBlueButton are both open source, so the cost is in operations rather than licenses.

How long does a self-hosted video deployment take in a public sector setting?

Duration depends on scope, the number of integrations, and how quickly approvals move. The main drivers are the identity source (whether users authenticate through an existing directory or a federated identity provider), network changes for firewall rules and public ports, certificate issuance, and the security review your agency runs before go-live. A basic Jitsi Meet deployment is mostly technical work, but a deployment inside a broader workplace suite, or one that must pass accessibility and records reviews, takes longer. Ask for a written schedule with milestones for design approval, staging tests, a load test, a pilot group and cutover. Any timeline in a quote should name the assumptions it depends on, such as access to change windows and named approvers.

What must our agency provide before a video implementation starts?

Several inputs decide whether the project stays on schedule:

Network: a public DNS name, a valid certificate from a trusted authority or your internal CA, open ports for the web, XMPP and media traffic, and a TURN relay for users behind restrictive firewalls. Jitsi's handbook says HTTPS with a proper domain certificate is necessary for working audio and video, and self-signed certificates cause problems, especially on mobile.
Identity: the directory or identity provider that will authenticate staff and guests, plus a decision on who may create rooms.
Legal and records review: sign-off on recording, consent notices, retention periods and where recordings are stored.

Ask the partner to list each input as a dependency in the quote, with the owner on your side.

Can our own staff run a self-hosted video platform after handover?

Often yes, but only if the platform team can operate the stack after handover. A Jitsi deployment has several parts: a web server, the Prosody XMPP server, Jicofo, and one or more Jitsi Videobridge media routers. Docker deployments split these into separate containers, and the official setup supports horizontal scaling by adding videobridges. Staff need skills in Linux administration, containers, TLS, monitoring and upgrade procedures. Ask the partner for a runbook, a documented upgrade and rollback path, alert thresholds, and a training plan. Decide in advance who handles security patches and who answers when a meeting fails during a public hearing.

Do we need openDesk Enterprise Edition for a production video deployment?

ZenDiS recommends openDesk Enterprise Edition for production, which is a decision your agency should confirm against its own requirements. The Enterprise Edition 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. It is sold as SaaS or for on-premises installation. If you run Jitsi standalone outside openDesk, the Enterprise Edition does not apply, and you must set your own support and patch commitments. Ask for a written comparison of the support model, the patch cadence, and which components sit under which licenses. Note that openDesk expects external production-grade services such as PostgreSQL, Redis, an SMTP relay, object storage and a TURN server, so production scope is larger than an evaluation install.

How do FedRAMP and CJIS requirements change self-hosting for agencies?

Self-hosting on your own infrastructure can keep a system out of FedRAMP's cloud scope, because FedRAMP applies to cloud products offered on behalf of an agency, and systems used only for a single agency's operations on cloud infrastructure, not offered as a shared service, are out of scope. That answer depends on the facts of your deployment, so confirm it with your authorizing official. CJIS Security Policy is different: version 6.1 took effect on 26 June 2026, and it requires FIPS 140-3 certified modules or FIPS 197 AES with at least 256-bit keys for CJI in transit and at rest outside physically secure locations, along with at least monthly vulnerability scanning. Ask the partner which cryptographic modules the stack uses, how TLS is configured, and how scanning is scheduled and evidenced. Any SP 800-53 baseline mapping should use the control IDs in NIST's catalog and the baseline your authorizing official selects.

How do accessibility deadlines apply to meeting pages and plugins?

The ADA Title II rule requires state and local government web content and mobile apps, including those provided through contracts or licenses, to meet WCAG 2.1 Level A and AA. Entities serving 50,000 or more people must comply from 26 April 2027, and smaller entities and special districts from 26 April 2028, according to 28 CFR 35.200. A meeting page, join flow, lobby, or a plugin embedded in a public site falls within that scope if your agency provides it. Ask the partner for an accessibility review of the join page, the in-meeting controls, the lobby and any custom branding or plugins, with the issues logged and a remediation plan. Confirm with your legal counsel which pages and vendors are in scope.

What should a public sector quote include so we can compare partners?

Ask every partner to price the same written scope, with each deliverable named. A useful quote lists:

Architecture and design, including the number of videobridges and the peak concurrency assumed
Installation, identity integration, TURN and certificate setup
Hardening, testing and the load test method
Documentation, runbooks and training
Support tier, patch windows and response expectations
Hosting, bandwidth and recording storage, with who pays for each

DeployOpen plans, implements and supports self-hosted open-source platforms in your own infrastructure, and most engagements are fixed-scope with agreed deliverables and timelines. DeployOpen does not publish a price list, so a quote follows from the written scope.

Questions to put to an implementation partner before signing

Start with where the data lives. Ask the partner to show, in writing, where media, logs and recordings are stored for each component of a Jitsi Meet deployment: the web server, Prosody, Jicofo, Jitsi Videobridge and, if Jibri is used, its recording output. Ask which of these run inside the agency's own accounts or data centers, where the TURN service sits, and whether any telemetry or crash reporting leaves the network. Ask how records retention is enforced in practice: who sets the retention period for recordings and chat logs, whether deletion is automatic or manual, how legal holds are applied, and how the partner proves that deletion happened. Retention rules that exist only in a document will not satisfy a records officer.

Next, pin down identity and administrator access. Ask how JWT token authentication is configured in the .env file, who issues the signing keys, how they are rotated, and which separate anonymous domain is used for citizen and inter-agency guests. Ask the same for LDAP: which directory is queried, which service account is used, and how group membership maps to meeting moderators. Then ask who holds administrator access to the hosts, the Kubernetes cluster and the openDesk Helmfile repository, how that access is granted and removed, and how every privileged session is logged and reviewed. Request a sample of those audit records before signing.

Map the openDesk requirements to the agency's estate before any hardware is discussed. The published evaluation minimum is not a production sizing, so ask which production-grade PostgreSQL, MariaDB, Redis, SMTP relay, ClamAV, object storage and TURN services the partner will provide, and whether they run inside the agency's boundary. Ask how upgrades follow the openDesk release policy, under which only the latest minor version is supported and in-place upgrades between majors are not guaranteed, and what the partner will do when the agency is several minor versions behind. Finally, ask how accessibility is tested against WCAG 2.1 Level A and AA, which tools and manual checks are used, and whether results are delivered as evidence the agency can file.

How to confirm which rules apply before design starts

This sequence turns the agency's jurisdiction, data types, hosting model, and population size into a written applicability memo that legal, procurement, and the design team can all work from before any platform is chosen.

Confirm the agency's level of government
The agency's legal counsel or records officer confirms whether the organization is federal, state, or local, and whether it is a department, a special district, or a contractor acting on its behalf. This determines which frameworks are in view, since NIST SP 800-53 and FISMA apply to federal agencies, while state and local bodies often inherit requirements through state law, contracts, or grant terms. Done means a signed one-page statement of jurisdiction is in the file, with the authority cited for each framework that may apply.
Classify the information that will appear in meetings
The information security lead and the business owners of recurring meetings list the kinds of information discussed, such as personal data, controlled unclassified information (CUI), or criminal justice information (CJI). CUI triggers the safeguards in 32 CFR 2002 for non-federal systems, and CJI triggers the FBI CJIS Security Policy, which version 6.1 made effective on 26 June 2026. Done means each meeting series has a data classification label and a named owner who confirmed it.
Determine whether the service is cloud-hosted and shared
The architect and the procurement lead document where the Jitsi or BigBlueButton servers will run and whether any outside party operates them for multiple customers. FedRAMP scope under OMB M-24-15 covers cloud services that handle federal information on behalf of an agency, while a single-agency system on cloud infrastructure that is not offered as a shared service is generally out of scope. Done means a hosting diagram is attached to the memo and the shared-service question has a written answer from the hosting provider.
Check NIS2 transposition in the member state
For agencies in the EU, legal counsel checks how the national government has transposed NIS2 and whether it extends the directive to local public administration. NIS2 covers central government entities regardless of size and excludes entities working in national security, public security, defense, or law enforcement. Done means the memo states whether NIS2 applies, the national law reference, and whether any exclusion covers the meetings in scope.
Set the accessibility deadline from population served
The accessibility lead counts the population the agency serves and maps it to the ADA Title II web and mobile rule. Under 28 CFR 35.200, WCAG 2.1 Level A and AA apply from 26 April 2027 for entities serving 50,000 or more people and from 26 April 2028 for smaller entities and special districts, including content delivered through contracts or licenses. Done means the memo records the population basis, the applicable date, and whether meeting interfaces and recordings fall in scope.
Assemble the applicability memo for review
The compliance lead combines the five findings into a written applicability memo, listing each framework as applies, does not apply, or needs a decision, with the reason. Legal reviews the legal conclusions and procurement reviews the hosting and support implications before design starts. Done means both functions sign the memo, and open questions are assigned to named owners with a date for resolution.

How DeployOpen scopes, builds and supports public sector video

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the agency's own infrastructure, including its cloud accounts, data centers or isolated networks. For public sector video, that means agreeing the meeting model, identity and records requirements in writing before any server is configured.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Scope maps which meeting types, guest groups and departments use Jitsi, and where media servers must sit.
Scope records how citizen and inter-agency guest access, recording and retention rules will be handled.

How we build

Build covers the web, Prosody, Jicofo and videobridge components, with HTTPS certificates issued from the agency's own trust chain.
Authentication is configured with JWT tokens and a separate anonymous domain for guests, following current Jitsi guidance.
Where openDesk is in scope, the Jitsi component is integrated into the wider suite and its identity federation is tested.

How we hand over

Handover includes configuration documentation, network and port maps, and runbooks for restarts, certificate renewal and scaling.
Compliance evidence is prepared for the controls the agency names, such as access, audit and transmission settings, for its assessors to review.
Acceptance tests cover meeting join from inside and outside the network, guest flows and recording behavior as agreed in scope.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, separate from the initial fixed-scope build.
Upgrade planning follows the vendor release cadence, and the agency approves each change window before it is applied.
Security testing of the deployed service can be scoped separately, including web application and infrastructure testing.

Self-hosted video conferencing for the public sector