stacker agent deploy-app creates the redeployed container on a different, isolated network than the rest of the stack

[vsilent]

Summary

After the #211 fix, stacker agent deploy-app <app> --image <img> --force succeeds (no more "undefined network" error) and reports "status": "deployed", but the redeployed container actually ends up broken: it's placed on a different Docker network than its sibling services, so service-name DNS resolution fails and the app crash-loops.

Steps to reproduce

1. Full cloud deploy of a project with an app + a service it depends on via hostname, e.g. miniflux (trydirect/stacker-project-examples) — DATABASE_URL uses hostname postgres.

   stacker deploy --target cloud --key htz-0 --force-new --watch

   This produces containers project-app-1 / project-postgres-1 on network default_network (per the Remote compose references undefined network default_network #211-fixed renderer).
2. Redeploy just the app container via the agent:

   stacker agent deploy-app miniflux --image miniflux/miniflux:latest --force

   Reports success:

   { "status": "deployed", "container_state": "starting", ... }

3. Check container health shortly after — the new container is crash-looping:

   stacker agent health
   CONTAINER            STATE
   miniflux              restarting
   project-postgres-1    running
   project-app-1         running   <- old container, untouched
   

   (Note: agent deploy-app created a new container literally named miniflux, alongside the original project-app-1 — a separate issue in itself, but focusing on the network problem here.)

Root cause (confirmed via docker inspect/docker network ls on the target server)

• New miniflux container's logs: dial tcp: lookup postgres on 127.0.0.11:53: server misbehaving — Docker embedded DNS can't resolve postgres.
• docker inspect miniflux → networks: project_default_network (note the project_ prefix).
• docker inspect project-postgres-1 → networks: default_network and project_app-network (no project_default_network).
• docker network ls shows both default_network and project_default_network exist as separate networks on the host; docker network inspect project_default_network has zero containers attached despite the miniflux container's inspect output claiming membership in it (empty EndpointID — the attach may not have actually completed, likely downstream of the container's own crash-restart loop).

