Container app with Compose Postgres

• host control plane for Compose
• container workload context for app tasks
• Postgres reached as postgres:5432 from the workload
• execution contexts, typed compose plus host service managers, endpoint projection, readiness origin, and Compose-network attachment are all shipped

• it turns a repo pattern into something humans, CI, and agents can read the same way
• it makes the next command obvious instead of implied by README drift
• it keeps readiness, setup, and execution explainable in receipts and diagnostics

Use this when the app should run in a container context but service orchestration should stay on the host control plane.

This example uses the shipped execution-topology contract surface: execution.default_context, execution.contexts, tasks.<name>.context, tasks.<name>.requires_services, services.<name>.manager, services.<name>.endpoints, and services.<name>.readiness.

version: 1project:  name: sample-java-serviceexecution:  default_context: app  contexts:    host:      backend: native      requirements:        tools:          docker: "*"    app:      backend: container      lifecycle: persistent      container:        image: maven:3.9.14-eclipse-temurin-21-noble      attachments:        compose:          - local      requirements:        runtimes:          java: ">=21"          node: ">=24.14.1"        tools:          maven: "*"services:  postgres:    manager:      kind: compose      name: local      file: compose.yaml      service: postgres    endpoints:      app:        address: postgres        port: 5432    readiness:      from: app      run: pg_isready -h postgres -p 5432tasks:  compose:up:    context: host    run: docker compose up -d postgres  compose:down:    context: host    run: docker compose down -v  setup:    internal: true    context: app    run: mvn -q -DskipTests dependency:go-offline  db:integration:    context: app    requires_services:      - postgres    run: mvn -B -Dgroups=db-integration test  test:    context: app    run: mvn test

Why this matters: the app does not need Docker inside the app image. The host controls Compose, the workload joins the network, and db:integration can ask for postgres directly instead of relying on a manual ota up reminder.

What it fixes: host control-plane tools and workload tools stop pretending they belong to one flat repo-wide backend surface, and the task graph no longer has to duplicate service ownership.

Operator rule: keep attachments.compose and services.<name>.manager.name aligned with the Compose project name you actually use, or ota will attach workload containers to the wrong network namespace.