OUTBOUND_PORT is not doing anything #68

New Issue

adam · 2025-12-28T23:25:09+01:00

adam commented

2025-12-28 23:25:09 +01:00

Originally created by @Hanibachi on GitHub (Nov 9, 2025).

the web server is still serving on port 8000 despite the OUTBOUND_PORT being set to 9005.
the container logs :

wygiwyh STDOUT [2025-11-08 19:08:57] - INFO - procrastinate.periodic - Registering task check_for_updates with periodic id '' to run periodically with cron 0 */12 * * *
wygiwyh STDOUT [2025-11-08 19:08:58 +0100] [8] [INFO] Starting gunicorn 23.0.0
wygiwyh STDOUT [2025-11-08 19:08:58 +0100] [8] [INFO] Listening at: http://0.0.0.0:8000 (8)
wygiwyh STDOUT [2025-11-08 19:08:58 +0100] [8] [INFO] Using worker: sync
wygiwyh STDOUT [2025-11-08 19:08:58 +0100] [34] [INFO] Booting worker with pid: 34
wygiwyh STDOUT [2025-11-08 19:08:58 +0100] [35] [INFO] Booting worker with pid: 35
wygiwyh STDOUT [2025-11-08 19:08:58 +0100] [38] [INFO] Booting worker with pid: 38
wygiwyh STDOUT Launching a worker on all queues

also from inside the container :

$ app@105c870ad77a:/usr/src/app$ echo $OUTBOUND_PORT
9005
app@105c870ad77a:/usr/src/app$

navigating to 9005 returns bad gateway, navigating to 8000 u get the webui

Originally created by @Hanibachi on GitHub (Nov 9, 2025). the web server is still serving on port 8000 despite the `OUTBOUND_PORT` being set to 9005. the container logs : ``` wygiwyh STDOUT [2025-11-08 19:08:57] - INFO - procrastinate.periodic - Registering task check_for_updates with periodic id '' to run periodically with cron 0 */12 * * * wygiwyh STDOUT [2025-11-08 19:08:58 +0100] [8] [INFO] Starting gunicorn 23.0.0 wygiwyh STDOUT [2025-11-08 19:08:58 +0100] [8] [INFO] Listening at: http://0.0.0.0:8000 (8) wygiwyh STDOUT [2025-11-08 19:08:58 +0100] [8] [INFO] Using worker: sync wygiwyh STDOUT [2025-11-08 19:08:58 +0100] [34] [INFO] Booting worker with pid: 34 wygiwyh STDOUT [2025-11-08 19:08:58 +0100] [35] [INFO] Booting worker with pid: 35 wygiwyh STDOUT [2025-11-08 19:08:58 +0100] [38] [INFO] Booting worker with pid: 38 wygiwyh STDOUT Launching a worker on all queues ``` also from inside the container : ```bash $ app@105c870ad77a:/usr/src/app$ echo $OUTBOUND_PORT 9005 app@105c870ad77a:/usr/src/app$ ``` navigating to 9005 returns bad gateway, navigating to 8000 u get the webui

adam closed this issue

2025-12-28 23:25:09 +01:00

adam commented

2025-12-28 23:25:09 +01:00

@eitchtee commented on GitHub (Nov 9, 2025):

Hey there. Are you using the docker-compose available in the repo?

The OUTBOUND_PORT var is used only on that docker compose file as a way to map the internal port (8000) to any port you want in the line: ${OUTBOUND_PORT}:8000. If you're not using the original docker-compose file, you'd probably want to add this mapping somewhere on you docker run command or compose file. This should be better documented.

If you're using something like nginx-proxy-manager connecting to containers directly from the same docker network, then you'd need to use the internal port instead of the exposed port.

With that said, as far as I know this is standard procedure with docker containers, as the internal port doesn't really matter since you can expose it as any other port. But it should be trivially easy to add another variable to control this and use another port internally, do you have a use case for this?

@eitchtee commented on GitHub (Nov 9, 2025): Hey there. Are you using the [docker-compose available in the repo](https://github.com/eitchtee/WYGIWYH/blob/main/docker-compose.prod.yml)? The OUTBOUND_PORT var is used only on that docker compose file as a way to map the internal port (8000) to any port you want in the line: `${OUTBOUND_PORT}:8000`. If you're not using the original docker-compose file, you'd probably want to add this mapping somewhere on you docker run command or compose file. This should be better documented. If you're using something like nginx-proxy-manager connecting to containers directly from the same docker network, then you'd need to use the internal port instead of the exposed port. With that said, as far as I know this is standard procedure with docker containers, as the internal port doesn't really matter since you can expose it as any other port. But it should be trivially easy to add another variable to control this and use another port internally, do you have a use case for this?

adam commented

2025-12-28 23:25:10 +01:00

@Hanibachi commented on GitHub (Nov 9, 2025):

my use case is with podman, pods in podman share a single namespace so two containers cannot attach to the same port. it's kind of a niche case, but being able to to control the port is essential is such cases.

@Hanibachi commented on GitHub (Nov 9, 2025): my use case is with podman, pods in podman share a single namespace so two containers cannot attach to the same port. it's kind of a niche case, but being able to to control the port is essential is such cases.

adam commented

2025-12-28 23:25:10 +01:00

@eitchtee commented on GitHub (Nov 9, 2025):

Can you please try use the image/tag: eitchtee/wygiwyh:test_internal_port? Set the env var INTERNAL_PORT to whatever port you want the application to listen on internally.

Then let me know If it works, so I can publish a proper new version with this change.

@eitchtee commented on GitHub (Nov 9, 2025): Can you please try use the image/tag: `eitchtee/wygiwyh:test_internal_port`? Set the env var `INTERNAL_PORT` to whatever port you want the application to listen on internally. Then let me know If it works, so I can publish a proper new version with this change.

adam commented

2025-12-28 23:25:12 +01:00

@eitchtee commented on GitHub (Nov 24, 2025):

This is available on v0.18.0

@eitchtee commented on GitHub (Nov 24, 2025): This is available on v0.18.0

adam referenced this issue

2025-12-28 23:26:32 +01:00

[PR #68] [MERGED] feat(transactions): proper clear button for filters #149

Sign in to join this conversation.