[Help]: docker-compose.yml missing port information

[gregoryacole]

Controller Version

6.2.14.11

Describe Your Issue or Question

I decided to move from a physical host to a Docker container for my controller. When I was setting up the controller, I wasn't able to get to the management interface. After looking at the docker-compose.yml (for host mode) and comparing it to docker-compose_bridge.yml, I realized that the port section was missing from the host mode file. I added the ports to the host mode file, and then everything started working as expected. Thought this might help others if they are trying to get this working. Thanks for creating it!

Expected Behavior

be able to access the controller web interface

Steps to Reproduce

modified the docker-compose.yml file

How You're Launching the Container

docker compose up -d

Container Logs

nothing really to log, it works as expected once the compose file was modified

MongoDB Logs

No response

Additional Context

No response

[mbentley]

Hmm well that’s very strange. Host mode specifically uses the hosts’s existing network interfaces and then there should be nothing to map because they natively get exposed on the actual network interfaces - unless they changed the compose or docker engine behavior. Any chance your host has an unusual network interface config as in it isn’t just standard network interfaces? Even multiple interfaces should be fine typically.

[gregoryacole]

I will be completely transparent that I am a newbie with Docker. Every time I ran the compose, I could see that the container was running, but I couldn't access the web interface. I was following this guide: https://lazyadmin.nl/home-network/omada-controller-docker/ and when I used the command docker ps --format "table {{.Names}}\t{{.Image}}\t{{.Status}}\t{{.Ports}}", nothing would come back with a value for the ports. I then checked your two compose files and saw the difference, so I just added those lines to the host mode compose file and it worked like a charm. I'm running Docker on Windows 11 if that matters somehow. Greg

…

On Thu, Sep 3, 2026 at 6:30 PM Matt Bentley ***@***.***> wrote: Hmm well that’s very strange. Host mode specifically uses the hosts’s existing network interfaces and then there should be nothing to map because they natively get exposed on the actual network interfaces - unless they changed the compose or docker engine behavior. Any chance your host has an unusual network interface config as in it isn’t just standard network interfaces? Even multiple interfaces should be fine typically. — Reply to this email directly, view it on GitHub <#816?email_source=notifications&email_token=CNNA6DJEHAFLE5Z334EMPS35NHWKFA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBSG43TENBQUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-18277240>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CNNA6DJNDGIMEWFSPHPQBR35NHWKFAVCNFSNUABIKJSXA33TNF2G64TZHMYTKMJZHEYTEOJUHNCGS43DOVZXG2LPNY5TCMBXGQ2TEOJWUF3AE> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/CNNA6DM7XEHGVZKSZVVVPQT5NHWKFA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBSG43TENBQUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVJTG633UMVZF62LPOM> and Android <https://github.com/notifications/mobile/android/CNNA6DKA2LML365SHLR32RL5NHWKFA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBSG43TENBQUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE>. Download it today! You are receiving this because you authored the thread.Message ID: <mbentley/docker-omada-controller/repo-discussions/816/comments/18277240@ github.com>

[mbentley]

Ah gotcha. Yeah, that's to be expected about the displaying of the ports when using bridged mode vs host mode. At least in bridged mode, the only method of exposing a port, besides using a sidecar container that exposes the service through it, like a reverse proxy type scenario where it uses a common bridged network for private communication and then exposing the port from the reverse proxy, is through specifically exposing ports and that's what the CLI output is communicating there.

With host mode, every port is going to be exposed regardless of whether or not it is declared since it's use the native host interface but there are some wrinkles when it comes to Docker Desktop and that is probably why the port wasn't working. I haven't used Docker Desktop on a Windows machine and I rarely run anything on my Mac that needs host networking either so I don't know completely how the behavior has changed but that might explain the possible need to expose the ports so Windows can expose those ports from the WSL2 VM that Docker runs in onto the Windows host since there is that mostly invisible layer of a VM that runs Docker on Windows vs the daemon running natively on a Linux host.

So yeah, it's a gotcha between a native Linux host vs Docker Desktop behavior so great to know!

[gregoryacole]

I understood a few of those words lol! I realize that I'm probably in the minority of users by hosting Docker on Windows, but it is what I know. So maybe it handles things differently in some cases. But maybe this will help someone else down the road. Thanks for the explanation!

…

On Fri, Sep 4, 2026, 7:41 AM Matt Bentley ***@***.***> wrote: Ah gotcha. Yeah, that's to be expected about the displaying of the ports when using bridged mode vs host mode. At least in bridged mode, the only method of exposing a port, besides using a sidecar container that exposes the service through it, like a reverse proxy type scenario where it uses a common bridged network for private communication and then exposing the port from the reverse proxy, is through specifically exposing ports and that's what the CLI output is communicating there. With host mode, every port is going to be exposed regardless of whether or not it is declared since it's use the native host interface but there are some wrinkles when it comes to Docker Desktop and that is probably why the port wasn't working. I haven't used Docker Desktop on a Windows machine and I rarely run anything on my Mac that needs host networking either so I don't know completely how the behavior has changed but that might explain the possible need to expose the ports so Windows can expose those ports from the WSL2 VM that Docker runs in onto the Windows host since there is that mostly invisible layer of a VM that runs Docker on Windows vs the daemon running natively on a Linux host. So yeah, it's a gotcha between a native Linux host vs Docker Desktop behavior so great to know! — Reply to this email directly, view it on GitHub <#816?email_source=notifications&email_token=CNNA6DNMZ3CXXFGIFJ6QBRD5NKS6JA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBSHA3TGNRZUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-18287369>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CNNA6DKNYNR2B53LUWSD6SL5NKS6JAVCNFSNUABIKJSXA33TNF2G64TZHMYTKMJZHEYTEOJUHNCGS43DOVZXG2LPNY5TCMBXGQ2TEOJWUF3AE> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/CNNA6DMIZ4MYRZXQXCBA5JL5NKS6JA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBSHA3TGNRZUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVJTG633UMVZF62LPOM> and Android <https://github.com/notifications/mobile/android/CNNA6DL6ABCLMAQWXNGAGS35NKS6JA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBSHA3TGNRZUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE>. Download it today! You are receiving this because you authored the thread.Message ID: <mbentley/docker-omada-controller/repo-discussions/816/comments/18287369@ github.com>