docker-compose.yml

x-valkey-image: &valkey-image valkey/valkey:9.1

# The six cluster nodes below differ only in name, published port and data directory.
x-valkey-node: &valkey-node
  image: *valkey-image
  command: valkey-server /etc/valkey.conf
  environment:
    # valkey-cli still reads the password from REDISCLI_AUTH
    - REDISCLI_AUTH=openvsx
  healthcheck:
    test: ["CMD", "valkey-cli", "-p", "7000", "--user", "openvsx", "ping"]
    interval: 5s
    retries: 5
  # The admin UI depends on the cluster, so starting it starts the cluster too.
  profiles:
    - valkey
    - valkey-admin

services:

  postgres:
    image: postgres:16.2
    environment:
      - POSTGRES_USER=openvsx
      - POSTGRES_PASSWORD=openvsx
    logging:
      options:
        max-size: 10m
        max-file: "3"
    ports:
      - '5432:5432'
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U openvsx"]
      interval: 5s
      timeout: 5s
      retries: 20
    profiles:
      - db
      - debug

  postgres-timeseries:
    # download analytics only: PostgreSQL plus the timescaledb extension, kept apart from the
    # registry database so the registry never needs the extension
    image: timescale/timescaledb:2.17.2-pg16
    environment:
      - POSTGRES_USER=openvsx
      - POSTGRES_PASSWORD=openvsx
      - POSTGRES_DB=openvsx_timeseries
    logging:
      options:
        max-size: 10m
        max-file: "3"
    ports:
      - '5433:5432'
    volumes:
      - postgres-timeseries-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U openvsx -d openvsx_timeseries"]
      interval: 5s
      timeout: 5s
      retries: 20
    # Its own profile, not `db` or `debug`: download analytics are off by default, so the ordinary
    # local setup should not pay for a second database it will never connect to. Select `analytics`
    # alongside the rest, and set ovsx.analytics.enabled, when working on them.
    profiles:
      - analytics

  elasticsearch:
    image: elasticsearch:9.2.8
    environment:
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
      - xpack.security.enabled=false
      - xpack.ml.enabled=false
      - discovery.type=single-node
      - bootstrap.memory_lock=true
      - cluster.routing.allocation.disk.threshold_enabled=false
    ports:
      - 9200:9200
      - 9300:9300
    ulimits:
      memlock:
        soft: -1
        hard: -1
    healthcheck:
      # localhost, not the service name: there is no `elasticsearch01` here, so this never resolved
      # and the container sat "starting" for the full 50 retries while the cluster was green.
      test: ["CMD-SHELL", "curl -sf http://localhost:9200/_cluster/health >/dev/null || exit 1"]
      interval: 10s
      timeout: 5s
      retries: 50
      start_period: 5s
    profiles:
      - es
      - debug

  # Kibana has to match the Elasticsearch above: it refuses to talk to a cluster on a different
  # major version, so the two versions move together.
  kibana:
    image: kibana:9.2.8
    ports:
      - "5601:5601"
    environment:
      # ELASTICSEARCH_HOSTS, not ELASTICSEARCH_URL: `elasticsearch.url` was removed in Kibana 7 and
      # is not a setting any more, so the old name was quietly doing nothing.
      - ELASTICSEARCH_HOSTS=http://elasticsearch:9200
    depends_on:
      elasticsearch:
        condition: service_healthy
        required: false
    profiles:
      - kibana

  valkey-node-1:
    <<: *valkey-node
    ports:
      - "7001:7000"
    volumes:
      - ./valkey.conf:/etc/valkey.conf
      - ./data/valkey/node-1:/data

  valkey-node-2:
    <<: *valkey-node
    ports:
      - "7002:7000"
    volumes:
      - ./valkey.conf:/etc/valkey.conf
      - ./data/valkey/node-2:/data

  valkey-node-3:
    <<: *valkey-node
    ports:
      - "7003:7000"
    volumes:
      - ./valkey.conf:/etc/valkey.conf
      - ./data/valkey/node-3:/data

  valkey-node-4:
    <<: *valkey-node
    ports:
      - "7004:7000"
    volumes:
      - ./valkey.conf:/etc/valkey.conf
      - ./data/valkey/node-4:/data

  valkey-node-5:
    <<: *valkey-node
    ports:
      - "7005:7000"
    volumes:
      - ./valkey.conf:/etc/valkey.conf
      - ./data/valkey/node-5:/data

  valkey-node-6:
    <<: *valkey-node
    ports:
      - "7006:7000"
    volumes:
      - ./valkey.conf:/etc/valkey.conf
      - ./data/valkey/node-6:/data

  valkey-cluster-init:
    image: *valkey-image
    depends_on:
      valkey-node-1:
        condition: service_healthy
      valkey-node-2:
        condition: service_healthy
      valkey-node-3:
        condition: service_healthy
      valkey-node-4:
        condition: service_healthy
      valkey-node-5:
        condition: service_healthy
      valkey-node-6:
        condition: service_healthy
    environment:
      - REDISCLI_AUTH=openvsx
    # Nodes keep their nodes.conf in ./data/valkey, so on a restart the cluster is already
    # formed and `--cluster create` would fail. Only create when node-1 still knows just itself,
    # which keeps `up` idempotent. Checking known nodes rather than cluster_state avoids a race:
    # nodes.conf is loaded at startup, while the state only turns ok once the nodes have gossiped.
    entrypoint: >
      sh -c "
      if valkey-cli -h valkey-node-1 -p 7000 --user openvsx cluster info
      | grep -qE 'cluster_known_nodes:1([^0-9]|$$)';
      then valkey-cli --user openvsx --cluster create
      valkey-node-1:7000 valkey-node-2:7000 valkey-node-3:7000
      valkey-node-4:7000 valkey-node-5:7000 valkey-node-6:7000
      --cluster-replicas 1 --cluster-yes;
      else echo 'valkey cluster already initialized';
      fi"
    profiles:
      - valkey
      - valkey-admin

  # Web UI for the cluster above. Pre-configuring the connection makes Valkey Admin discover the
  # cluster topology from node-1 on startup and spawn a metrics collector per primary, so metrics
  # are already being collected when you open it. In Web mode the UI still manages connections
  # itself, so it asks you to create one on first use - enter host `valkey-node-1`, port `7000`,
  # user `openvsx`, password `openvsx` (the admin server resolves the host inside the compose
  # network, so the published 127.0.0.1:7001-7006 ports do not work here).
  # DEPLOYMENT_MODE=Web is the image default, set here to be explicit.
  valkey-admin:
    image: valkey/valkey-admin:1.1.1
    # Discovery is a one-shot at startup with no retry, so wait for the cluster to exist.
    depends_on:
      valkey-cluster-init:
        condition: service_completed_successfully
    ports:
      - '8090:8080'
    environment:
      - DEPLOYMENT_MODE=Web
      - VALKEY_HOST=valkey-node-1
      - VALKEY_PORT=7000
      - VALKEY_AUTH_TYPE=password
      - VALKEY_USERNAME=openvsx
      - VALKEY_PASSWORD=openvsx
    profiles:
      - valkey-admin

  server:
    image: eclipse-temurin:25-jdk
    working_dir: /app
    command: sh -c 'scripts/generate-properties.sh --docker && ./gradlew assemble && ./gradlew runServer'
    volumes:
      - ./server:/app
    ports:
      - 8080:8080
    # `required: false` states the dependency without claiming ownership: postgres and elasticsearch
    # stay in their own profiles, and are waited on when the selected profiles include them. Without
    # it, selecting a profile that holds a service but not its dependency is a hard error - "service
    # X depends on undefined service Y: invalid compose project" - which is what `--profile openvsx`,
    # `--profile frontend`, `--profile commandline` and `--profile kibana` all used to be.
    depends_on:
      postgres:
        condition: service_healthy
        required: false
      postgres-timeseries:
        condition: service_healthy
        required: false
      elasticsearch:
        condition: service_healthy
        required: false
    healthcheck:
      # eclipse-temurin ships no curl, wget or nc, so the previous curl-based check could only ever
      # exit 127. bash is present, and its /dev/tcp is enough to ask the actuator the same question.
      # bash explicitly, not CMD-SHELL: that runs /bin/sh, which on this image is dash, and dash has
      # no /dev/tcp - it fails with "cannot create /dev/tcp/...: Directory nonexistent".
      # Single-quoted so the \r\n reach bash as escapes for printf, rather than being turned into
      # real control characters by YAML on the way.
      test:
        - CMD
        - bash
        - -c
        - 'exec 3<>/dev/tcp/localhost/8081 && printf "GET /actuator/health HTTP/1.0\r\n\r\n" >&3 && grep -q UP <&3'
      interval: 10s
      timeout: 5s
      retries: 50
      start_period: 5s
    profiles:
      - openvsx
      - backend

  webui:
    image: node:24
    working_dir: /app
    command: sh -c 'yarn install --immutable && yarn dev'
    volumes:
      - ./webui:/app
      - /app/node_modules
    ports:
      - 3000:3000
    depends_on:
      server:
        condition: service_started
        required: false
    profiles:
      - openvsx
      - frontend

  cli:
    image: node:24
    working_dir: /app
    command: sh -c 'yarn && yarn watch'
    volumes:
      - ./cli:/app
    depends_on:
      server:
        condition: service_started
        required: false
    environment:
      - OVSX_REGISTRY_URL=http://server:8080
    profiles:
      - openvsx
      - commandline

  # Silo rather than MinIO: minio/minio is gone from Docker Hub, so the old image cannot be pulled
  # any more. Silo is a MinIO fork and a drop-in for everything used here - the same entrypoint
  # contract, the same minioadmin defaults, the same bundled mc, and it still answers the MinIO
  # health path as well as its own.
  silo:
    image: pgsty/silo:RELEASE.2026-09-03T13-18-01Z
    command: server --console-address ":9001" /data
    ports:
      - "9000:9000"
      - "9001:9001"
    healthcheck:
      test: curl -s http://localhost:9000/silo/health/live >/dev/null || exit 1
      interval: 10s
      timeout: 5s
      retries: 50
      start_period: 5s
    profiles:
      - silo

  # No persistent volume on `silo` above, so its bucket and access policy are wiped every time
  # the container is recreated (not just re-started). Re-creates both on every `up` instead of
  # requiring a manual `mc` setup each time - `mc` is bundled in the same image, so this reuses
  # it rather than pulling a client as a separate image.
  silo-init:
    image: pgsty/silo:RELEASE.2026-09-03T13-18-01Z
    depends_on:
      silo:
        condition: service_healthy
    entrypoint: >
      sh -c "
      mc alias set local http://silo:9000 minioadmin minioadmin &&
      mc mb --ignore-existing local/test &&
      mc anonymous set download local/test
      "
    profiles:
      - silo

volumes:
  postgres-timeseries-data: