What Jitsi customization covers
Customization of Jitsi Meet covers four kinds of work: branding the web interface, configuring interface and feature settings, embedding meetings in your own applications with the IFrame API, and enabling optional components such as Etherpad for shared notes, Excalidraw whiteboards and transcription through Jigasi. Each has different owners and different risks, so it helps to scope them separately before a rollout starts.
Most changes start with a trigger. A rebrand changes logos, colors and the welcome page. An intranet embed places meetings inside a portal or case management tool. A feature policy turns off screen sharing for guests or hides features that conflict with recording rules. A new optional component, such as a whiteboard for a training team, adds a service that must be deployed, secured and upgraded alongside the core stack. Write down which trigger applies to each request, because it determines who should make the change.
Many small configuration changes can be made in-house by a platform team that is comfortable editing the deployment configuration and reading release notes. Embedding work, changes that span several components and upgrade-safe maintenance are more often outsourced, because they touch the web app, the IFrame API contract and the containers together, and because each Jitsi release can change them. Confirm with your team which of these skills you already have.
Jitsi Meet is licensed under Apache 2.0, so you may modify it, but most of these goals are met through configuration, the IFrame API and the supported optional components. A fork creates a code base you must merge and retest with every stable release. Ask any partner to show which goals truly require code changes before agreeing to maintain a fork.
What the work includes
Customization is delivered as configuration and integration work inside your own infrastructure, so the Jitsi Meet code stays upstream. Deliverables for each package are listed in the written scope before work starts.
Interface branding
Covers the logo, color palette, watermarks, favicon, pre-join page text and welcome text shown to participants. Check that every asset is supplied in the sizes and formats the web app expects, and that the branding survives the next Jitsi Meet stable release without manual patching.
Toolbar and feature configuration
Sets which toolbar buttons appear, default audio and video state on join, and which options moderators and guests receive, such as who can mute others or share screens. Each setting should be reviewed with the people who run meetings, because defaults chosen for a small team can fail at larger scale.
IFrame API embedding
Embeds meetings into an intranet portal or internal application through the Jitsi IFrame API, including room naming, display names and lifecycle events. Confirm how the host page passes identity into the meeting and which authentication model governs who can open a room.
Etherpad, Excalidraw and transcription
Enables the optional Etherpad shared notes, Excalidraw whiteboards and transcription backends (Google Cloud, Vosk or Whisper) as Docker extensions. Transcription choices decide where audio is processed, so confirm with your data protection owner whether a cloud backend is permitted before selecting it.
Versioned configuration repository
Keeps branding assets, interface settings, environment files and integration code in a Git repository that is handed over with the deployment. Pin the Jitsi release used for each change so upgrades can be tested against a known configuration rather than rebuilt from memory.
What drives customization effort
This table lists the factors that most change how much work a Jitsi customization takes, why each one adds effort, and how to keep it contained.
| Driver | Why it adds effort | How to keep it down |
|---|---|---|
| Number of brand and layout changes | Each logo, color, toolbar or pre-join change must be built, tested across browsers and carried through every upgrade. Changes to the web app's own code are the hardest to maintain. | Limit changes to the supported interface and configuration options. Agree a written list of brand elements before build starts and treat anything beyond it as a new scope item. |
| Depth of interface configuration | Hiding or reordering toolbar buttons, changing default settings and switching features on or off touch several configuration files. Deep edits interact with each other and need regression checks. | Set only the options your users need. Keep a single version-controlled configuration file so every change is visible, reviewed and easy to roll back. |
| Number of embedding points and their frameworks | Each page or application that embeds meetings needs its own integration with the IFrame API, and each framework (React, Angular, plain HTML, mobile wrappers) handles lifecycle events differently. | Reuse one embed pattern and one wrapper component across all embedding points. Confirm early which frameworks and platforms the embed must support. |
| Optional components enabled | Etherpad, Excalidraw whiteboards, Jibri, Jigasi and transcription each add a service, storage, ports and monitoring. Each one also needs its own sizing, access rules and update cycle. | Enable only the components the requirement names. Add them in phases with a pilot, so each one is verified before the next is introduced. |
| Transcription backend choice and data-handling rules | Google Cloud, Vosk and Whisper backends differ in where audio is processed, what is logged and how the output is stored. Data-handling rules from legal or privacy teams can force a design change after build work has started. | Agree one transcription backend and its data-handling rules before any integration work. Document where audio and transcripts are stored and who can access them. |
| Number of environments | Each environment (development, test, staging, production) needs its own configuration, certificates, domains and test data. Keeping them aligned is ongoing work, and drift between them causes most late defects. | Keep environments built from the same configuration source and promote changes through them in order. Limit the number of environments to what the testing process actually uses. |
| Frequency of Jitsi release changes | Jitsi Meet publishes stable releases by build number. Customizations that touch configuration or embed code may need retesting each time the client moves to a newer release, and the frequency sets how often that retest happens. | Confirm the release cadence the client will follow and keep customizations within supported configuration so upgrades need less rework. Plan the retest into the support agreement. |
Project phases and outputs
The sequence moves from agreed requirements to a tested, documented customization that your team can redeploy without rebuilding it by hand.
Discover brand, feature and embedding requirements
We review your brand guidelines, the features you need switched on or off, and every page or application that will embed meetings, checking each requirement against the Jitsi Meet release tag you have chosen. The output is a requirements register that records each item, the release it was checked against, and any gaps that need a decision before design starts.
Design the configuration and code boundary
We draft the configuration design and list, item by item, what stays in configuration files and interface settings and what would require code changes to the web app. You review and approve the list, because items moved to code add maintenance work at every future upgrade. The output is a signed-off configuration design with a code change register.
Build in a non-production environment
We apply the approved configuration, branding assets and any approved code changes to a non-production deployment that matches your production topology as closely as the written scope allows. Changes are kept in version control so each build can be reproduced. The output is a working non-production instance and a build record tied to the release tag.
Integrate embedding and optional components
We connect the IFrame API embedding in your applications and enable any optional components in scope, such as Etherpad, whiteboards or transcription, with their own configuration checks. Each integration is tested for join, leave and meeting controls from the host page. The output is a list of working integrations with the test results for each.
Test across browsers and devices
We run the test plan across the browsers, operating systems and mobile devices your users rely on, covering branding display, feature toggles, embedded meetings and access paths. Defects are logged, fixed in non-production and retested until the agreed exit criteria are met. The output is a test report with pass and fail results, open defects and the browser and device matrix used.
Hand over with a change log and repeatable deployment
We move the approved build to your production process, document the configuration, the code boundary and the embedding setup, and walk your team through a deployment and rollback run. The change log records every customization and the release it applies to. The output is the handover pack, a change log and a repeatable deployment method your team can run again for future upgrades.
What stays in-house and what goes to a partner
This table compares the Jitsi customization work your team should keep with the technical work a partner typically takes on, along with the skills each side needs to cover it.
| Work area | Typically kept in-house | Typically outsourced to a partner | Skills each side needs |
|---|---|---|---|
| Brand assets and visual identity | Logos, colors, favicons, background images and the final approval of how the interface looks | Placing assets into the web app build, wiring them through the Docker or Debian configuration and checking them across browsers | In-house: brand and design owners. Partner: front-end and web configuration knowledge for the Jitsi Meet interface |
| Copy and text decisions | Wording of welcome pages, prejoin text, legal notices and any language or locale choices | Changing text strings in the build, testing each locale and keeping overrides applied through upgrades | In-house: content owner and legal reviewer. Partner: web build and localization handling |
| Feature and interface policy | Deciding which toolbar buttons, lobby rules, moderator powers and optional features users may see | Translating those decisions into interface and feature configuration and confirming each option exists in the release you run | In-house: a product owner who can make the final call on each setting. Partner: knowledge of Jitsi configuration options |
| Configuration design against the release | Agreeing which release line the organization will follow and who accepts upgrade risk | Mapping customizations to the stable release in use, recording which overrides must be reviewed on each upgrade | In-house: release owner. Partner: Jitsi Meet internals and release change review |
| Container-based overrides | Approving which files or settings are overridden and reviewing the resulting images | Building the override layer for the Docker setup, keeping containers rootless and read-only as the release provides, and documenting each override | In-house: container operations to run the result. Partner: Docker and container build skills |
| IFrame API embedding | Naming the internal applications and pages that will host meetings and owning their user experience | Building the embedding code, handling events and authentication hand-off, and testing inside each host application | In-house: application developers who own the host pages. Partner: IFrame API and web integration developers |
| Optional component setup | Deciding whether Etherpad, Excalidraw whiteboards or transcription are needed, and which data may leave your network | Configuring the chosen Docker extensions, connecting them to the web and XMPP services, and checking each component works end to end | In-house: data protection and privacy owner for transcription choices. Partner: Docker extension configuration skills |
| Testing and documentation | Acceptance criteria, user pilot groups and sign-off on each change | Test plans for browsers and devices, regression checks after each change and written runbooks for the configuration | In-house: pilot users and product owner. Partner: QA, technical writing and Jitsi operations knowledge |
What goes wrong and how to prevent it
Most Jitsi customization problems come from where changes live, how they survive upgrades, and what they expose to users and data flows. Check each item before the first production embed.
Edits inside running containers
Changes made directly inside a running container are lost when the container is recreated on redeploy. Since release stable-11146, the Docker containers run rootless with read-only filesystems, so writes inside them can fail anyway. Prevention: keep branding and configuration overrides as files on the host, mount them into the container, and keep those files in version control.
Upgrades that break customized configuration
A new Jitsi Meet release can change interface keys, templates or build output that your overrides depend on, and the break may appear only after a pull. Prevention: pin the release tag you run, rehearse each upgrade on a staging copy that includes your branding and embedded pages, and review the release notes before rollout.
Snippets from older or unrelated sources
Examples copied from forum posts, blogs or older Jitsi versions often reference settings, file paths or deployment models that no longer apply to your setup. Prevention: check every key and path against the handbook for the release you run, and remove any setting you cannot trace to a current source.
Embeds that ignore browser permissions
Browsers grant camera and microphone to an embedded meeting only when the iframe carries the required permission attributes and the host page is served over HTTPS. Without them, users may join a room that shows no audio or video. Prevention: set the allow attributes in your embed code and test joins in each browser your users run, inside your actual intranet or portal pages.
Optional components that add data obligations
Etherpad notes, Excalidraw whiteboards, Jigasi transcription and Jibri recordings each create data flows the base meeting does not have. Transcription may send audio to a backend such as Google Cloud, and recordings and notes need storage and retention rules. Prevention: map where each component's data goes before enabling it, and record the decision with your privacy and legal owners.
Self-signed certificates on embedded pages
A self-signed certificate on the meeting domain or on a page that embeds it can block audio and video, and the Jitsi handbook warns that such certificates cause problems, especially with mobile clients. Browser warnings also teach users to click through. Prevention: issue the meeting domain a certificate from a trusted authority, serve every embedding page over HTTPS, and test joins on mobile devices before launch.
How the work differs by starting point
Teams running the official Docker setup customize Jitsi through configuration rather than by editing files inside containers. Most of the work is in environment variables and mounted custom directories, which survive container image updates when they are kept separate from the image itself.
- Overrides: Branding, interface settings and feature flags are passed through the environment file and custom directories mounted into the web container.
- Container model: The web, Prosody, Jicofo and videobridge containers are separate, so each customization must be checked against the service it touches.
- Rootless and read-only: Recent releases run rootless with read-only filesystems, so any change that writes into the image will fail, which pushes work toward mounts.
- Optional containers: Etherpad, whiteboards and transcription add services, each with its own configuration and network needs.
- Confirm first: The exact image tag you run, which environment variables your current file sets, and whether anyone has already edited files inside a running container.
Package installs place the web app files on the host, and customizing them usually means editing those files directly. The scope therefore includes a repeatable way to reapply changes after each package upgrade, which the Docker model does not require.
- File edits: Changes to web app files and configuration must be recorded so they can be reapplied after upgrades.
- Upgrade regression: Each package upgrade may overwrite edited files, so the work includes a diff review and a test pass on staging.
- Operating system scope: The Debian 12 or newer and Ubuntu 24.04 or newer requirements, with OpenJDK 17, bound which hosts the work can target.
- Ongoing effort: The recurring cost is tied to the upgrade cadence, not only to the initial build.
- Confirm first: Your current package version, whether local edits already exist on the host, and whether a configuration management tool already manages those files.
Teams moving from meet.jit.si or 8x8's JaaS usually expect their branding and settings to carry over. They do not, because a self-hosted instance starts with its own configuration, so the customization must be specified and built again on your domain.
- Branding rebuild: Logos, colors, titles and background images are re-created for your instance rather than inherited from the hosted service.
- Feature parity: Settings that were configured in a hosted account must be mapped to equivalent options in your own configuration.
- Links and domain: Your domain, its HTTPS certificate and the links users already bookmarked form part of the customization plan.
- Scope of migration: Calendar links, app integrations and user communication are covered by the separate migration work, so this scope should reference it.
- Confirm first: Which hosted settings your users depend on, which assets you own the rights to, and which domain the new instance will use.
Organizations that embed meetings in an intranet or application treat the IFrame API as the main integration point. The customization focuses on how the host page creates, controls and styles the meeting, and on the events the page must handle.
- API calls: The work covers the options passed when a meeting is created, such as room names, display names, toolbar settings and interface options.
- Event handling: The host application needs to respond to events such as participants joining or leaving, so those handlers are part of the scope.
- Styling boundaries: The embedded interface can be adjusted through supported options, but changes beyond those options need to be confirmed against the version in use.
- Identity: When the host application knows who the user is, the token or display name handling is designed with the host application.
- Confirm first: The application framework, the browser and device types that load the page, and which Jitsi version the API must track.
What you need to provide
Before implementation starts, the client supplies the inputs that customization cannot be built without. Brand assets should arrive in the formats the work needs: logo files in vector form where available, favicon and app icon sources, and the colors and fonts used in the web interface. Approved copy for the pre-join page, the welcome page and any legal or privacy text should be final before build, because wording changes after theming tend to cause rework in the templates and language files.
A named decision owner is needed for feature policy. This person decides which toolbar buttons, moderator controls, lobby behavior, and default audio and video settings are enabled or hidden, and which optional extensions such as Etherpad, Excalidraw whiteboards or transcription are in scope. Feature settings in the interface configuration and the config file interact, so one owner should approve the final list rather than several departments each adding requests. The same owner should also approve the list of embedding applications and their hosting details, including the domains that will load the IFrame API and the URLs that will be allowed to embed meetings.
Access to a non-production Jitsi environment running the current stable release tag is required. Confirm which build tag the client has agreed to, and make sure the test environment matches the production version, Docker or Debian packaging method and HTTPS setup. Staff for browser and device testing should be named in advance, covering the browsers, operating systems and mobile clients the organization uses. If transcription is in scope, the client must name the transcription backend, confirm where audio may be processed, and state data-handling rules for transcripts, including retention and who may read them.
A change process for the production configuration must exist before go-live. It should record who requests a change, who reviews it, where configuration files are stored, and how changes are rolled back. Final sign-off rests with the client's named owner for the Jitsi service, who accepts the test results, the feature policy and the branding in writing. DeployOpen prepares the build and evidence, but the client's owner decides when a change goes to production.
Frequently asked questions
Does customizing Jitsi Meet require forking the code?
Generally no. Most branding, feature settings and embedding choices are made through configuration and web assets on your own deployment, so the upstream code stays unchanged. A fork becomes likely when you need behavior that configuration does not expose, such as new interface components, changed signaling or altered media handling. Each such change adds code your team must carry through every upgrade, so decide early which requirements truly need code.
What drives the cost of Jitsi customization, and can you give a price?
A figure follows from the written scope, so DeployOpen does not publish a price list or estimate prices. The main drivers are the number of branding and interface changes, whether meetings must be embedded in your own applications, which optional components such as Etherpad, whiteboards or transcription are enabled, the authentication work, and how many browsers and devices must be tested. Ask the quote to separate one-time build work from recurring upgrade and support work, and to list its assumptions.
How long does a Jitsi customization project take?
The timeline is set in the written scope before work starts, and it depends on the drivers listed there. Interface branding is usually the smallest part of the work. Embedding meetings in your applications, adding optional components and testing across clients take longer because each depends on your systems and internal approvals. Ask for the timeline with its dependencies, including when your team must review designs, supply assets and approve test results.
Can our internal team customize Jitsi without outside help, and what must we supply?
Yes for small brand changes, such as a logo, colors, welcome text and a few settings, if an engineer is comfortable editing deployment configuration and redeploying the web container. Harder work includes embedding meetings with the IFrame API, handling authentication, and enabling optional components, which touch several services and need testing. Your team should supply brand assets in usable formats, a named decision-maker, a staging deployment that matches production, a working HTTPS certificate, and the list of applications that will embed meetings.
Do Jitsi customizations survive upgrades, and how are they tested?
Customizations survive upgrades when they are kept as separate configuration and web assets applied on top of an unmodified release. They break when they edit upstream files. Keep custom work in version control, pin each release, and rerun the branding, embedding and optional component checks in staging before each upgrade. Confirm whether your deployment uses Docker images or Debian packages, because the upgrade steps differ. Also recheck browser compatibility after each release.
What should we confirm about transcription data handling with Jitsi?
Confirm where audio goes and who can access it, because the answer depends on the backend you choose. Jitsi's optional transcription can use Google Cloud, Vosk or Whisper backends. A hosted service receives audio outside your infrastructure, so check its terms, data retention, processing region and contract with the provider. For a self-run backend, confirm where it is hosted, what it logs, and where transcripts are stored. Set retention and access rules before enabling it, and tell meeting participants that transcription is active.
How DeployOpen delivers Jitsi customization
DeployOpen scopes, builds, tests and hands over Jitsi customization inside infrastructure you control, without forking the Jitsi Meet code. Branding, interface settings, IFrame API embedding and optional components are configured on top of a standard deployment so upgrades stay manageable.
How we scope
- Each engagement is fixed-scope, with the customization items, deliverables and timelines agreed in writing before work starts.
- The written scope lists which web interface, branding, interface and feature settings change, and which embedding pages call the IFrame API.
- Optional components such as Etherpad, Excalidraw whiteboards or transcription are scoped separately, with the backend and hosting choices confirmed first.
How we build
- Customization is applied through configuration and supported extension points, keeping the upstream jitsi-meet codebase unmodified where possible.
- Branding assets, interface options and feature flags are set in a version-controlled configuration that your team can review and reproduce.
- Embedded meeting pages are built against the IFrame API and tested in the browsers and devices your users rely on.
How we hand over
- Handover includes documentation of every customization, where it lives in the deployment and how to change it safely.
- Optional components are documented with their resource needs, network requirements and the Docker or package settings that control them.
- Your team receives a test checklist covering branding, embedding and component behavior to run after each future Jitsi release.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, covering customizations across Jitsi releases.
- Upgrade testing checks that custom branding, IFrame embeds and optional components still behave after each stable release.
- Confirm with DeployOpen which items a retainer covers, how upgrades are tested and how quickly issues are triaged before you sign.
