Continuing to get ready for my initial mailcow deployment, in conjunction with an existing, non-mailcow docker-compose stack. The existing stack has nginx 1.25.1 running, and mailcow community Icon it’s been suggested

to simply point my external nginx to the nginx-mailcow service.

I intend to follow this advice, but I’ve never chained nginx in this fashion before. I see on the docs.mailcow.email Icon Reverse Proxy

documentation that I should add any other servers to the ADDITIONAL_SERVER_NAMES variable in mailcow.conf. Is this absolutely necessary in this case? My other, non-malcow web domains shouldn’t reach the nginx-mailcow service (they’ll be handled by the external nginx service, and not forwarded to the nginx-mailcow service).

My plan is to use my existing ACME/certbot certs for mailcow (I’ve already set up the letsencrypt renewal-hooks/post/mailcow-restart script as recommended on the Reverse Proxy documentation). Would I need to add everything in the SAN on that cert (ADDITIONAL_SAN, or ADDITIONAL_SERVER_NAMES), given that nginx-mailcow wouldn’t actually see anything it’s not supposed to handle?

I see the following warning on the Reverse Proxy documentation: If you enable TLS SNI (ENABLE_TLS_SNI in mailcow.conf), the certificate paths in your reverse proxy must match the correct paths in data/assets/ssl/{hostname}. The certificates will be split into data/assets/ssl/{hostname1,hostname2,etc} and therefore will not work when you copy the examples from below pointing to data/assets/ssl/cert.pem etc.

Isn’t this only for the acme-mailcow service? I was thinking of disabling this service since I’ll be using the external ACME/certbot, if that’s recommended (or possible).

  • I asked the question more pointedly in another thread, this is the best answer from that thread:

    D4niel

I would also need to change the proxy_pass parameter to point to nginx-mailcow, wouldn’t I? 127.0.0.1 assumes localhost:8080 will be pointing to nginx-mailcow, but I don’t think that’s correct.

Have something to say?

Join the community by quickly registering to participate in this discussion. We'd like to see you joining our great moo-community!

I found this comment on my original thread helpful: accolon

Basically it says let the acme-mailcow service manage ACME for everything mailcow related, and my non-mailcow ACME/certbot for everything else. I just need to point my reverse proxy to the nginx-mailcow service, and point to the mailcow certs.

I was hoping someone would respond to this topic, but I’m afraid it hasn’t gotten any visibility. I read through the mailcow docker-compose.yaml file, and it makes sense that I really shouldn’t touch this file at all. I found some interesting things in that file, especially setting up the Docker network bridge. I did try to emulate some of that in my non-mailcow stack, but it didn’t quite work like I expected.

That’s likely due to my non-mailcow docker-compose.yml being on version 3.8, while the mailcow version is on 2.1. I’m not looking for help from the mailcow community on that, I have the Docker community for that (irc://#docker@libera).

In any case I am several weeks away from running docker compose up -d in my first mailcow stack. I’m about to launch a new website for a community organization I run from my existing VPS, and will be adding 200 users next week. I need to see what kind of load that puts on the VPS. I have no idea how many concurrent users I’ll have, probably not close to the maximum number of members, but I have no way to gauge the actual load before launch.

I’ll make the decision on whether it can support mailcow under such a load. The initial mailcow stack will only have one user (me), so I’m pretty sure this VPS will be able to handle it.

11 days later

I asked the question more pointedly in another thread, this is the best answer from that thread:

D4niel

No one is typing