Guidance Request: Migrating Existing Mailman 3 Installation to Docker-Based Deployment

older
request to held messages yields...

Prasanth Nair

April 10, 2026

3:03 p.m.

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

Show replies by date

Washington Odhiambo

April 2026

4:31 p.m.

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]

Stephen J. Turnbull

4:51 p.m.

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

Prasanth Nair

10:07 a.m.

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

Washington Odhiambo

12:31 p.m.

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.

Stephen J. Turnbull

3:06 p.m.

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

Prasanth Nair

8:54 a.m.

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

Age (days ago)

Last active (days ago)

List overview

Download

6 comments

3 participants

participants (3)

Prasanth Nair
Stephen J. Turnbull
Washington Odhiambo