BUG: AWF agent cannot reach Postgres started via `services:`

[srgibbs99]

Summary

We are using a gh-aw workflow with a documented GitHub Actions services: block for Postgres.

The service container starts successfully and publishes 5432:5432, but the AI agent running inside the default AWF sandbox cannot connect to it.

At the same time, the agent can successfully reach gh-aw's own host-backed HTTP services through host.docker.internal.

This makes the expected behavior unclear:

1. Either GitHub Actions services: are not meant to be reachable from the AWF agent.
2. Or they are meant to be reachable, but there is a networking bug or missing documentation.

Repro shape

engine:
  id: copilot
  env:
    POSTGRES_HOSTNAME: host.docker.internal

services:
  postgres:
    image: postgres:15
    ports:
      - 5432:5432
    env:
      POSTGRES_USER: app
      POSTGRES_PASSWORD: app

network:
  allowed:
    - defaults
    - host.docker.internal

Application config was also set to use POSTGRES_HOSTNAME, so this was not a localhost misconfiguration.

Observed behavior

Service startup succeeds

docker create ... -p 5432:5432 ... postgres
5432/tcp -> 0.0.0.0:5432
postgres service is healthy.

host.docker.internal is allowed and usable for gh-aw infrastructure

Configuring HTTP MCP backend: mcpscripts, url=http://host.docker.internal:3000
Successfully connected ... url=http://host.docker.internal:3000

Configuring HTTP MCP backend: safeoutputs, url=http://host.docker.internal:3001
Successfully connected ... url=http://host.docker.internal:3001

Postgres is still unreachable from the AWF agent

PG::ConnectionBad: connection to server at "172.17.0.1", port 5432 failed: Connection timed out

Agent probes showed:

- localhost:5432 -> connection refused
- host.docker.internal:5432 -> timed out
- 172.30.0.x:5432 -> connection refused

Docs checked

Documented:

• services: is supported and shown with a Postgres example:
  https://github.github.com/gh-aw/reference/frontmatter/
• agents run in a containerized sandbox in GitHub Actions:
  https://github.github.com/gh-aw/reference/faq/
• network.allowed supports custom domains like host.docker.internal:
  https://github.github.com/gh-aw/reference/network/

Strongly implied by docs/source:

• gh-aw uses host.docker.internal for host-backed services when the agent sandbox is enabled
• gh-aw rewrites localhost to host.docker.internal for MCP HTTP services in sandboxed runs

What we could not find:

• any doc or example explaining whether a database started via services: is expected to be reachable from the AWF agent
• any Postgres-specific example showing the supported address pattern from inside the AWF sandbox

Question

What is the intended behavior here?

1. Are GitHub Actions services: expected to be reachable from the AWF agent?
2. If yes, what is the supported address pattern?
3. If no, should the docs explicitly say that DB-backed validation must run in deterministic steps: or separate jobs: outside the agent sandbox?
4. If this should work, is this a bug where host.docker.internal works for gh-aw MCP HTTP services but not for host-published TCP services like Postgres?

Requested outcome

Any of these would resolve the ambiguity:

1. Confirm the supported configuration for Postgres access from AWF.
2. Confirm this is not supported and document the recommended pattern.
3. Fix the networking behavior if published service ports are supposed to be reachable from the AWF agent.

[Mossaka]

Hi, thanks for raising this issue. I am looking into it now. The ports like 5432 are dropped by the iptables because we have a catch-all policy in the firewall. I do see the value of adding configuration to awf so that host-local service ports an be allowed. Let me work on this feature.

[lpcox]

🔗 AWF tracking issue: https://github.com/github/gh-aw-firewall/issues/github/gh-aw-firewall#1462

Generated by AWF Issue Auditor · ◷