Installing MM on a machine where 443 is used

I followed to install MM on VPS running discourse alreaday but run into

root@Ubuntu18:~/mattermost-docker# docker-compose up -d
Creating network "mattermost-docker_default" with the default driver
Creating mattermost-docker_app_1 ...
Creating mattermost-docker_web_1 ... error
Creating mattermost-docker_db_1  ...
Creating mattermost-docker_app_1 ... done
ERROR: for mattermost-docker_web_1  Cannot start service web: driver failed programming external connectivity on endpoint mattermost-docker_web_1 (a210daeda9eb7f3df79c1d8e2be141f8a3fbc9c4cae8ffcb305d0fdab5a1f630): Bind for faCreating mattermost-docker_db_1  ... done

ERROR: for web  Cannot start service web: driver failed programming external connectivity on endpoint mattermost-docker_web_1 (a210daeda9eb7f3df79c1d8e2be141f8a3fbc9c4cae8ffcb305d0fdab5a1f630): Bind for failed: port is already allocated
ERROR: Encountered errors while bringing up the project.

so I did

root@Ubuntu18:~/mattermost-docker#  sudo lsof -i -P -n | grep LISTEN
sshd        959            root    3u  IPv4   18822      0t0  TCP *:22 (LISTEN)
sshd        959            root    4u  IPv6   18829      0t0  TCP *:22 (LISTEN)
docker-pr  1688            root    4u  IPv6 3748819      0t0  TCP *:443 (LISTEN)
docker-pr  1699            root    4u  IPv6 3748846      0t0  TCP *:80 (LISTEN)
systemd-r  8636 systemd-resolve   13u  IPv4 3181490      0t0  TCP (LISTEN)


root@Ubuntu18:~/mattermost-docker# docker ps
CONTAINER ID        IMAGE                   COMMAND                  CREATED             STATUS                   PORTS                                      NAMES
0148a95a2c09        mattermost-docker_db    "/ post…"   6 minutes ago       Up 6 minutes (healthy)   5432/tcp                                   mattermost-docker_db_1
4ec918f2efa8        mattermost-docker_app   "/ matt…"   6 minutes ago       Up 6 minutes (healthy)   8000/tcp                                   mattermost-docker_app_1
c447e7f705b5        local_discourse/app     "/sbin/boot"             3 weeks ago         Up 3 weeks     >80/tcp,>443/tcp   app

telling me that discourse is already using 443.

So the solution is a proxy but somewhere in the docs, it was mentioned that SSO is incompatible with running behind a proxy. Is that still true or any other side effects of running behind a proxy?
I cannot find anything anymore.

Instead, I find good tutorials explaining how to run behind a proxy.
I’m supposed to do this changes before doing ~/mattermost-docker# docker-compose up -d?

Hi there, @PackElend

Before I dig deeper into this, I would like to verify the documentation stating that SSO is incompatible running behind a proxy. Can you please share it here so we can have it reviewed? I just want to know if it only applies to older versions of Mattermost or rather an ongoing issue that needs to be fixed.

Meanwhile, the article did not explicitly provide information on when the changes needs to be done but since it involves changing the information in docker-compose.yml file, I believe that it needs to be done before running the docker-compose up command.

Had been searching for an hour for this without success before I started this topic. I’ll continue and will share when I find it.

1 Like

may we able to solve it as I have found something.

I definitely read Authentication options outside of a private network but that is not was concerns me. It is rather the point where I started (I reckon so).

I assume that I found something in the docs related to the combination of docker, proxy configuration, redirect and full authentication. I searched everywhere yesterday but only found:

So my question is.

If I use one out of following proxies


deployed via independent docker images. Will this have any impact on the functionality on MM?
According to MatterMost behind reverse proxy it seems to feasible.

Just thinking out loud about sockets, as I properly read to much about it. Moreover, as I use this approach on my private server.

Would be there any advantage, running WebSocket over UNIX sockets as UNIX sockets are subject to file system permissions what is easier to manage from an administrator perspective of view.

I don’t think it currently possible. It looks that you can expose UNIX Sockets in Docker (Can docker port forward to a unix file socket on the host container? & Use Unix sockets with Docker). It seems supported by some solutions WebSocket over AF_UNIX socket but may not by all browser although there is quite an old Mozilla discussion.
Ensuring that anyone reading this has the same understanding, these things are well explained on:



I’m running now Mattermost behing Traefik v2.
It is running with default settings but some questions are open, see Alternative reverse proxy - Traefik v2