Local recording no longer works with TOOLBAR_BUTTONS=recording after upgrading from stable-8319 to stable-10532-1

[dhelly45]

Description
Hi,
I’m experiencing a regression related to local recording vs cloud recording after upgrading Jitsi Meet.

---

Environment
• Old version: stable-8319
• Current version: stable-10532-1
• Deployment: Docker (jitsi/docker-jitsi-meet)
• Config method: .env + custom-interface_config.js
• Jibri: Running (but cloud recording is not desired)

---

Expected behavior (stable-8319)
In stable-8319, the following setup was sufficient:
TOOLBAR_BUTTONS=...,recording
With this configuration:
• The recording button was visible
• Clicking it allowed local recording only
• No cloud recording / Jibri was triggered
• No need to set ENABLE_RECORDING=1
This behavior matched our requirements perfectly.

---

Actual behavior (stable-10532-1)
After upgrading to stable-10532-1:
• Adding recording to TOOLBAR_BUTTONS is no longer sufficient
• The recording button only appears if:
ENABLE_RECORDING=1
However, when ENABLE_RECORDING=1 is enabled:
• Local recording is no longer available
• The UI switches to cloud recording only
• Recording attempts require Jibri
• Local download recording cannot be started
This forces cloud recording, which we do not want.

---

Problem summary
• In older versions, TOOLBAR_BUTTONS=recording enabled local recording
• In newer versions, ENABLE_RECORDING=1 seems mandatory
• ENABLE_RECORDING=1 implicitly enables cloud recording
• There is no clear way to:
o Enable local recording
o While disabling cloud/Jibri recording
o Using only .env + interface config

---

Question
How can we achieve local recording only (no cloud recording, no Jibri dependency) in stable-10532-1?
Is this:
• an intentional breaking change?
• a missing configuration option?
• or a regression compared to stable-8319?
Any guidance or recommended configuration would be appreciated.

[jmallach]

What browser are you using?

[dhelly45]

Google Chrome
Version 144.0.7559.60 (Official Build) (64-bit)

[damencho]

By default localrecording is enabled:

docker-jitsi-meet/web/rootfs/defaults/settings-config.js

Line 207 in ed30d0d

config.localRecording = {

and you don't need ENABLE_RECORDING for it.
Do you see the localrecording config in your config.js when served from the web?

[dhelly45]

We are using .env and custom-interface_config.js for configuration.

For local recording, the only related setting we apply is in the .env file:

TOOLBAR_BUTTONS=microphone,camera,desktop,closedcaptions,fullscreen,participants-pane,toggle-camera,tileview,settings,recording

Apart from this, we are not applying any additional local recording–specific configuration.

When we check the served config file at
https://xx.com:7913/config.js the local recording section is present and looks like this:

// Local recording configuration.
config.localRecording = {
disable: false,
notifyAllParticipants: false,
disableSelfRecording: false
};

So config.localRecording is clearly enabled and visible in the generated config.js, and we are not using ENABLE_RECORDING.

[damencho]

Is there a change if you use toobarButtons from config.js which is the recommended way of configuring that?
https://github.com/jitsi/jitsi-meet/blob/ab4be2366f7b902e649d5e35fd93d17e8b4d004f/config.js#L851

[dhelly45]

I tried following the recommended way by removing the TOOLBAR_BUTTONS variable from the .env file to let the system use the defaults from config.js. However, the 'Start Local Recording' button still does not appear in the UI.

When I set ENABLE_RECORDING=1 in the .env file, the UI changes as shown below, but it still doesn't solve the issue for Local Recording.

[damencho]

How are you opening the meeting via iframeAPI or directly in the browser?
You can use iframeAPI only if the iframeAPI is loaded in the same domain as the meeting itself in the browser.

[dhelly45]

iFrame API React SDK tools. As I said, in stable version 8319, the TOOLBAR_BUTTONS=...,recording link inside the .env file was sufficient. I encountered problems when upgrading to stable version 10532-1.

[damencho]

What about the origin that I asked?
Release 8319 is 3 years old and many things changed since then. For example local recording is no longer stored in the memory of the browser, it uses filestorage API to save it on the filesystem directly, but that comes with the drawback that you cannot use it in iframeAPI if not using the same origin of the page, which is a browser limitation.

[dhelly45]

Thank you for the explanation. That makes perfect sense. My main application is running on port 443 and Jitsi is on port 7913. Since they are on different ports, they are treated as different origins, which explains why the FileSystem API is blocked in the iframe.

To resolve this, should I set up an Nginx Reverse Proxy to serve both my application and Jitsi from the same domain and port (e.g., domain.com and domain.com/jitsi)? Would unifying them under a single origin (same port/domain) satisfy the browser's security requirements and enable the Local Recording button?

Also, is there any other way to bypass this 'Origin' restriction while keeping them on different ports, or is a proxy/unified origin the only way to support Local Recording in a modern browser environment?

[saghul]

To resolve this, should I set up an Nginx Reverse Proxy to serve both my application and Jitsi from the same domain and port (e.g., domain.com and domain.com/jitsi)? Would unifying them under a single origin (same port/domain) satisfy the browser's security requirements and enable the Local Recording button?

Yes, that should work. Note that we don't quite recommend using subdirectories since that is a scenario we don't test. If you use domains, having different subdomains with the same parent should do: meet.example.com for jitsi and app.example.com for your main app.

Also, is there any other way to bypass this 'Origin' restriction while keeping them on different ports, or is a proxy/unified origin the only way to support Local Recording in a modern browser environment?

It's a browser limitation.

[dhelly45]

In the latest stable releases (e.g., 10532-1), Local Recording requires the FileSystem API, which enforces a strict Same-Origin policy. This prevents the 'Start Local Recording' button from appearing when Jitsi is served on a different port (e.g., 7913) than the parent application (e.g., 443) via iframeAPI.

While I understand this is a browser-level security restriction, many embedded setups (like those using Tomcat or separate app servers) cannot easily unify origins without complex proxy configurations.

Suggested Improvement: Could an option be added to .env or config.js to fallback to the old Memory-based (Blob) recording method (as used in version 8319)? This would allow users in cross-origin environments to still use Local Recording, even if it lacks the 'persistence' benefits of the FileSystem API.

Currently, it's 'all or nothing', which breaks local recording for many iframe-based integrations.

[damencho]

Suggested Improvement: Could an option be added to .env or config.js to fallback to the old Memory-based (Blob) recording method (as used in version 8319)?

That does not exist in the code so there is no fallback to it, sorry.

[dhelly45]

Thank you for the detailed explanation regarding the FileSystem API and the Same-Origin Policy constraints. It’s clear that the modern implementation is superior for stability and preventing memory-related crashes.

However, many of us integrate Jitsi via iframe in complex enterprise environments where unifying origins (via reverse proxy) is not always feasible due to strict infrastructure policies or cross-departmental domain management.

Since a fallback to the old Memory-based (Blob) method is not an option in the current codebase, could we consider a "PostMessage Bridge" approach for future iterations?

The idea: In a cross-origin iframe scenario, Jitsi could emit the recording chunks (blobs) via the postMessage API to the parent window. The parent application (which is in a top-level context) could then receive these chunks and handle the saving/downloading process.

This would:

Bypass the FileSystem API origin restriction for the iframe.

Keep the Jitsi core "memory-light" as it offloads the storage responsibility to the parent app.

Provide a standard way for developers to support local recording in embedded scenarios.

Is this something the team would be open to exploring, or perhaps accepting a PR for? It would bridge the gap for many users currently stuck on versions as old as 8319 just to keep the recording feature alive.