Guidance Request: Migrating Existing Mailman 3 Installation to Docker-Based Deployment
Hi all,
I am currently running a Mailman 3 setup on a standalone server and planning to migrate it to a Docker-based deployment using the official Docker Mailman images. I would appreciate your guidance on the recommended approach for this migration.
*Current (existing) setup:*
- Mailman Core: 3.3.5
- Postorius: 1.3.6
- HyperKitty: 1.3.5
- PostgreSQL: 12.22 (Ubuntu)
- Host-based installation (non-Docker)
- Postfix used as the MTA
- Active mailing lists with members and archives
- Apache reverse proxy in front
*Target (new) setup:*
- Docker-based Mailman 3 (mailman-core, mailman-web, PostgreSQL containers)
- Based on the official Docker Mailman repository
- Postfix as the MTA
- Apache reverse proxy in front
I would like to migrate the following components safely:
- Mailing lists and their configurations
- Subscribers and roles
- HyperKitty archives
- Postorius/web data (users, preferences, etc.)
I have a few specific questions:
- What is the recommended migration approach from a host-based Mailman 3 installation to the Docker-based setup?
- Is it safe to directly restore the PostgreSQL databases into the Docker environment, or is there a preferred migration method?
- Are there any version compatibility considerations when migrating from Mailman Core 3.3.5 / Postorius 1.3.6 / HyperKitty 1.3.5 to the versions used in the current Docker images?
- How to migrate archives?
- The official Docker Compose file references
postgres:12-alpine. Is it recommended to stay on PostgreSQL 12 for compatibility, or is it supported to use a newer PostgreSQL version (for example, PostgreSQL 18) with the Docker Mailman setup? - Are there any common pitfalls or best practices you would recommend for ensuring a smooth migration?
Any guidance or documentation you can provide would be greatly appreciated.
Thank you for your time and support.
Kind regards, Prasanth Nair
On Fri, Apr 10, 2026 at 6:04 PM Prasanth Nair <prasanth.nair@linaro.org> wrote:
Hi all,
I am currently running a Mailman 3 setup on a standalone server and planning to migrate it to a Docker-based deployment using the official Docker Mailman images. I would appreciate your guidance on the recommended approach for this migration.
*Current (existing) setup:*
- Mailman Core: 3.3.5
- Postorius: 1.3.6
- HyperKitty: 1.3.5
- PostgreSQL: 12.22 (Ubuntu)
- Host-based installation (non-Docker)
- Postfix used as the MTA
- Active mailing lists with members and archives
- Apache reverse proxy in front
*Target (new) setup:*
- Docker-based Mailman 3 (mailman-core, mailman-web, PostgreSQL containers)
- Based on the official Docker Mailman repository
- Postfix as the MTA
- Apache reverse proxy in front
I would like to migrate the following components safely:
- Mailing lists and their configurations
- Subscribers and roles
- HyperKitty archives
- Postorius/web data (users, preferences, etc.)
I have a few specific questions:
- What is the recommended migration approach from a host-based Mailman 3 installation to the Docker-based setup?
- Is it safe to directly restore the PostgreSQL databases into the Docker environment, or is there a preferred migration method?
- Are there any version compatibility considerations when migrating from Mailman Core 3.3.5 / Postorius 1.3.6 / HyperKitty 1.3.5 to the versions used in the current Docker images?
- How to migrate archives?
- The official Docker Compose file references
postgres:12-alpine. Is it recommended to stay on PostgreSQL 12 for compatibility, or is it supported to use a newer PostgreSQL version (for example, PostgreSQL 18) with the Docker Mailman setup?- Are there any common pitfalls or best practices you would recommend for ensuring a smooth migration?
Any guidance or documentation you can provide would be greatly appreciated.
Thank you for your time and support.
Hello Prasanth,
How about you just test the installation on Docker and migration and see the results. You could even use a higher version of postgres in your container since MM3 supports it. My test machine has PostgreSQL 17 and MM3 running. Since the test migration is non-destructive, you could do it, fail, drop the volumes, do it again until you have it working. And you take notes in the process. I asked Uncle Google for "migrate mailman3 from bare metal to docker" and the AI response at the top seemed quite close to what it should be. Scare the fear away and just do the testing on some VM.
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 In an Internet failure case, the #1 suspect is a constant: DNS. "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]
Prasanth Nair writes:
I am currently running a Mailman 3 setup on a standalone server and planning to migrate it to a Docker-based deployment using the official Docker Mailman images. I would appreciate your guidance on the recommended approach for this migration.
docker-mailman is basically a hobby of the maintainer's. It's not even maintained in the GitLab project. As far as I know it's there because it's frequently requested and folks who run docker usually know what they're doing so it doesn't impose a particular burden on us. But really the only expert on docker-mailman is Abhilash himself.
All three of the major Mailman suite applications (core, Postorius, and HyperKitty) use object-relation managers with automated schema updates. So contrary to Odhiambo's advice, I would try to replicate the versions of the Mailman components and PostgreSQL, then do upgrades in-place in Docker. Doing a database dump (in the current host) and restore (in the containerized PostgreSQL) is safe if you have the same schema on both hosts. (Upgrading the PostgreSQL version is much less risky but why tempt the software gremlins?)
An alternative if you know PostgreSQL well would be to setup a "failover and failback" system, where you start with your current PostgreSQL as the primary and the container's as a replica, then when you're ready to go live you swap primary and replica for the database and point the DNS to the containerized Mailman. This probably involves less downtime (although in my experience PostgreSQL dump and restore is quite fast, and the Mailman databases for core and Postorius are small), but the big advantage is if you have a problem with the containers you can switch back right away. I know this works because I worked on a project where high availability was required, but another guy did the PostgreSQL work so I can't provide details.
Networking is a FAQ for mailman-docker. I've only run it out of the box with all its defaults, and that worked fine. But somehow people have problems with it. My guess is that they're trying to fit the Mailman containers into some predetermined scheme, either a Docker host that hosts other containers and there are IP conflicts, or some organizational constraints. If you know what you're doing, no problem I think, but if you're newish to containers, you might want to set up docker on a host dedicated to Mailman.
Other than that, I think Abhilash provided a preferred channel for discussing docker-mailman in the docs in his repo, that would be where to get your best (and more detailed) information.
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
Hi Odhiambo and Stephen,
Thank you both for your helpful responses and guidance.
Given that this is a critical production system, I am now considering migrating to a new server using a host-based Mailman installation first, before evaluating a Docker-based setup at a later stage.
In that case, could you please advise on the recommended approach for migrating from my current host-based Mailman 3 installation to a new host-based server? In particular, I would appreciate any guidance on:
Safely migrating the PostgreSQL databases (e.g., dump and restore approach)
Preserving mailing lists, memberships, and configurations
Migrating HyperKitty archives and Postorius data
Any best practices to ensure a smooth cutover with minimal downtime
Any documentation or pointers you can share would be greatly appreciated.
Thank you again for your time and support.
Kind regards, Prasanth Nair
On Sat, 11 Apr 2026 at 17:52, Stephen J. Turnbull <steve@turnbull.jp> wrote:
Prasanth Nair writes:
I am currently running a Mailman 3 setup on a standalone server and planning to migrate it to a Docker-based deployment using the official Docker Mailman images. I would appreciate your guidance on the recommended approach for this migration.
docker-mailman is basically a hobby of the maintainer's. It's not even maintained in the GitLab project. As far as I know it's there because it's frequently requested and folks who run docker usually know what they're doing so it doesn't impose a particular burden on us. But really the only expert on docker-mailman is Abhilash himself.
All three of the major Mailman suite applications (core, Postorius, and HyperKitty) use object-relation managers with automated schema updates. So contrary to Odhiambo's advice, I would try to replicate the versions of the Mailman components and PostgreSQL, then do upgrades in-place in Docker. Doing a database dump (in the current host) and restore (in the containerized PostgreSQL) is safe if you have the same schema on both hosts. (Upgrading the PostgreSQL version is much less risky but why tempt the software gremlins?)
An alternative if you know PostgreSQL well would be to setup a "failover and failback" system, where you start with your current PostgreSQL as the primary and the container's as a replica, then when you're ready to go live you swap primary and replica for the database and point the DNS to the containerized Mailman. This probably involves less downtime (although in my experience PostgreSQL dump and restore is quite fast, and the Mailman databases for core and Postorius are small), but the big advantage is if you have a problem with the containers you can switch back right away. I know this works because I worked on a project where high availability was required, but another guy did the PostgreSQL work so I can't provide details.
Networking is a FAQ for mailman-docker. I've only run it out of the box with all its defaults, and that worked fine. But somehow people have problems with it. My guess is that they're trying to fit the Mailman containers into some predetermined scheme, either a Docker host that hosts other containers and there are IP conflicts, or some organizational constraints. If you know what you're doing, no problem I think, but if you're newish to containers, you might want to set up docker on a host dedicated to Mailman.
Other than that, I think Abhilash provided a preferred channel for discussing docker-mailman in the docs in his repo, that would be where to get your best (and more detailed) information.
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/...
This message sent to prasanth.nair@linaro.org
On Tue, Apr 14, 2026 at 1:08 PM Prasanth Nair <prasanth.nair@linaro.org> wrote:
Hi Odhiambo and Stephen,
Thank you both for your helpful responses and guidance.
Given that this is a critical production system, I am now considering migrating to a new server using a host-based Mailman installation first, before evaluating a Docker-based setup at a later stage.
In that case, could you please advise on the recommended approach for migrating from my current host-based Mailman 3 installation to a new host-based server? In particular, I would appreciate any guidance on:
Safely migrating the PostgreSQL databases (e.g., dump and restore approach)
Preserving mailing lists, memberships, and configurations
Migrating HyperKitty archives and Postorius data
Any best practices to ensure a smooth cutover with minimal downtime
Any documentation or pointers you can share would be greatly appreciated.
For a host-based installation, the recommended method is documented here: https://docs.mailman3.org/en/latest/install/virtualenv.html
If your current installation is based on the above, then (off the top of my head):
- Ensure that the database backend on the new host meets the specified requirements in the above documentation.
- Ensure that the Python version is the same on both hosts (so that nothing bites you immediately to migrate). @Stephen J. Turnbull <steve@turnbull.jp> call them software gremlins :-)
- Install MM3 the normal way on the destination host and ensure you run all the tests. 'mailman info' should show similar details on both hosts.
- Postfix should be configured the same way on both hosts. The migration will involve the following: (a) dumping the DB on the source and restoring on the destination (b) zip up /etc/mailman3 on the source and extract it on the destination (c) zip up /opt/mailman, move it to the destination server, extract it and copy the files/directories (except the venv directory) from this archive to /opt/mailman/ You then fix the permissions so that /opt/mailman is owned by the mailman user. The commands are on the link liven above (d) You need your Nginx vhost configs to be migrated to the new server. (e) DNS. Oh DNS! You will flip the records to point to the new server
That should preserve everything as you want.
These details are off the top of my head. I might have forgotten something so I beg your pardon in advance.
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 In an Internet failure case, the #1 suspect is a constant: DNS. "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]
Washington Odhiambo via Mailman-users writes:
[...] (see his mail)
I don't have specific comments beyond Odhiambo's excellent suggestions.
For the host -> host migration, if you are very concerned about a high-quality migration and can afford the effort, I would emphasize starting with a duplicate of the working host as close as possible, then reviewing configurations and eliminating weak points, general improvement, and optimization of the system while keeping a working configuration after each stage. However, unless you are considering changing MTAs (including a major version upgrade with backward incompatibilities), I don't recall people having problems with this.
For the host -> containerized transition, there's not a lot of lore about this. As far as I know, the Mailman side doesn't present problems, but for those not experienced with containers, networking and persistent storage configuration can cause issues.
For minimal downtime, I have done a 5k list migration from Mailman 2 to Mailman 3 with zero downtime of post distribution. If there are large archives, then archive migration will take time, just no way around that (although you can keep the old archives online). The basic strategy is to note that routing to lists in the MTA has some prioritization when different routes might apply to a particular destination address, then arrange that the "new" host gets the posts as each list is created, while the old host continues to handle the old posts.
That approach had the advantage in that case both Mailman hosts were dedicated to Mailman. Also, for a 5k list installation with Postfix, I needed a small change to routing. Mailman normally creates a hash db, which takes a lot of time (seconds) with a lot of lists. To get~ zero downtime (ie, less than than normal relay delays in Postfix), I created an alternative routing mechanism that talks directly to PostgreSQL. I think you don't need to do that with Exim4, can't help with other MTAs.
Regards, Steve
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
Thank you Stephen and Odhiambo for your advise on this.
Kind regards, Prasanth
On Tue, 14 Apr 2026 at 16:06, Stephen J. Turnbull <steve@turnbull.jp> wrote:
Washington Odhiambo via Mailman-users writes:
[...] (see his mail)
I don't have specific comments beyond Odhiambo's excellent suggestions.
For the host -> host migration, if you are very concerned about a high-quality migration and can afford the effort, I would emphasize starting with a duplicate of the working host as close as possible, then reviewing configurations and eliminating weak points, general improvement, and optimization of the system while keeping a working configuration after each stage. However, unless you are considering changing MTAs (including a major version upgrade with backward incompatibilities), I don't recall people having problems with this.
For the host -> containerized transition, there's not a lot of lore about this. As far as I know, the Mailman side doesn't present problems, but for those not experienced with containers, networking and persistent storage configuration can cause issues.
For minimal downtime, I have done a 5k list migration from Mailman 2 to Mailman 3 with zero downtime of post distribution. If there are large archives, then archive migration will take time, just no way around that (although you can keep the old archives online). The basic strategy is to note that routing to lists in the MTA has some prioritization when different routes might apply to a particular destination address, then arrange that the "new" host gets the posts as each list is created, while the old host continues to handle the old posts.
That approach had the advantage in that case both Mailman hosts were dedicated to Mailman. Also, for a 5k list installation with Postfix, I needed a small change to routing. Mailman normally creates a hash db, which takes a lot of time (seconds) with a lot of lists. To get~ zero downtime (ie, less than than normal relay delays in Postfix), I created an alternative routing mechanism that talks directly to PostgreSQL. I think you don't need to do that with Exim4, can't help with other MTAs.
Regards, Steve
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
participants (3)
-
Prasanth Nair -
Stephen J. Turnbull -
Washington Odhiambo