How to use self-signed certificates in offline environment?

[AoEiuV020]

Hi,

I'm trying to deploy openvidu-local-deployment in an air-gapped environment (no internet access). Currently facing an issue where Caddy fails to obtain certificates for HTTPS since it cannot connect to the internet.

I noticed the Caddy configuration is generated by a program called "local-caddy-generate".

Questions:

1. Is the source code for "local-caddy-generate" available?
2. Is it possible to configure it to use self-signed certificates instead of obtaining them from the internet?
3. Are there any alternative solutions for using openvidu-local-deployment with self-signed certificates in an offline environment?
4. Or are there any better deployment solutions specifically designed for air-gapped environments?

Environment:

• Using openvidu-local-deployment 3.0.0
• Air-gapped network environment (no internet access)

Thank you for your help!

[KazimirPodolski]

Is the source code for "local-caddy-generate" available?

I double this. The way OpenVidu currently hardcodes everything is a massive pain in adoption, at least for us. We already have a setup with caddy, redis and whatnot. But somehow OpenVidu assumes it's the most important part of the stack and wants the whole system for itself.

[cruizba]

@KazimirPodolski the idea of the openvidu-local-deployment is to allow you to develop locally only. For production environments you have other options: https://openvidu.io/latest/docs/self-hosting/deployment-types/ , for example the Single Node Community edition

There you can edit caddy config freely as you want at /opt/openvidu/config/caddy.yaml

We can make the caddy in the local-deployment available to edit if you think it would be useful. We intended to do it in this manner to not encourage the local-deployment option because its pure intention is local development.

We're open to suggestions anyway, what do you want to do exactly?

[KazimirPodolski]

@cruizba thank you for your answer. I'm just trying to add OpenVidu (replace Cloudflare Realtime actually) to our setup.

We have:

• docker-compose.base.yml which just enumerates eveything we have with basic configs, and services there are referenced from other composes
• docker-compose.local.yml for easy local development/testing
• docker-compose.develop.yml/docker-compose.staging.yml/docker-compose.production.yml
• docker-compose.preview.yml for per-branch preview deployments (think of Gitlab's Review apps)

I would say our setup is typical for web apps, the difference people have is usually is in the details. What's common is:

• a reverse proxy
• a compose file(s) with the app's infra

Basically, I would expect a docker-compose-friendly service to be able to be easily injected into something like

services
  db:
    image: mongodb:latest
  
  redis:
    image: redis:latest

  server:
    build: ...

  <OpenVidu goes here>

Now if you actually try to add OpenVidu (rather than just set up a standalone OpenVidu all by itself on a machine), the first thing you'll get following the docs is... "port is already in use" errors for redis/mongo/caddy. Because chances are people already have some/all of it in their setup. So here we come to the first big issue:

• OpenVidu's setup is super opinionated and the only easy way to set it up is to dedicate the whole machine to it. While people would expect the ability to throw OpenVidu's stuff into their dockers/composes

Next, in our case we use valkey instead of redis and it makes perfect sense to re-use it for OpenVidu. Normally I would just point the service to valkey:port instead of redis:6379. Here we have the second biggest issue:

• hosts and ports are hardcoded in configs

So as far as I see, a typical web app setup forces us to copypaste docker-composes and configs from containers built by OpenVidu's setup scripts and rewrite them (which I'm currently doing). Which is 1) less convenient than it could be, and 2) fragile. Then repeat the procedure of pulling configs on every update of OpenVidu...

To sum up, I believe setting up OpenVidu will be 5x easier if you shipped actual docker-compose files of the service, not docker-compose files of the service's installer.

[cruizba]

It really depends on the use case. Our approach right now is opinionated because:

1. There are multiple services and configuration between each other which are pretty complex without a global understanding of the WebRTC global context.
2. Installation complexity of an OpenVidu deployment (or any WebRTC realtime backend service) is not only in the docker compose, but on the myriad of configuration files that are interlinked together.
3. We want non technical people to be able to deploy OpenVidu without having to tweak anything.

I think we can sum up (at least part) of your issue in the following statement: "I already have a redis container running on my server, and I want OpenVidu to use that and not a different one". Is that possible? Yes. Is that as easy as changing one line of a docker-compose.yaml? Not quite. It currently requires modifying multiple files (because many services of the OpenVidu stack require connection to the redis). That's precisely one of the reasons why we work with an installer-guided deployment: orchestrating all the configurations and services in just a declarative way is hard manual work and error-prone.

