Apache OpenMeetings: self-hosted video conferencing with a whiteboard and groupware

One server for meetings, chat, whiteboard and shared documents

Apache OpenMeetings provides video conferencing, instant messaging, a whiteboard, collaborative document editing, and other groupware tools, all in one server.

That grouping is the point. Most of the alternatives in this space are a video component plus a separate chat, plus a separate collaborative editor, plus a separate file sharing, and the integration between them is where the work lands. OpenMeetings ships the whole surface, which is why the feature list reads as a set of checkboxes rather than a single headline capability.

The media layer is external and that is the single most important fact for an evaluator. It uses the API functions of the media server for remoting and streaming, Kurento. So OpenMeetings is not a self-contained conferencing application, it is a Java application server that talks to a Kurento media server over its API, and that media server is where the actual media flows through.

The repository layout reflects a multi-module Maven build: openmeetings-web/ for the web front end, openmeetings-webservice/ for the web services and the OpenAPI surface, openmeetings-core/, openmeetings-db/ for persistence, openmeetings-service/, openmeetings-util/, openmeetings-mediaserver/ and openmeetings-screenshare/, openmeetings-install/ for the packaged distribution, and openmeetings-tests/. The root pom.xml is the aggregator. The repository is a mirror of Apache OpenMeetings, it is licensed under the Apache Licence 2.0, and the last push was on 2026-10-20.

Building it is Maven with a profile, and the media server is separate

The prerequisites are short. To build, Apache Maven 3.10.0 or later. To run, Java SE 21. The build instructions in the project documentation are explicit about the order of operations.

First, ensure the prerequisites are installed. Then build the project using Maven in the root directory:

mvn clean install -PallModules

The allModules profile is what assembles the complete set of modules rather than the default subset, so a first build that produces an incomplete tree is usually a missing profile rather than a broken environment.

To run the result, you navigate to the openmeetings-server/target directory, extract apache-openmeetings-x.x.x.tar.gz, or the .zip for Windows, enter the apache-openmeetings-x.x.x directory and execute the startup script:

./bin/startup.sh

with ./bin/startup.bat used on Windows. So the build produces a distribution archive and you run it from the extracted directory, which means the deployment model is a directory on a machine with a startup script rather than a container image or a service unit that the project ships.

What is not in these instructions is the media server, and that is the gap to be aware of. The prerequisites list names Java and Maven; the Kurento media server appears as an API dependency in the feature description, and the release notes for 9.0.0 and 9.1.0 both carry the line that Java 21 and KMS 7.3.0 or later are required. KMS here means the Kurento Media Server, so the version floor for 9.x is a floor on the media server too, not only on the Java runtime. The installation guide linked from the project documentation is where that is spelled out in full.

The release notes are a security log, and they show the version floor moving

The release history in the project documentation reads as a running security log, and it is the most useful thing there for an adopter deciding on a version.

Release 9.1.0, dated 2026-07-14, is labelled Security. It adds more security checks in the whiteboard download service, protects the default git branches, updates all libraries to their most recent versions, and addresses one security vulnerability, with five other issues addressed as well. The note is that Java 21 and Kurento 7.3.0 or later are required.

Release 9.0.0, labelled Security, SIP and Dark theme, drops weak hash functions, makes the Remember Me feature more secure, updates all libraries, updates fabric.js for the whiteboard, adds a dark theme, fixes file deletion via the trash button click, addresses three security vulnerabilities and fifteen other issues. The same Java 21 and Kurento 7.3.0 requirement applies.

Release 8.1.0 updates all libraries and fixes whiteboard video player controls, with nine other issues addressed. Release 8.0.0 moves OpenMeetings to the Jakarta stack, uses Fullcalendar v6, and addresses one security vulnerability.

The trend across 9.0.0 and 9.1.0 is consistent: every release updates all libraries, and the theme of both is security hardening, from dropping weak hash functions to adding checks to a download service. The version floor has also moved twice inside the documented history. 7.0.0 required Java 17, 7.1.0 and 7.2.0 required Java 17 and Kurento 6.18.0 or later, and 9.0.0 onwards requires Java 21 and Kurento 7.3.0 or later. A deployment that upgrades the application without upgrading the media server in step will not work, and the release notes are where you find that.

The whiteboard is where the release notes spend their attention

Look across the documented releases and one subsystem keeps coming up: the whiteboard.

Release 8.1.0 fixed whiteboard video player controls. Release 9.0.0 updated fabric.js to its most recent version, fixed file deletion via the trash button click, and that release also brought a dark theme. Release 9.1.0 added more security checks in the WB download service. Release 7.1.0 fixed the TURN server configuration passing to the client, and release 7.0.0 added a full screen mode for the whiteboard, a redo tool for the whiteboard, and made the microphone on and off not interrupt the streaming.

