`yarn dev` in production dockerfiles?

[AndrinGautschi]

Hi,

I'm currently trying to setup edumeet for testing purposes in a Kubernetes cluster. Unfortunately, there is no documented case of someone doing this and that might be the reason why it feels like I'm struggling throughout the whole process. Given that I might have something completely misunderstood, here's my issue:

Since I have no interest in hosting another proxy in my cluster besides the main one already in place, my approach is to let my already existing traefik handle the work nginx does in the docker-compose setup. This means that I have an ingress-route deployed, and separate deployments for each component (management-server, client, media-node, ...). The problem I'm facing right now does not arise from that though, but rather from the docker images themselves, particularly that one from the management-server.

In the Kubernetes community, usually one can rely on the fact that the docker images provided are intended for production use. As far as I can see, this is not the case here. Clearly, a yarn dev as entrypoint in the image seems misplaced (dockerfile, latest build on dockerhub does the same, as well as the most up to date build on dockerhub). Besides the antipattern to deliver files with the dev tool nodemon (yarn dev executes this command), this causes issues in Kubernetes. Since nodemon creates file-watchers to trigger server reloads in a dev environment, when I try to run that image in my cluster, the container breaks with Internal watch failed: EMFILE: too many open files, watch '/usr/src/app'. I could raise the bar of open filewatchers, but this would not solve the underlying issue that I don't need to watch files if I run the image as a 'production' workload (that has no interest at all to in file changes and server-reloads).

The main issue I'm trying to wrap my head around is that I simply don't understand why you start the container with yarn dev when you have the proper production ready command start already in place. Are these images intended for dev usage only? Shouldn't they, then, be labeled as 'stable-dev-build' or something alike? The current naming scheme '4.1-20250926-stable' seems very misleading.

Help or some general guidance would be greatly appreciated. Thanks :)

[N7Remus]

Thank you for your feedback!
It was an oversight on my part. (I use edumeet-docker for development as well, and reloading changes on the fly was usefull)
I will update it on the next release to use the proper start.

[AndrinGautschi]

Thanks for the fast reply. Do you already know when you're going to release a patched version?

[N7Remus]

It is fixed in a few seconds (in version 4.1-20250930-stable ).

[AndrinGautschi]

Nice, thanks a lot! I will check it out in the next couple of days. Depending on whether we invest more work and actually start using it, I'd be willing to contribute some simple readme with guidance on how to deploy it in a kubernetes environment, given you want that. But I can't yet promise anything.

Btw: If this project is intended to be used like any other opensource project, a good way to get the interest and participation of the community would be to list it on awesome-selfhosted (github project).

[N7Remus]

We have a few test instances that are running from kubernetes already.

I have a somewhat working config for it, but the networking is a bit difficult for the media node + turn. (The part where we have to document it is difficult, not the actual configuration)
I made it public here: https://github.com/edumeet/edumeet-k8s

Note: Components do no care about changes in enviroment states/configmaps/files at the moment, if you want to change the config you will have to restart the pods.