So stacker agent deploy-app's redeploy path uses a project_-prefixed network name that doesn't match the network the original full-stack deploy created/uses (default_network, unprefixed, per the #211 fix). The two deploy paths (stacker deploy --target cloud vs stacker agent deploy-app) appear to use inconsistent naming conventions for the same project.

Expected

stacker agent deploy-app should place the redeployed container on the same network as the rest of the project's stack (whatever the original stacker deploy created), so service-name DNS resolution keeps working.

Impact

High for the agent deploy-app workflow specifically — the command reports success but silently leaves the app unable to reach its database, with no error surfaced to the caller.

Environment

• stacker CLI 0.3.1 (144d1a6)
• Found immediately after re-verifying the Remote compose references undefined network default_network #211 fix landed — same session, same miniflux deployment (trydirect/stacker-project-examples)
• Related: Remote compose references undefined network default_network #211, ConfigRenderer::render_compose omits top-level volumes: block, breaking services with named volumes (same class as #211) #236 (same general area — compose/network rendering divergence between different generation code paths)

[vsilent]

Adding fuller raw evidence, since the root cause is more specific than my first pass suggested — the compose file itself is correct, so this isn't a rendering bug like #211/#236, it's happening at the docker-invocation layer.

The rendered compose file is right

/home/trydirect/project/docker-compose.yml (regenerated at the exact moment of the agent deploy-app call, 2026-08-20 12:59:50 UTC):

  miniflux:
    image: miniflux/miniflux:latest
    container_name: miniflux
    networks:
      - default_network
  postgres:
    image: postgres:16-alpine
    container_name: postgres
    volumes:
      - postgres_data:/var/lib/postgresql/data
    networks:
      - default_network

networks:
  default_network:
    driver: bridge

volumes:
  postgres_data:

Both services correctly reference default_network, top-level block matches. No syntax/naming bug in the YAML.

But the actual running containers disagree

docker ps -a:

NAMES                IMAGE                      STATUS                         CREATED AT
miniflux              miniflux/miniflux:latest   Restarting (1) 3 seconds ago  2026-08-20 12:59:51 UTC
project-postgres-1    postgres:16-alpine         Up 15 hours (unhealthy)       2026-08-19 22:10:17 UTC
project-app-1         miniflux/miniflux:latest   Up 15 hours                   2026-08-19 22:10:17 UTC

docker network ls:

NAME                      DRIVER
default_network           bridge
project_app-network       bridge
project_default_network   bridge

docker inspect miniflux (the container the compose file above just created) → networks:

{"project_default_network": {"EndpointID":"", "IPAddress":"", ...}}

Note the project_ prefix — not default_network as the compose file says — and empty EndpointID/IPAddress, i.e. never actually got a working attachment.

docker inspect project-postgres-1 (created the day before, 2026-08-19 22:10:17, by the original stacker deploy --target cloud) → networks:

{
  "default_network": {"EndpointID":"4dbc...", "IPAddress":"172.20.0.4", ...},
  "project_app-network": {"EndpointID":"c62e...", "IPAddress":"172.18.0.2", ...}
}

So postgres is real-attached to default_network (matches the current compose) and project_app-network (a leftover from an earlier compose revision — see the .stacker-bak-* files below, project was apparently the original compose's project name and app-network an older network key that predates the #211 fix). docker network inspect project_default_network shows zero containers.

There's also a backup-file trail on the server showing the compose has been regenerated repeatedly as fixes landed:

docker-compose.yml.stacker-bak-20260819T223723Z-...
docker-compose.yml.stacker-bak-20260819T223834Z-...
docker-compose.yml.stacker-bak-20260820T074155Z-...
docker-compose.yml.stacker-bak-20260820T105818Z-...
docker-compose.yml.stacker-bak-20260820T125950Z-...

Refined hypothesis

Since the compose YAML itself says default_network (no prefix) but the container that was just created from it ends up on project_default_network (prefixed), whatever agent deploy-app runs to actually create/start the container (docker compose up invocation, or an equivalent Docker Engine API call) appears to be applying a project_/-p project scope that isn't reflected in — and doesn't match — the network name declared in the compose file it just wrote. That's a different bug class than #211/#236: those were compose-generation bugs (wrong text in the YAML); this is a compose-execution bug (the YAML is right, but whatever creates the container ignores/overrides it, or resolves the network name under a different project scope than the rest of the stack was created under).

Happy to pull more (docker compose ls, the actual command line the agent ran if there's a way to capture it, etc.) if useful — let me know what would help narrow it down further.

[vsilent]

Root cause confirmed and fixed — you had it exactly right in the "Refined hypothesis": the YAML text was correct, this was a compose-execution/network-scoping bug, not a rendering-text bug like #211/#236.

Root cause: ConfigRenderer::render_compose's template (src/services/config_renderer.rs) declared the top-level network as:

networks:
  default_network:
    driver: bridge

No external: true. default_network is meant to be the platform's one pre-existing shared host network — everywhere else in the codebase that creates or references it marks it external: true (forms::project::network::Network::default(), compose_service_sync::upsert_external_network). Without that flag, docker compose -p <project> up does what Compose always does for a non-external network: scopes/prefixes it with the project name and creates a new network (<project>_default_network) if one doesn't already exist under that scoped name — exactly the empty, newly-created project_default_network you found the crash-looping miniflux container attached to, while project-postgres-1 (created via a different path) sits on the real, literal default_network.

Fix: the renderer now marks default_network external: true (any other network name — the trydirect_network fallback for apps with no configured network — keeps driver: bridge, matching Network::into()'s existing is_default check).

Added render_compose_declares_default_network_as_external, asserting the rendered top-level block is default_network: {external: true}. Full suite: 1773 passed, 0 failed.

Not committed — leaving that to the repo owner, as with #211/#236.

[vsilent]

Confirmed fixed on a fresh cloud deploy + `agent deploy-app` redeploy:

```
$ stacker agent deploy-app miniflux --image miniflux/miniflux:latest --force
{ "status": "deployed", "container_state": "running", ... }

\`docker network ls\` on the server now shows only \`default_network\` (no more orphan \`project_default_network\`), and \`docker inspect miniflux\` shows a real attachment:
\`\`\`json
{"default_network": {"EndpointID": "4689...", "IPAddress": "172.20.0.6", ...}}
\`\`\`
No more crash loop — confirmed end-to-end via \`GET /v1/me\` (authenticated, DB-backed) returning the admin user correctly. Thanks for tracking this one down!