I'm trying to deploy Komga in a Docker container on Catchy OS, but although the container starts, I can't reach the web interface at localhost:25600. Three other containers—Audiobookshelf, Immich, and Navidrome—are working normally on the same system.
I've rebuilt the Compose file, opened the port in the firewall, checked folder ownership, and reviewed the logs without seeing an obvious error. The setup uses the gotson/komga image, publishes port 25600, and runs as UID/GID 1000:1000. I've also tried connecting through the host machine's LAN address and its Tailscale address, but neither worked.
The relevant Compose configuration is:
services:
komga:
image: gotson/komga
container_name: komga
volumes:
- type: bind
source: /home/$me/containers/Komga/config/
target: /config
- type: bind
source: /home/$me/containers/Komga/data/
target: /data
- type: bind
source: /home/$me/Documents/comics/
target: /comics
ports:
- 25600:25600
user: "1000:1000"
environment:
- TZ=America/Los_Angeles
restart: unless-stopped
What would be the best way to determine whether the problem is Komga itself, the port mapping, the bind mounts, or the host network/firewall?
3 Answers
The port mapping looks reasonable, so test each layer separately rather than changing the Compose file repeatedly. Run `docker compose ps` and `docker port komga` first; the published port should show something like `0.0.0.0:25600->25600/tcp`. Then test directly on the Docker host with `curl -v http://127.0.0.1:25600/` and inspect `docker logs --tail=200 komga`.
If the local curl fails, Komga may not have completed startup. Since the container is forced to run as UID/GID 1000:1000, verify that this user can read and write all three bind-mounted directories. `docker compose config` is also useful for confirming that the paths and variables are being expanded as expected. Avoid using broad permissions such as `chmod 777` as a first fix.
Remember that `localhost` only refers to the machine where the browser is running. If you’re testing from another computer, use the Docker host’s LAN address and make sure the host firewall allows TCP 25600. However, because you also tried the host and Tailscale addresses, first confirm that the service responds locally with curl; if it doesn’t, the issue is probably inside Komga or its container rather than remote networking.
Also check whether another process is already listening on port 25600. You can compare the Docker mapping with the host’s listeners using `ss -ltnp | grep 25600` or a similar command. If something else owns the port, change the host side of the mapping, for example `25601:25600`, and connect to port 25601.
I was using localhost from the same computer hosting Docker, then also tested the machine’s LAN and Tailscale addresses. None of them connected, so I’ll focus on the local curl result and the container logs first.