When running docker-compose.prod.yml with Podman Compose, the frontend nginx fails to resolve the api service hostname, resulting in 502 Bad Gateway on all /api/ requests.
Root cause
The nginx config inside flowsint-app uses Docker's embedded DNS resolver:
resolver127.0.0.11valid=10s;
127.0.0.11 is Docker Engine specific - it's a hardcoded IP where Docker runs its internal DNS server inside each container. Podman does not use this address. Instead, Podman's DNS resolver runs on the network gateway (typically 10.89.0.1), which is written into the container's /etc/resolv.conf.
Because 127.0.0.11:53 has nothing listening in a Podman container, DNS resolution fails:
send() failed (111: Connection refused) while resolving, resolver: 127.0.0.11:53
api could not be resolved (110: Operation timed out)
Fix
1. Remove the Docker-specific resolver from nginx.conf
In flowsint-app/nginx.conf, replace the resolver + variable pattern with a direct proxy_pass:
Since there is no build: section, the container runs the baked-in nginx.conf from the registry image (which still has 127.0.0.11). Mount the corrected local config as a volume:
podman compose -f docker-compose.prod.yml up -d --build --force-recreate
Docker vs Podman DNS comparison
Runtime
Resolver IP
Source
Docker Engine
127.0.0.11
Hardcoded in Docker daemon
Podman
Gateway IP (e.g. 10.89.0.1)
Written to /etc/resolv.conf
By removing the hardcoded 127.0.0.11 and letting nginx use the system resolver, the config works on both runtimes.
Trade-off
Using proxy_pass http://api:5001 directly (without resolver + set) means nginx resolves the api hostname once at startup. If the api container is recreated with a different IP, the nginx container must be restarted to pick up the new address. For typical compose deployments this is acceptable.
Originally created by @nidorx on GitHub (Jun 6, 2026).
Original GitHub issue: https://github.com/reconurge/flowsint/issues/180
## Problem
When running `docker-compose.prod.yml` with [**Podman Compose**](https://podman.io/), the frontend nginx fails to resolve the `api` service hostname, resulting in `502 Bad Gateway` on all `/api/` requests.
### Root cause
The nginx config inside `flowsint-app` uses Docker's embedded DNS resolver:
```nginx
resolver 127.0.0.11 valid=10s;
```
`127.0.0.11` is **Docker Engine specific** - it's a hardcoded IP where Docker runs its internal DNS server inside each container. Podman does not use this address. Instead, Podman's DNS resolver runs on the network gateway (typically `10.89.0.1`), which is written into the container's `/etc/resolv.conf`.
Because `127.0.0.11:53` has nothing listening in a Podman container, DNS resolution fails:
```
send() failed (111: Connection refused) while resolving, resolver: 127.0.0.11:53
api could not be resolved (110: Operation timed out)
```
## Fix
### 1. Remove the Docker-specific resolver from `nginx.conf`
In `flowsint-app/nginx.conf`, replace the resolver + variable pattern with a direct `proxy_pass`:
```diff
location /api/ {
- resolver 127.0.0.11 valid=10s;
- set $api_upstream http://api:5001;
- proxy_pass $api_upstream;
+ proxy_pass http://api:5001;
proxy_http_version 1.1;
proxy_set_header Host $host;
...
}
```
This makes nginx resolve `api` using the system's DNS configuration (`/etc/resolv.conf`), which Podman sets up correctly.
### 2. Mount the local `nginx.conf` into the container
The production compose file pulls a pre-built image from GHCR:
```yaml
app:
image: ghcr.io/reconurge/flowsint-app:${FLOWSINT_VERSION:-latest}
```
Since there is no `build:` section, the container runs the baked-in `nginx.conf` from the registry image (which still has `127.0.0.11`). Mount the corrected local config as a volume:
```yaml
app:
image: ghcr.io/reconurge/flowsint-app:${FLOWSINT_VERSION:-latest}
volumes:
- ./flowsint-app/nginx.conf:/etc/nginx/nginx.conf:ro
```
Then
```
podman compose -f docker-compose.prod.yml up -d --build --force-recreate
```
### Docker vs Podman DNS comparison
| Runtime | Resolver IP | Source |
|----------------|-----------------|----------------------------------|
| Docker Engine | `127.0.0.11` | Hardcoded in Docker daemon |
| Podman | Gateway IP (e.g. `10.89.0.1`) | Written to `/etc/resolv.conf` |
By removing the hardcoded `127.0.0.11` and letting nginx use the system resolver, the config works on both runtimes.
### Trade-off
Using `proxy_pass http://api:5001` directly (without `resolver` + `set`) means nginx resolves the `api` hostname once at startup. If the `api` container is recreated with a different IP, the nginx container must be restarted to pick up the new address. For typical compose deployments this is acceptable.
GiteaMirror
added the bug label 2026-06-17 01:14:56 -05:00
thank you for this. If you feel like it, could you open a PR ? 🙏
<!-- gh-comment-id:4650289868 -->
@dextmorgn commented on GitHub (Jun 8, 2026):
Hey @nidorx,
thank you for this. If you feel like it, could you open a PR ? 🙏
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @nidorx on GitHub (Jun 6, 2026).
Original GitHub issue: https://github.com/reconurge/flowsint/issues/180
Problem
When running
docker-compose.prod.ymlwith Podman Compose, the frontend nginx fails to resolve theapiservice hostname, resulting in502 Bad Gatewayon all/api/requests.Root cause
The nginx config inside
flowsint-appuses Docker's embedded DNS resolver:127.0.0.11is Docker Engine specific - it's a hardcoded IP where Docker runs its internal DNS server inside each container. Podman does not use this address. Instead, Podman's DNS resolver runs on the network gateway (typically10.89.0.1), which is written into the container's/etc/resolv.conf.Because
127.0.0.11:53has nothing listening in a Podman container, DNS resolution fails:Fix
1. Remove the Docker-specific resolver from
nginx.confIn
flowsint-app/nginx.conf, replace the resolver + variable pattern with a directproxy_pass:This makes nginx resolve
apiusing the system's DNS configuration (/etc/resolv.conf), which Podman sets up correctly.2. Mount the local
nginx.confinto the containerThe production compose file pulls a pre-built image from GHCR:
Since there is no
build:section, the container runs the baked-innginx.conffrom the registry image (which still has127.0.0.11). Mount the corrected local config as a volume:Then
Docker vs Podman DNS comparison
127.0.0.1110.89.0.1)/etc/resolv.confBy removing the hardcoded
127.0.0.11and letting nginx use the system resolver, the config works on both runtimes.Trade-off
Using
proxy_pass http://api:5001directly (withoutresolver+set) means nginx resolves theapihostname once at startup. If theapicontainer is recreated with a different IP, the nginx container must be restarted to pick up the new address. For typical compose deployments this is acceptable.@dextmorgn commented on GitHub (Jun 8, 2026):
Hey @nidorx,
thank you for this. If you feel like it, could you open a PR ? 🙏