docker-compose.yml

# Two Coolify specifics are load-bearing and must not be "tidied away":
#
#  1. The public-facing service joins the external `coolify` network AND carries
#     `traefik.docker.network=coolify`. Coolify's Traefik has no default docker
#     network, so without both it eventually resolves the container's
#     unreachable private-network IP and the route returns 504 after the next
#     unrelated deploy.
#  2. The app Domain configured in the Coolify UI must include the scheme
#     (`https://tel.example.com`). A bare hostname makes Coolify emit broken
#     Traefik labels — empty Host(), the domain treated as a path.
#
# Postgres deliberately does NOT join the `coolify` network and publishes no
# ports. It is reachable only from the ingest container on the private default
# network. Read it from DataGrip over an SSH tunnel; see README.md.

services:
  ingest:
    # Built in GitHub Actions and pulled from GHCR — see
    # .github/workflows/docker-publish.yml. Deliberately no `build:` stanza:
    # compose prefers building over pulling, so re-adding one silently moves
    # compilation back onto the server.
    image: ghcr.io/plohnensoftware/git-graph-libre-telemetry-server:main
    pull_policy: always
    restart: unless-stopped
    expose:
      - "3000"
    environment:
      - DATABASE_URL=postgres://telemetry:${SERVICE_PASSWORD_POSTGRES}@postgres-git-graph-libre-telemetry-server:5432/telemetry?sslmode=disable
      - PORT=3000
    depends_on:
      postgres-git-graph-libre-telemetry-server:
        condition: service_healthy
    networks:
      - default
      - coolify
    labels:
      - traefik.docker.network=coolify
    # No `healthcheck:` here on purpose. The image carries its own — the binary
    # re-invoked as `telemetry-ingest healthcheck` — and an override in this
    # file would suppress it and put Coolify back to "Healthcheck: not
    # configured". See the HEALTHCHECK stanza in Dockerfile.

  # Named in full, not `postgres`. The ingest sits on the shared external
  # `coolify` network, so a bare `postgres` alias there could be another
  # app's database — Docker DNS would be free to hand us either one. The
  # long name is the collision guard; do not shorten it.
  postgres-git-graph-libre-telemetry-server:
    image: postgres:18-alpine
    restart: unless-stopped
    environment:
      - POSTGRES_USER=telemetry
      - POSTGRES_PASSWORD=${SERVICE_PASSWORD_POSTGRES}
      - POSTGRES_DB=telemetry
    volumes:
      # Mount the PGDATA *parent*, not `.../data`. Since Postgres 18 the image
      # keeps data in a major-version subdirectory (/var/lib/postgresql/18/docker)
      # and refuses to boot when /var/lib/postgresql/data is a mount point at
      # all -- an empty one included, which is how this first deploy failed.
      - telemetry-data:/var/lib/postgresql
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U telemetry -d telemetry"]
      interval: 10s
      timeout: 5s
      retries: 5
      start_period: 10s
    ports:
      # Bound to the host's loopback, never 0.0.0.0. The UFW-bypass problem is
      # about wildcard publishes: this DNAT rule only matches traffic already
      # arriving on the VPS's own 127.0.0.1, which is where an SSH tunnel lands
      # and where nothing from the internet can reach.
      #
      # It exists so DataGrip has a target that survives a redeploy. Tunnelling
      # to the container's bridge IP works too, but Docker reassigns it on every
      # deploy, so the saved connection breaks roughly once a week.
      #
      # 55432 rather than 5432 on the host side: this VPS runs several Coolify
      # apps, any of which may want to publish its own Postgres on loopback, and
      # the first one to bind 5432 would make the others fail to start. It also
      # means the day someone drops the `127.0.0.1:` prefix by accident, the
      # mistake is not sitting on the port every scanner tries first.
      - "127.0.0.1:55432:5432"

networks:
  coolify:
    external: true

volumes:
  telemetry-data: