Posted almost 2 years ago. Visible to the public.


If you want to use containers for your deployment, we support this via a docker-compose.yml file.

For this case we provide a slightly different directory structure than our usual opscomplete setup.

/home/<deploy-user>/ /var/container/<deploy-user>/code /var/container/<deploy-user>/data /gluster/shared/<deploy-user>

The folder in the home directory contains the script that you can use to trigger a (re-)deploy of your containers. The script pulls, builds and then restarts the container on the server one after the other.

If the tag name on an image changes, the environment variable TAG_NAME can be passed to The best way is to store it in your code/.env file (where you should store your other environment data too). In the docker-compose.yaml an example image setting looks like:

image my-image:${TAG_NAME?Image tag missing}

The docker-compose.yml and all other relevant files (e.g. .env file for custom environment files) for your images should be placed in the code/ directory. The docker-compose.yml is also symlinked to the home directory.

Important: We use the docker-compose.yml as the interface between your code and our managed hosting. We can place database-specifc information or VM-specific information in the environment variables which can in turn be picked up by the docker-compose.yml file. We advise you to discuss larger changes in this file with us before you go into production. We will use this file also to restart the services after maintenance reboots or other unplanned incidents.

If your containers need to persist data you have the options to use docker volumes or bind mounts. For the bind mounts the data/ directory is supposed to hold local data.

The /gluster/shared/ directory is shared via network between your application servers and can hold common data between container on different server.

Internally we are using podman to run the containers. At the moment we use podman-compose to manage the docker-compose file. This will change in the future. If you want to do manual changes to manage your containers you can use these tools, but make sure to recheck this card regularly for updates.

Following are some examples commands.

(Re-)start your containers:

cd /var/container/<deploy-user>/code podman-compose -f <docker-compose-file> down podman-compose -f <docker-compose-file> up -d --force-recreate

List your containers:

podman ps

Stop a container:

podman stop $INSTANCE


We cannot prepare a default monitoring solution for all your deployed services because of the flexibility this setup offers. Please discuss the details of your applications with us, so we can monitor the functionality of your application. We propose that you provide a single healthcheck route for all your services. This way we can continue to check the health even if the underlying services change.


You are free to create data folders in:

/var/container/<deploy-user>/data /gluster/shared/<deploy-user>

Let us know which of these folders need to be backed up. All directories on the gluster mount are backed up.

Owner of this card:

Stefan Langenmaier
Last edit:
16 days ago
by Claus-Theodor Riegg
Posted by Stefan Langenmaier to opscomplete
This website uses short-lived cookies to improve usability.
Accept or learn more