[KazimirPodolski]

Nah, the core issue we have is that OpenVidu supplies usable service installation images while actual service images are treated as "internal" (not for users to meddle with).

I think open-sourcing openvidu/openvidu-installer might greatly help us users to work out the ways to install we need.

[KazimirPodolski]

I think we can sum up (at least part) of your issue in the following statement: "I already have a redis container running on my server, and I want OpenVidu to use that and not a different one".

Well, sorry, but no. Redis issue is just one of many issues which I believe anyone with some king of CI will face.

[cruizba]

I’m not opposed to your idea at all. We’re actively exploring ways to make the installation process both simpler and more flexible. In fact we are right now planning a better approach in the future, more pluggable and more friendly for git ops.

I’ll put this conversation on hold for now and discuss the possibility of open-sourcing openvidu-installer with the team. I’m not the Lead Developer, so I can’t make that decision myself.

That said, I’m very interested in your perspective. If we assume openvidu-installer didn’t exist, what approach do you think would work best?

Would a simple template or Ansible repository be enough? Or perhaps a straightforward docker-compose.yaml file with config files? (Similar to the openvidu-local-deployment)

I’d really appreciate your thoughts.

[KazimirPodolski]

Sorry I cannot help with those infrastructure-as-code things, haven't used any.

Or perhaps a straightforward docker-compose.yaml file with config files?

IMO that would be great by multiple reasons:

• It's easy to try and also easy to continue to more production setups
• It proves the ability of the software to be set up without complex platforms and/or much effort (I mean yeah docker is complex underneath but it's 2026 and pretty much anyone in the web are at least exposed to the thing); sort of "if it's simple it's probably designed well"
• (Not sure) It can serve as a foundation for infrastructure-as-code solutions (if they can "consume" docker stuff)

I'll share what setup we'll end up with when it'll run.

[KazimirPodolski]

Btw sharing openvidu/openvidu-operator would be nice too because from users point of view it's some magic glue which does who knows what, especially given the /var/run/docker.sock:/var/run/docker.sock.

[cruizba]

Btw sharing openvidu/openvidu-operator would be nice too because from users point of view it's some magic glue which does who knows what, especially given the /var/run/docker.sock:/var/run/docker.sock.

In the openvidu-local-deployment, the operator is only used to launch agents via the agent-*.yaml config files (at least in openvidu-local-deployment). See: https://openvidu.io/latest/docs/ai/openvidu-agents/speech-processing-agent/#1-ssh-into-an-openvidu-node-and-go-to-configuration-folder. In your use case, if you are not using AI agents you don't need it...

In production deployments (Single Node, Elastic and HA), the operator also handles environment variable interpolation across config files. This lets users manage global variables through openvidu.env while still having per-service config files... which is important because not all services expose their settings via environment variables, and config files make everything much more discoverable...

In Pro environments (Elastic and HA), the operator goes further and configures all services. In HA deployments, for example, it automatically sets up Redis and MongoDB for high availability with no manual intervention required and restart services automatically just by changing the config file and restarting the Master Node... It let users deploy in multiple machines with lower entry level (just basic Linux commands) without entering other concepts in play...

I understand your use case doesn't align perfectly with how things are structured right now, but we do have clients running these deployments smoothly and managing them without issues. That said, we need to discuss the docker-compose, and the open-source scenario internally... I'll let you know on any news, we just have right now other priorities. Open-sourcing the operator, (at least the community part), requires a bit of more work... We will discuss this too...

[KazimirPodolski]

I might be pushing to a little too purist approach than usually. In our current setup we have everything self-hostable, locally reproducible and CI-reproducible. So we have preview deployments for each git branch, which allows effortless testing of hypotheses, features development isolation, and so on... Basically the CI/CD it was meant to be in a perfect world.

The only missing piece was Cloudflare Realtime which we're currently trying to replace. Well, I guess we'll treat OpenVidu the same for now - as an exception from the rule)

[cruizba]

@KazimirPodolski

We decided to work on your request, we will try to have a less opinionated OpenVidu deployment based on plain docker-compose. Also, it is more friendly to GitOps workflow.

I'll notify you when it's available.

[cruizba]

@KazimirPodolski here is the repo with the instructions. It is available from 3.6.0: https://github.com/OpenVidu/openvidu-docker-compose-deployment

The caddy docker image is open source and all the config files and compose files are defined trying to be as friendly as possible with Docker Compose.