Jitsi whiteboard, notes and file sharing setup

The three add-ons attach to the Jitsi stack in different ways, and the difference determines what you configure and where you troubleshoot. The Excalidraw whiteboard and Etherpad document editing are switched on through settings in the .env file: WHITEBOARD_ENABLED enables the whiteboard, and ETHERPAD_URL_BASE tells the web app where Etherpad is reachable. Each feature also has its own compose file (whiteboard.yml and etherpad.yml) that you add to the deployment. The web container is the only part participants load in their browser, so the web app is the component that must know where the whiteboard and Etherpad live. File sharing is different because it is a separate service that the browser calls directly.

For Etherpad, the key value is ETHERPAD_URL_BASE, which is the address the browser opens when someone starts a shared document. Decide early whether Etherpad sits under the same domain as the meeting, behind the same reverse proxy, or on its own host name. Each choice changes certificate scope, DNS records and firewall rules. Participants' browsers must be able to reach that address over HTTPS, and the Jitsi handbook states that HTTPS with a proper domain certificate is necessary for working audio and video, so a self-signed certificate is not an acceptable shortcut here. Confirm the exact service names and proxy routes in the Docker guide for the release you run, because the layout can change between releases.

File sharing uses the config.fileSharing setting in the web configuration, which points the browser at the file service apiUrl. When a participant uploads or downloads a file, the browser sends the request to that service. The service does not trust the browser alone. It checks a short-lived token that Prosody issues for the meeting session, so the file service must be able to verify tokens from Prosody. Ask your team to confirm how the handbook example validates these tokens, how long they last and which secret or key the two services share, since those details decide whether the service rejects expired sessions and how you rotate credentials.

The handbook's file sharing example stores uploads on the local filesystem of the file service host, and the reverse proxy sets a client_max_body_size of 50M on the upload location. That limit is a proxy decision with a direct effect on users, so change it only when you have agreed the largest file the meeting should accept. The local disk is also the only copy of uploaded files in the example, which makes that host a data store you must back up, encrypt at rest and include in retention rules. Before go-live, test an upload and download from a real browser session, confirm the token check rejects an expired session, and restore a test file from backup.

Before you enable any of these add-ons, map where each one keeps its content. The answer differs by component, and none of it falls under the protection Jitsi applies to the video stream. Jitsi states that audio and video are encrypted on the network with DTLS-SRTP and that the videobridge decrypts packets in memory while routing and never stores them. Whiteboard drawings, shared document text and uploaded files are created outside that stream. Their protection depends on the storage, access controls and transport settings you choose for each service, so they need their own entries in your data inventory and your backup and retention policies.

Uploaded files are the easiest of the three to locate. Jitsi's file sharing uses a separate file sharing service. The example service in the Jitsi handbook stores uploads on the local filesystem and authenticates requests with short-lived tokens issued by Prosody. Identify the host and the exact directory or volume that receives uploads, confirm it sits on storage you back up, and include it in your backup scope. The handbook's example also sets client_max_body_size to 50M in the nginx location for the service, which caps what can reach that directory. Confirm the value you use, because it determines the largest file your users can place on your storage.

Etherpad and Excalidraw need a different kind of check. Jitsi enables Etherpad with ETHERPAD_URL_BASE and the etherpad.yml compose file, and enables the Excalidraw whiteboard with WHITEBOARD_ENABLED and the whiteboard.yml compose file. The supplied Jitsi material does not describe where either tool persists content, which database or volume it uses, or whether content remains after a meeting ends. Confirm these points in the current Etherpad and Excalidraw documentation and in the compose files you deploy. Identify which container holds state, which volume or database it writes to, and whether an export or deletion path exists. Until you have confirmed these answers, treat the location of this content as unknown.

Use those answers to set your backup and retention scope. Back up the upload directory and the file service configuration, the Etherpad and whiteboard data locations you confirmed, and the .env file and compose files that define them. Since the official Docker containers run rootless with read-only filesystems, check which paths are writable volumes, because content written elsewhere will not persist. Write a retention rule for each data type and assign an owner who can delete content on request. Test a restore of all three data sets, not only the video configuration, before you rely on the backups.

Meeting notes and uploads often contain personal or regulated information, so ask your privacy and compliance leads whether this content falls under existing records or data retention rules. Ask the vendors or community maintainers for written confirmation of storage behavior for the versions you deploy. Ask your own team who can access each volume, how access is logged, and how long old copies remain in backups after content is deleted from the live service. Those answers, not the video encryption settings, determine how well these three features fit your regulated meetings.

