Apache OpenMeetings uses Java, database-backed state, and file storage for recordings/uploads.
Production configuration should prioritize secure auth, stable JVM settings, and storage planning.
¶ Main configuration scope
Core parameters are set in openmeetings.properties (and app server/JVM settings).
Example baseline:
dbType=mysql
dbUrl=jdbc:mysql://127.0.0.1:3306/openmeetings?useSSL=true
dbUser=openmeetings
dbPass=replace-with-strong-password
application.name=OpenMeetings
default_lang=en
files.path=/var/lib/openmeetings/files
¶ JVM and service tuning
- Set fixed min/max heap sizes appropriate for conference load.
- Enable proper GC logging for troubleshooting.
- Run service under dedicated non-root user.
- Keep Java runtime version aligned with OpenMeetings release notes.
¶ Access and room policy
- Enforce HTTPS and secure cookies.
- Separate roles for admins, organizers, and moderators.
- Require passwords for high-sensitivity rooms.
- Define recording defaults by room type.
¶ Storage and retention
- Keep file repository (
files.path) on persistent storage.
- Define retention policy for old recordings/uploads.
- Limit maximum upload size to prevent abuse.
- Export critical recordings before major upgrades.
¶ Backup and recovery
Back up:
- MySQL/PostgreSQL database
files.path content (recordings, uploads, room assets)- App server and OpenMeetings config files
Recovery test:
- Restore DB and file path to test host.
- Validate login, room join, whiteboard, and recording playback.
- Confirm scheduled cleanup still works after restore.
- JVM memory and GC behavior monitored.
- Database latency and connection pool health monitored.
- TLS certificate lifecycle automated.
- Incident runbook covers media failures and DB restore.
Feel free to contact us. Find all contact information on our contact page.