Summary
When setting up mailcow in any orchestration system that involves other containers, it's organized the exact opposite of other systems. For example, running Nextcloud with OnlyOffice?
- nextcloud-web
- nextcloud-onlyoffice
- nextcloud-reddis
- nextcloud-postgres
Running Immich as a Google Photos replacement?
- immich-machine-learning
- immich-postgres
- immich-redis
- immich-server
However, mailcow's containers are all mixed up when running a docker ps, interspersed inside every other containerization, because they're backwards:
- unbound-mailcow
- mysql-mailcow
- redis-mailcow
- etc...
These should all be reversed so that mailcow (the stack) comes before the app name.
Motivation
Clean, integrated orchestration in homelabs.
Additional context
Normally, with standard container deployments, it would be easy to rename everything, and pin the sha256 container tags to latest for updates. But since mailcow uses a docker-compose.yml that is updated via git, and an update.sh script instead of an in-container update script that runs with version tracking (this should probably be another issue opened), there's no easy way to manage this.
Ideally if the containers were "self-migrating" after a new container was pulled, this would be moot.
Summary
When setting up mailcow in any orchestration system that involves other containers, it's organized the exact opposite of other systems. For example, running Nextcloud with OnlyOffice?
Running Immich as a Google Photos replacement?
However, mailcow's containers are all mixed up when running a
docker ps, interspersed inside every other containerization, because they're backwards:These should all be reversed so that
mailcow(the stack) comes before the app name.Motivation
Clean, integrated orchestration in homelabs.
Additional context
Normally, with standard container deployments, it would be easy to rename everything, and pin the
sha256container tags tolatestfor updates. But since mailcow uses adocker-compose.ymlthat is updated viagit, and anupdate.shscript instead of an in-container update script that runs with version tracking (this should probably be another issue opened), there's no easy way to manage this.Ideally if the containers were "self-migrating" after a new container was pulled, this would be moot.