Most of the one-time cost for these add-ons comes from deploying and configuring each one as a separate service beside the core Jitsi stack. Whiteboard is enabled with WHITEBOARD_ENABLED and the whiteboard.yml compose file, Etherpad with ETHERPAD_URL_BASE and the etherpad.yml compose file, and file sharing needs its own service, an apiUrl entry in config.fileSharing, and an nginx location with client_max_body_size set to 50M. Each one adds configuration, hostnames, reverse proxy routes and testing across browser and mobile clients. Ask for each add-on as its own line item so you can drop one later without reopening the others.

Storage and backup work is where these add-ons differ most from the base install. Whiteboards, shared notes and uploaded files all create data you must keep, secure and restore. The example file sharing service stores uploads on the local filesystem, so the work includes sizing that volume, choosing where it lives, setting retention and deciding what restoring one meeting's files looks like. Confirm where Etherpad and the whiteboard persist their content in the versions you plan to run, because that sets the backup scope. Each store needs a documented, tested restore, not only a scheduled copy.

Each new service also adds an access path, and the security review grows with the number of paths. The file sharing service authenticates with short-lived tokens issued by Prosody, so the review should trace how those tokens are validated, who can upload, which file types and sizes are accepted, and whether the upload endpoint is reachable from the public internet or only from the meeting domain. Documents opened from a room URL raise the question of who can read or edit them without signing in. Check which new containers run with the rootless, read-only settings the Docker setup uses and document every place an add-on departs from them.

Recurring work grows with each container. Every add-on is another image to track against Jitsi's stable release tags, another set of environment variables to carry through upgrades, and another service to retest after a platform update. Plan recurring effort for patching, confirming that upload limits and proxy routes survive each upgrade, restoring a backup into a test environment on a schedule you set, and reviewing logs for file sharing errors. These tasks continue after go-live, so the support terms matter as much as the build price.

A quote should list each component by name and version, the environments it covers (test, staging and production), the storage volumes and backup scope for every stateful add-on, the access paths and the review you expect, and the testing approach, including restore tests and browser checks on desktop and mobile. It should also include handover documentation and the support terms for updates after go-live, and state whether the figures cover retesting after platform upgrades. A quote that names only Jitsi itself is missing most of the work described above.

Test the whiteboard, shared notes and file sharing in staging before any user depends on them, and write the test plan first so that everyone agrees on what counts as a pass. Start with enablement. Confirm that WHITEBOARD_ENABLED is set for the whiteboard, that the whiteboard.yml compose file is included in the deployment, that ETHERPAD_URL_BASE points at the Etherpad instance and that etherpad.yml is in use. Check the running web client as well as the .env file, because a setting that is written but not picked up by the containers is a common cause of a feature that appears missing to users.

Next, run a meeting with two or more participants on separate browsers or devices. One participant should open the Excalidraw whiteboard and draw, a second should edit the Etherpad document, and a third should upload a file during the call. Confirm that every participant sees the same whiteboard content and document text, that an edit made by one person appears for the others without a page reload, and that the uploaded file can be opened by everyone in the room. Repeat the run from at least one mobile client, since certificate problems often show up there first.

Then test persistence and limits. Restart the containers that serve each add-on, reopen the meeting and confirm that the whiteboard scene, the Etherpad document and the file list all load with their previous content. Next, check upload limits. The Jitsi handbook's file sharing example sets client_max_body_size to 50M in nginx, so upload one file just under your configured limit and one just over it, and confirm that the large file is refused with a message users can understand. Confirm your own limit with your configuration, since the example is not a recommendation for your environment. For token expiry, confirm the lifetime of the short-lived tokens Prosody issues to the file sharing service in your setup, wait until a token has expired, and check that the expired token is refused and that a fresh session obtains a new one.

The last check is recoverability. Back up the file sharing upload storage, the Etherpad data and the whiteboard data, restore them to a separate staging host and confirm that the restored files download with the same contents, and that the restored documents and whiteboards open with their last saved state. Confirm with your deployment team where each add-on keeps its data, because the uploads sit on the local filesystem in the example service and the storage for the other two depends on how they are deployed. Record every test with the date, the Jitsi build in use, the configuration values tested, the tester, the result and the evidence, such as screenshots or logs. Agree the full scope, the test cases, the environments and the acceptance criteria in the written plan before testing starts, so that a failed case has a clear owner and a clear decision attached to it.