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

mailcow community Icon mailcow communityDiscussion
Why is the compose file at version 2.1?
Author avatar image tblancher
I’m currently planning my initial mailcow-dockerized deployment. I just cloned the mailcow-dockerized project, I haven’t done anything else with it yet. I see that docker-compose.yml has version: '2.1' at the top, which seems to be an old version. Background: I have another docker compose stack,
mailcow community
9 4
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

docs.mailcow.email Icon docs.mailcow.email
Overview - mailcow: dockerized documentation
None
docs.mailcow.email
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