Title: OpenVidu 3.4: app module enabled but / still serves OpenVidu Meet (Overview). How do I make my app the root?
Body:
Environment
Single-node, own certificates
OS: Ubuntu 24.04.3 LTS
OpenVidu images (from docker ps):
openvidu/openvidu-server:3.4.0
openvidu/openvidu-operator:3.4.0
openvidu/openvidu-meet:3.4.0
openvidu/openvidu-caddy:3.4.0
Custom app image: evigils/ov-landing:2 (HTTP on port 5442, host network)
Goal
Serve our own landing app at / and keep OpenVidu Meet available (ideally under /meet). This worked in 2.x with a custom landing.
What I configured
/opt/openvidu/docker-compose.override.yml (app service only shown):
services:
app:
image: evigils/ov-landing:2
network_mode: host
restart: on-failure
environment:
Local health check:
curl -s http://127.0.0.1:5442 | head -n1
=> (our app is serving fine)
But the external root still serves Meet:
curl -s https:/// | head -n3
=> HTML from OpenVidu Meet (title “OpenVidu Meet”)
In Chrome DevTools (Disable cache + “Empty cache and hard reload”):
The Document is overview and even fetch(‘/index.html’, {cache:‘no-store’}) returns the Meet HTML, not our landing.
So it looks like the reverse proxy keeps mapping / → OpenVidu Meet even though the app module is enabled and serving on 5442.
What I expected
Docs suggest that with ENABLED_MODULES=app,… OpenVidu should expose the app at the root, while other modules are available under their paths. That’s what we want (root = our app; Meet under /meet).
Questions
In 3.4, what is the supported way to place OpenVidu Meet under a subpath (e.g., /meet) so the app can own /?
Is there a recognized env var like MEET_BASE_PATH=/meet or PATH_PREFIX=/meet for the openviduMeet module?
Which file should it go in (/opt/openvidu/config/openviduMeet.env or elsewhere)?
Is module order in ENABLED_MODULES significant for routing priority? (We tried app,openviduMeet,observability.)
Does the operator need an extra step to re-generate routing after changing modules (beyond systemctl restart openvidu)? Any cache we should clear?
Is there a known issue in 3.4.0 where / remains mapped to Meet even with app enabled? If so, any official workaround (without editing Caddy manually)?
Extra info (if helpful)
Operator env shows it sees the modules:
docker compose exec operator sh -lc ‘printenv | grep ENABLED_MODULES’
=> ENABLED_MODULES=app,openviduMeet,observability
Meet REST API at https:///api/v1/rooms works fine with our API key.
We can confirm our app image is rebuilt and running (host network, 5442).
Thanks for any guidance or a pointer to the correct knob to move Meet under /meet so the app owns / per the intended design.
No, AFAIK it is not possible to deploy OpenVidu Meet in a different path, I’ll cc just in case it is possible @pabloFuente@CSantosM
No, it does not affect. Right now we consider “OpenVidu Meet” as the default application. If you want to serve your own Application, OpenVidu Meet will be disabled. The option you want is not possible AFAIK.
No, It just generates all needed config files with systemctl restart openvidu, no cache involved, the service itself clean and prepare config files for the services.
I think so, we did not considered the main application to be deployed in the same machine as OpenVidu deployment , but I think it is very important and it should be considered as a bug.
As a workaround you can consider these 2 options:
Deploy your app in a different machine until we think for an strategy to handle both apps in the same machine.
Tinkering with the caddy.yaml config file. Technically it should be possible to deploy the app if you use a different domain name and expose your app in a port so caddy can reverse proxy those requests to your app.
Thanks for the quick clarification and for confirming the current behavior—super helpful.
Given that OpenVidu Meet is the default application at / and can’t be placed under a sub-path right now, we’ll proceed with a separate small VM and domain for our public landing (e.g., https://start.evigils.com). That landing will call the Meet REST API server-side on https://video.evigils.com (using the API key) to create or fetch rooms, and then redirect users to the moderatorUrl or speakerUrl provided by the API. This lets us keep our simple “Room + shared password → Join/Create” flow without exposing the admin console.
Two confirmations if you don’t mind:
Are the /api/v1/rooms endpoints (and the returned moderatorUrl / speakerUrl) considered stable across 3.x?
Any security best practices you recommend for this pattern (API key handling, rate limiting, etc.)? We never expose the key to the browser—only server-side.
As a feature request: if/when you add a hook for a custom landing at / (while keeping Meet enabled at a configurable base path), we’d adopt it immediately.
Thanks again to you and the team—Meet is an excellent showcase of what OpenVidu can do.
We follow semver and /api/v1/rooms endpoint will not suffer breaking changes during 3.X. This doesn’t mean we can’t refine the API endpoints, deprecating properties/methods or adding new ones as we iterate, but you will have the security of API’s not breaking as long as the major version does not change.
As long as you keep your API Key safe in your servers (both in your OpenVidu deployment servers and your custom application server), this strategy should be completely secure. The main advice is not sending any sensitive data to your frontend app, just as in any other web application architecture.
We will give some thoughts to the possibility of changing the path to serve OpenVidu Meet, so replacing it with a custom app is much easier. This is an interesting feature that clearly aligns with our customers interests, and we will think about it in detail.
, but I think it is very important and it should be considered as a bug.