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'
    profiles:
      - db
      - debug

  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:
      test: curl -s http://elasticsearch01:9200 >/dev/null || exit 1
      interval: 10s
      timeout: 5s
      retries: 50
      start_period: 5s
    profiles:
      - es
      - debug

  kibana:
    image: kibana:8.7.1
    ports:
      - "5601:5601"
    environment:
      - ELASTICSEARCH_URL=http://elasticsearch:9200
    depends_on:
      - elasticsearch
    profiles:
      - kibana

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

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

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

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

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

  valkey-node-6:
    <<: *valkey-node
    container_name: valkey-node-6
    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
    depends_on:
      - postgres
      - elasticsearch
    healthcheck:
      test: "curl --fail --silent localhost:8081/actuator/health | grep UP || exit 1"
      interval: 10s
      timeout: 5s
      retries: 50
      start_period: 5s
    profiles:
      - openvsx
      - backend

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

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

  minio:
    image: minio/minio:RELEASE.2025-09-07T16-13-09Z
    command: server --console-address ":9001" /data
    ports:
      - "9000:9000"
      - "9001:9001"
    healthcheck:
      test: curl -s http://localhost:9000/minio/health/live >/dev/null || exit 1
      interval: 10s
      timeout: 5s
      retries: 50
      start_period: 5s
    profiles:
      - minio

  # No persistent volume on `minio` 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 minio/mc as a separate image.
  minio-init:
    image: minio/minio:RELEASE.2025-09-07T16-13-09Z
    depends_on:
      minio:
        condition: service_healthy
    entrypoint: >
      sh -c "
      mc alias set local http://minio:9000 minioadmin minioadmin &&
      mc mb --ignore-existing local/test &&
      mc anonymous set download local/test
      "
    profiles:
      - minio