Since the release of UCS 4.1 in November 2015, the App Center has supported Docker apps. These are applications in the form of Docker images that are deployed by the App Center in a Docker container. To do this, the App Center downloads the Docker image of an app and starts the Docker container. We call these apps “Single Container Apps” because the App Center only supports one container per app. This functionality is sufficient for many apps.

Until now! The app landscape is constantly changing and new app candidates like Rocket.Chat, Metasfresh and Zammad no longer consist of just one container. These apps are called “Multi Container Applications”. In order to fulfill the wish of many of our users to also find such apps in the Univention App Center and run them on UCS, the App Center now supports Multi Container Apps with the UCS 4.3 errata update 345, thus creating the necessary prerequisites.

A common approach to container virtualization, as implemented by Docker, is to provide individual services in individual containers. Probably the most common use case is the separation of application and database, such as Rocket.Chat. The number of containers is not limited to two, as Metasfresh shows.

Container am Kran

If you want to learn more about the Docker technology itself, we recommend this short introduction:

Brief introduction: Docker

Multi Container with Docker Compose

Docker Compose, which is also used in the App Center, is used for multi-container applications in the Docker environment. Central element is the docker-compose.yml file. For Rocket.Chat it looks like this:

version: '2'
 image: rocketchat/
 restart: unless-stopped
 - ./uploads:/app/uploads
 - PORT=3000
 - ROOT_URL=http://localhost:3000
 - MONGO_URL=mongodb://mongo:27017/rocketchat
 - MONGO_OPLOG_URL=mongodb://mongo:27017/local
 - MAIL_URL=smtp://
 - mongo
 - 3000:3000

 image: mongo:3.2
 restart: unless-stopped
 - ./data/db:/data/db
 command: mongod --smallfiles --oplogSize 128 --replSet rs0 --storageEngine=mmapv1
 # this container's job is just run the command to initialize the replica set.
 # it will run the command and remove himself (it will not stay running)
 image: mongo:3.2
 command: 'mongo mongo/rocketchat --eval "rs.initiate({ _id: ''rs0'', members: [ { _id: 0, host: ''localhost:27017'' } ]})"'
 - mongo

 image: rocketchat/hubot-rocketchat:latest
 restart: unless-stopped
 - ROCKETCHAT_URL=rocketchat:3000
 - BOT_NAME=bot
 - EXTERNAL_SCRIPTS=hubot-help,hubot-seen,hubot-links,hubot-diagnostics
 - rocketchat
 - ./scripts:/home/hubot/scripts
 - 3001:8080

These files in YAML format define various services. These services specify which Docker image to use and which environment variables, volumes, ports, and dependencies to other containers are required. In its entirety, it describes an application with all its parts that are started using Docker Compose.

Docker Compose configuration using the Zammad application as an example

App providers can store their Docker Compose configuration in the App Provider Portal, as the screenshot of Zammad shows.


App providers can store a whole range of configuration settings for the app in the provider portal. This also includes scripts that are executed at different stages during the app lifecycle in the container and on the host.

For Multi Container Apps, it must be specified which of the defined services or containers is the main service so that the App Center knows to which these scripts and some configurations have to be applied. As a rule, the main service is the container containing the application.

Possible changes of the Docker Compose file by the App Center

Before a Multi Container App can be put into operation on the user’s target system via Docker Compose, the docker-compose.yml is directly processed by the App Center on the UCS system and some points are changed or added.

  1. The App Center adds two standard volumes for the main service, as they are also included in Single Container Apps. These are the /var/lib/univention-appcenter/apps/<appid>/data and /var/lib/univention-appcenter/apps/<appid>/conf directories on the UCS host. If volumes are also defined in the App Provider Portal in the app Configuration, these are also supplemented in the Docker Compose file by the App Center for the main service.
  2. If ports are defined in the App Provider Portal, they will also be added in the Docker Compose file. Already defined ports are still valid. If the same port is defined in the portal and in the Docker Compose file, the configuration in the App Provider Portal takes precedence. For example, if the Docker Compose file states that port 4500 is provided externally as port 4500, but the Portal defines that this port is to be used as 6500, the Docker Compose file will be modified to map port 4500 to 6500 on the host.
  3. Another special feature is the specification of the web interface. If the Docker Compose file specifies that port 80 or 443 should be opened to the outside and the app configuration specifies that these ports should be used by the App Center for the web interface, the App Center will specify a port on the fly on the target system and specify it in the Docker Compose file. This is because UCS hosts usually occupy ports 80 and 443 with a web server. The App Center creates an Apache Reverse Proxy configuration so that the app can be reached via a URL of the form https://hostname.domain/appid/.
  4. Docker containers like to use environment variables. Docker apps on UCS also make use of this and UCS provides a number of environment variables via the App Center, such as parameters for an LDAP connection. The necessary variables are also written to the Docker Compose file.
  5. Furthermore, in the main service, as in Single Container Apps, all UCR variables defined on UCS are available under /etc/univention/base.conf, as well as the password for the so-called machine account under /etc/machine.secret, via which the main service has authenticated read access to the LDAP directory.
  6. When a multi-container app is released, the Docker Compose file is adapted on the server side and the Docker Image information is modified to point to the Docker images in the Univention Docker registry. All Docker images from published apps are copied to the Univention Docker registry to be independent of the Docker infrastructure. This is the only server-side change to the Docker Compose file.

As a result, Docker Compose starts a Docker Compose configuration on the target system that no longer matches 100% of the app vendor’s input. This is necessary because a lot of information must be available at the start of an app for optimal integration. Thus, the apps can adjust to the local environment and preconfigure themselves accordingly, so that users can start immediately. The modified Docker Compose file can be found on the UCS target system under /var/lib/univention-appcenter/apps/$apps/compose/docker-compose.yml.


App providers can now directly start creating their Docker Apps in the App Provider Portal and store the Docker Compose configuration. The documentation will be published within the next days. And the first Multi Container Apps are already on their way and should be published in the App Center within the next weeks.


Use UCS Core Edition for Free!

Download now
Nico Gulden

Nico Gulden studied applied computer science and works for Univention since 2010. As technical editor he is responsible for maintenance and expansion of the product documentation. His spare time is dedicated to his family, reading, outdoor activities like cycling, photography, Geocaching and voluntary work with children and young people.

What's your opinion? Leave a comment!


  1. The documentation has been updated. The part about multi container support is described under:

  2. I thought, docker is docker. So i started with: docker save “name” > /path/filename
    as i use to backup debian docker containers.
    On UCS nothing will be written to filename, the hole server freeze, CPU-load gets high.
    What is wrong with it?

  3. Hello D.K.

    thank you for the comment. On UCS we use the default Docker engine. From what I understand from the documentation, it saves Docker images. Is that your intention? Or do you want to backup a Docker container?

    From the little input in this comment I cannot tell what’s wrong. I suggest to move this discussion over to Univention Help at and open a topic there. At first, I’m interested in answers to the following questions:

    * What Docker image did you try to save?
    * What does the docker daemon log say?
    * What’s the docker version you are running?
    * What UCS version are you using?

    A quick search brought me to which may relate to your observations.

    Best regards,


Your email address will not be published. Required fields are marked *