That pattern is a signal about where the difficulty sits. The video conferencing is delegated to Kurento, and the application side of it is a matter of wiring API calls. The whiteboard is the part OpenMeetings implements itself, and the fixes above are the fingerprints of that: a drawing library with a breaking change to absorb, a file deletion path that needed a trash button, a redo tool that had to be built, a full screen mode, and a download service that needed hardening once someone pointed at it.

Two other details from those notes are worth extracting. The 7.0.0 release added 2-factor authentication, which is a security feature at the account level rather than in the meeting. And the 6.2.0 release, which is the first one with a fuller entry here, added an OpenAPI specification in 3.0.x format, a Swagger specification at openmeetings.apache.org/swagger, and improved integration examples for Node and PHP, along with an upgrade to Bootstrap 5 and a mobile version that improves the ability to start from the home screen on a mobile device.

That OpenAPI work matters for anyone building on top of it, and it is the reason the 6.2.0 entry is worth reading even though it is old.

The other groupware pieces, and the ones with their own history

The features that are not the meeting itself have their own release trails, and they are worth knowing about separately from the conferencing side.

Instant messaging is one of the headline capabilities, and 7.2.0 changed it in two ways that are easy to miss in a conference call but matter to an administrator: login and email are now processed in a case insensitive mode, and message folders are not shared between users. The second is a permission change, and it is the kind of fix that arrives quietly in a security release and then closes a hole where one account could see another account's message folders.

The 7.1.0 release hardened other paths. The invitation hash check was made strict, the set of user permissions was fixed, and paths entered in Admin and Config are verified. The last of those is a path traversal fix in the configuration UI, which is the kind of bug that matters most in an application that writes files on the server.

That same release is where the user interface work shows up as well. Release 7.2.0 resized too large profile pictures and made the room look better in right to left mode, and it made email messages look better. Release 6.3.0 fixed multiple whiteboard issues, unified confirm popups, and fixed multiple issues for the latest Safari.

The 6.1.0 entry is where the project documentation stops being detailed, so for anything older than that the CHANGELOG.md file at the root is the source to consult, as the readme says for a detailed log.

Where Apache OpenMeetings is the wrong tool

The first limit is the media server. OpenMeetings delegates media to Kurento, and a deployment is an application server plus a media server plus the configuration to make them talk. If your requirement is a small video call embedded in an existing product, OpenMeetings is far too much, and a WebRTC library or a hosted meeting API is the smaller answer.

The second is that the installation is not packaged for modern operations out of the box. The documented path is to build with Maven, extract a tarball or zip, and run a startup script from a directory. There is no container image or service unit in the instructions. A team that runs everything in containers will have to write that packaging themselves, and a team that expects a signed, updated binary to be downloadable is looking for something else.

The third is the version floor for the media server, which is a genuine operational coupling. Kurento 7.3.0 or later is required from 9.0.0 onwards, and the media server is a separate service on your network with its own lifecycle. Upgrading OpenMeetings means upgrading the media server in the same window, and the two have separate documentation and separate release schedules.

The fourth is the interface age. The 6.2.0 release upgraded to Bootstrap 5, and 9.0.0 added a dark theme, which tells you the front end has been modernising but is not a single page application in the modern sense. A team that needs a deeply embedded, customisable meeting experience inside its own design system will find the groupware surface opinionated.

The fifth is the scope of what is not here. There is no mention of a recording pipeline, no transcription, no translation, and no federated identity. The 6.2.0 release mentions SIP in the 9.0.0 title, which suggests a signalling path, but the documentation excerpt does not describe a recording or transcription feature at all, and a buyer should not assume one exists.

Editorial conclusion

Apache OpenMeetings is worth running for an organisation that needs to hold its own meetings rather than send them to a third party, because it ships the whole groupware surface in one server, it is Java and Maven with no exotic prerequisites, and the release line has been moving security work forward for years, with 9.1.0 addressing one vulnerability and 9.0.0 addressing three. It is the wrong tool if your requirement is a small embedded video call in an existing product, and it is the wrong tool if you cannot run a media server. Before you plan an installation, check the three things the project states about itself: that Java 21 and Kurento Media Server 7.3.0 or later are required from 9.0.0 onwards, which is the real deployment constraint since the media server is a separate service you have to run; that the build needs Apache Maven 3.10.0 or later and the allModules profile to assemble the whole tree; and that the Windows and Linux installers are separate archives with a startup script rather than a single cross-platform launcher, which is the operational detail that catches first time operators.

Frequently asked questions

Official sources

1. apache/openmeetings on GitHub
2. Issues
3. README
4. Releases