update cycles?

I’ve seen that the latest version that is available in the App Center is rather dated. 3.14 was released a few days ago. Skimming through the support forum, I’ve found out that the question for updates came up a few times in the past already.

Do you have a (internal) policy on when the app is sync’ed to the latest release?

Thanks for a short clarification.

Kind regards,


Yes, I would be interested in that as well.

I just changed the Docker-Compose to have the newest Version.

cd /var/lib/univention-appcenter/apps/rocketchat/compose
nano docker-compose.yaml

change image line to: image: "rocketchat/"

activate changes

Run this commands onces

cd /var/lib/univention-appcenter/apps/rocketchat/compose/
docker ps
docker stop ROCKETCHATID
docker stop MONGODBID
docker rm rocketchat_rocketchat_1
docker network rm rocketchat_appcenter_net
docker-compose down
docker network prune
docker-compose up -d


every time you want to updates

cd /var/lib/univention-appcenter/apps/rocketchat/compose
docker pull rocketchat/
docker-compose down
docker-compose up -d rocketchat

But then u cant use the UCS Appcenter Updater for anymore. You still keep the ldap/saml settings and settings in UMC.

Use on your own risk. But we were annoyed about the updates on with this solution we kept all data and are always up to date. We are running this solution abount 6 months now with no issues.

Edit: You also could just setup your via docker on your own but we liked the pre settings an possibility to enable the App on user import


Thanks, @crunch for your helpful suggestion. Nevertheless, we are hoping for an official statement on an officially supported app from the app center. What’s the use of an automated update system that doesn’t do its job correctly?

Perhaps it really is some kind of known security bug that is holding Univention back. But then again, so many security fixes have been issued this year alone that it is highly recommended not to use the “official” version from the app center. Amongst then really nasty XSS vulnerabilities:

I have not done this with Rocketchat, but generally speaking there are better ways than to modify the compose file and using a mixture of docker and docker-compose commands.

  1. when the app is started through univention this is done my passing a “project name” that does not match the name of the folder. Therefore when doing a docker-compose ps inside of the folder these containers do not show. To fix this simply create a file called .env inside of /var/lib/univention-appcenter/apps/rocketchat/compose. The file needs to have the following content:
  1. modifying docker-compose.yml means that changes done will be lost when there is an update of the app. Docker-compose has a mechanism called override files that will prevent changes getting lost. So just create a file called docker-compose.override.yml in the above directory with the following content:
version: '2'

    image: rocketchat/

Afterwards you can just do a docker-compose pull && docker-compose up -d to update and start your new container.

  1. I would not use :latest personally, but rather a defined tag. But that does not mean that you need to lose ease of use. The version of a container could be stored in a variable in the .env file as well and with a small piece of bash you could automatically get their newest tag and store in back in the .env file.

The following command gives you their latest non development tag: git ls-remote --refs --tags | grep -v 'rc\|develop' | sort -t '/' -k 3 -V | awk -F/ '{ print $3 }

Check to see how I am getting the newest tag for my Lightmeter app.


Would this work the same way for other apps?

This has worked perfectly:

CONTAINER ID        IMAGE                                                  COMMAND                  CREATED             STATUS              PORTS                     NAMES
ee36ad3c8db3        rocketchat/                          "docker-entrypoint.s…"   3 minutes ago       Up 3 minutes>3000/tcp   rocketchat_rocketchat_1
7cf5bc2ea21b   "docker-entrypoint.s…"   3 months ago        Up 45 seconds       27017/tcp                 rocketchat_mongo_1

Should we then do the same with MongoDB?

Yes, unless a custom docker container is used for the ucs app this should work for all apps that use docker-compose. Also not only to change versions, but also to specify additional configuration. I recently explained how to use this method to add additional settings to Kopano Meet. The only thing that you cannot do with an override is removing values.

But: proceed at your own risk :wink:

Since the database is not globally reachable I would just keep it as it is.

1 Like

We have become very cautious in the meantime. Rocket.Chat releases new versions so often that we have already had problems several times. Now we write a version (of a testet Release) in the docker-compose-file for users of Rocket.Chat in EGroupware installations and no longer take every version with us.

Especially for updates with database update there is no downgrade anymore (without database backup).

We always publish an explicit reference to the database version:

Ultimately, however, every admin can also write in other versions or just latest/stable and then install the new container. Proceed as described above.

EGroupware Community Manager

1 Like

As you are either looking for alternatives or have implemented different update solutions, @StefanU, @fbartels, it seems like you are not very confident that this issue will be solved by Univention? :-/

It not entirely on Univention to be honest, but on the app provider (which is Rochet Chat itself) to submit newer versions. My intention was not to provide an alternative update solution, but simply to provide a cleaner approach to the workaround given by @crunch.

I wanted to say first of all that with Rocket.Chat it is difficult to publish a version that is stable enough and does not cause problems in any environment. The development is too dynamic for that.

But it is true that updates are necessary just because of the security fixes. That is why we also release updates for EGroupware.

Because of new functions, most users who “only” want to chat do not always need the latest version.

We provide Rocket.Chat as an installation option for EGroupware own installations. For EGroupware on UCS one then uses/integrates UCS-Rocket.Chat.
In this respect, we have not looked for an alternative solution but can do both.

We provide containers (for EGroupware installations):
Test it for a few days and then release it as stable.

If Univention builds/maintains the package: Yes!
Otherwise, Rocket.Chat has to take care of itself.
I don’t know exactly what the constellation is…


It seems like the integration was actively pushed by @gulden back in 2019, he even posted a promotional blog entry on the topic back then.

Unfortunately it is not clear which of the two parties, or Univention is responsible for keeping stuff up to date. A similar bug report was closed a few weeks ago for formal reasons on’s github.

I guess we will have to wait for an official statement.

Thanks for you support!

We will probably ban Rocket Chat from UCS for us and for all customers. That would work with Docker, but it would take us away from UCSapps again. So it will either be removed completely, or we will set it up again with Ubuntu and Snap on its own machine. Hopefully there will be updates soon. In the meantime, RocketChat is probably as full of holes as a Swiss cheese.