Problem
The AWF framework creates containers with hardcoded names (awf-squid, awf-agent, awf-api-proxy, awf-cli-proxy) and uses hardcoded ports (8080 for MCP Gateway, 18443 for CLI proxy). This means only ONE agent job can run at a time per Docker daemon, even on powerful multi-core machines.
For self-hosted runner fleets (our case: 32-core PC with 4 gh-aw runners), this is the bottleneck preventing parallel agent execution.
Proposal
Add optional configuration to parameterize:
-
Container name prefix: e.g., awf_config.json → {container: {namePrefix: run-${GITHUB_RUN_ID}-}} → containers become run-12345-awf-squid, etc.
-
Port assignments: e.g., {ports: {gateway: 0, cliProxy: 0}} where 0 means "auto-assign ephemeral port" and the actual port is reported back for the framework to use.
-
Runtime directory: {runtime: {dir: ${RUNNER_TEMP}/gh-aw}} instead of hardcoded /tmp/gh-aw/.
Why this matters
With these three parameters, N concurrent agent jobs can run on a single Docker daemon. For a 32-core machine running 4 self-hosted gh-aw runners, this would enable 4x parallel agent execution without any infrastructure changes (no DinD, no multiple daemons, no VMs).
Currently, the only workaround is running multiple Docker daemons (one per concurrent job), which requires either DinD (port/DNS/cgroup issues) or full VMs (heavy).
Use case
Polku (github.com/polku-learning/polku) runs 5 agentic workflows (triage/implement/review/approve/custodian) on self-hosted runners. Target: 100 merged PRs/day. Current bottleneck: 1 concurrent agent job due to fixed container names and ports.
Problem
The AWF framework creates containers with hardcoded names (
awf-squid,awf-agent,awf-api-proxy,awf-cli-proxy) and uses hardcoded ports (8080 for MCP Gateway, 18443 for CLI proxy). This means only ONE agent job can run at a time per Docker daemon, even on powerful multi-core machines.For self-hosted runner fleets (our case: 32-core PC with 4 gh-aw runners), this is the bottleneck preventing parallel agent execution.
Proposal
Add optional configuration to parameterize:
Container name prefix: e.g.,
awf_config.json→{container: {namePrefix: run-${GITHUB_RUN_ID}-}}→ containers becomerun-12345-awf-squid, etc.Port assignments: e.g.,
{ports: {gateway: 0, cliProxy: 0}}where0means "auto-assign ephemeral port" and the actual port is reported back for the framework to use.Runtime directory:
{runtime: {dir: ${RUNNER_TEMP}/gh-aw}}instead of hardcoded/tmp/gh-aw/.Why this matters
With these three parameters, N concurrent agent jobs can run on a single Docker daemon. For a 32-core machine running 4 self-hosted gh-aw runners, this would enable 4x parallel agent execution without any infrastructure changes (no DinD, no multiple daemons, no VMs).
Currently, the only workaround is running multiple Docker daemons (one per concurrent job), which requires either DinD (port/DNS/cgroup issues) or full VMs (heavy).
Use case
Polku (github.com/polku-learning/polku) runs 5 agentic workflows (triage/implement/review/approve/custodian) on self-hosted runners. Target: 100 merged PRs/day. Current bottleneck: 1 concurrent agent job due to fixed container names and ports.