Container app with host Postgres

• host-managed database
• typed host service manager
• containerized workload
• explicit endpoint projection instead of guessed localhost
• execution contexts, endpoint projection, and readiness origin 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 workload should stay in a container context but the database is owned by the host machine instead of Compose.

This example uses the shipped execution-topology contract surface to keep the host and workload endpoints honest.

version: 1project:  name: sample-java-serviceexecution:  default_context: app  contexts:    host:      backend: native      requirements:        tools:          lsof: "*"    app:      backend: container      lifecycle: persistent      container:        image: maven:3.9.14-eclipse-temurin-21-noble      requirements:        runtimes:          java: ">=21"        tools:          maven: "*"services:  postgres:    manager:      kind: host      name: local-postgres    endpoints:      host:        address: 127.0.0.1        port: 5432      app:        address: host.docker.internal        port: 5432    readiness:      from: app      run: pg_isready -h host.docker.internal -p 5432tasks:  setup:    internal: true    context: app    run: mvn -q -DskipTests dependency:go-offline  test:    context: app    run: mvn test

Why this matters: localhost stops lying. The host and app contexts each get their own truthful endpoint.

What it fixes: readiness and execution no longer have to guess whether a host-managed service is reachable from the workload container.