Skip to content

chore(dev): replace the MinIO image by pgsty/silo in the development and CI stacks (#7927) - #7928

Merged
Samuel Hassine (SamuelHassine) merged 1 commit into
mainfrom
issue/7927
Sep 12, 2026
Merged

Samuel Hassine (SamuelHassine) merged 1 commit into
mainfrom
issue/7927

Conversation

@SamuelHassine

Copy link
Copy Markdown
Member

Proposed changes

The minio/minio image can no longer be pulled: the upstream MinIO repository was archived on 24 April 2026 (the community edition is now source-only), and Docker Hub has since removed the minio/minio and minio/mc repositories altogether - every tag answers 404 and docker pull fails with pull access denied for minio/minio. Every fresh deployment or CI run of a stack that still references these images is broken today.

Following OpenCTI-Platform/opencti#18239, the stack moves to Silo, the community-maintained fork of the MinIO server published by Pigsty (pgsty/silo on Docker Hub, amd64 and arm64). Silo keeps the S3 API, the MINIO_* variables, the server /data --console-address command, the /minio/health/live route, the bundled mc client (so mc ready local healthchecks keep working) and the on-disk format unchanged, so an existing data volume is reused as is.

The latest tag is used on purpose: the MinIO-style dated release tags are not tracked anymore, and the whole Filigran ecosystem is aligned on pgsty/silo:latest (and pgsty/mc:latest for the client).

  • openaev-dev/docker-compose.yml: openaev-dev-minio (10000/10001) and openaev-test-minio (11000/11001) run pgsty/silo:latest instead of the frozen quay.io/minio/minio:RELEASE.2025-06-13T11-33-47Z. Container names, ports, minioadmin credentials, server /data --console-address ":9001" command and curl /minio/health/live healthcheck are untouched, so the minio.* configuration keys keep working and .github/actions/start-dev-services (which reads the image from the compose file) starts the new image with no change.
  • openaev-dev/README.md, docs/docs/deployment/installation.md, docs/docs/deployment/platform/overview.md, docs/docs/development/build-from-source.md, docs/docs/development/environment-windows.md: MinIO is named Silo where it is the object storage of the stack; the dependency table points at the Silo documentation and the latest tag.
  • .github/copilot-instructions.md, the CI action descriptions / wait messages (api-tests, api-types-check, e2e-tests, start-dev-services) and the activate-tenant-table skill comment: same rename.
  • The minio.* / MINIO_* configuration keys, the minio service names and the MinIO Java SDK dependency keep their names (the S3 protocol and the client are unchanged).

Testing Instructions

  1. cd openaev-dev && docker compose up -d openaev-dev-minio openaev-test-minio
  2. docker compose ps shows both containers healthy; curl -f http://localhost:10000/minio/health/live and http://localhost:11000/minio/health/live answer 200; the console is on http://localhost:10001 (minioadmin/minioadmin).
  3. Run the API tests (mvn test) or start the backend against the dev stack and upload a document: it lands in the openaev bucket exactly as before. The CI actions on this PR run against the new image.

Verified locally with Docker 29.6 on pgsty/silo:RELEASE.2026-09-03T13-18-01Z (the current latest) with the exact compose settings of the stack: the container reaches healthy through mc ready local, /minio/health/live and the console on 9001 answer 200, and a bucket create / upload / read round trip works with pgsty/mc. The image ships /usr/bin/mc, /usr/bin/mcli and /usr/bin/curl, so both healthcheck styles used across the Filigran stacks are supported.

Related issues

Checklist

  • I consider the submitted work as finished
  • I tested the code for its functionality
  • I wrote test cases for the relevant uses case
  • I added/update the relevant documentation (either on github or on notion)
  • Where necessary I refactored code to improve the overall quality
  • For bug fix -> I implemented a test that covers the bug

Further comments

The latest tag is used on purpose: the dated MinIO-style release tags are not tracked anymore, and the whole Filigran ecosystem is aligned on pgsty/silo:latest (and pgsty/mc:latest for the client). An existing local openaev-dev-minio data volume is reused as is (same on-disk format).

…and CI stacks (#7927)

The upstream MinIO repository was archived and Docker Hub removed the
minio/minio image; quay.io only carries frozen releases. Following
OpenCTI-Platform/opencti#18239 the openaev-dev-minio and openaev-test-minio
services now run pgsty/silo:latest, Silo being the community-maintained fork
of the MinIO server (same S3 API, MINIO_* variables, server command, health
route and on-disk format). Container names, ports, credentials, command and
healthcheck are untouched, so the minio.* configuration keys and the CI
actions (which read the image from the compose file) keep working. The
documentation, the dev README, the Copilot instructions and the CI action
descriptions now name Silo where they named MinIO as the object storage of
the stack.
Copilot AI lite review requested due to automatic review settings September 12, 2026 16:02
@github-actions

Copy link
Copy Markdown
Contributor

📖 Documentation check — ✅ Passed

No functional source changes detected.

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Replaces the unavailable MinIO image with Silo while preserving S3 configuration, service names, ports, and health checks.

Changes:

  • Updates development and CI object storage to pgsty/silo:latest.
  • Refreshes deployment and development documentation.
  • Updates CI descriptions and readiness messages.

Review findings:

  • docs/docs/deployment/platform/overview.md:59 — Moderate (1 vote): production guidance should use a dated Silo release or scope latest to development/CI.
  • openaev-dev/docker-compose.yml:32 — Moderate (1 vote): pin development and test images to verified immutable digests.
  • openaev-dev/docker-compose.yml:116 — Moderate (1 vote): pin the CI image to a verified immutable digest.

Reviewed changes

Copilot reviewed 12 out of 12 changed files in this pull request and generated no comments.

Show a summary per file
File Summary
openaev-dev/README.md Documents Silo usage.
openaev-dev/docker-compose.yml Uses Silo for development and test storage.
docs/docs/development/environment-windows.md Updates Windows setup references.
docs/docs/development/build-from-source.md Updates development dependency guidance.
docs/docs/deployment/platform/overview.md Updates the dependency table.
docs/docs/deployment/installation.md Updates installation documentation.
.github/skills/activate-tenant-table/SKILL.md Updates service references.
.github/copilot-instructions.md Updates repository service guidance.
.github/actions/start-dev-services/action.yml Updates CI service descriptions.
.github/actions/e2e-tests/action.yml Updates E2E readiness messages.
.github/actions/api-types-check/action.yml Updates type-check readiness messages.
.github/actions/api-tests/action.yml Updates API test readiness messages.
Suppressed comments (3)

docs/docs/deployment/platform/overview.md:59

  • issue (blocking): This table describes the dependencies required for production, so latest makes the supported Silo version non-reproducible and can silently change the storage server on a fresh deployment. Silo's own installation guidance recommends pinning a release for production; please use a dated Silo release here, or explicitly scope latest to development/CI instead of presenting it as the recommended version.
| S3 / Silo     | latest (Silo is a MinIO fork)   | 1 core  | ≥ 128MB | SSD       | ≥ 16GB     |

openaev-dev/docker-compose.yml:116

  • issue (blocking): start-dev-services derives the CI image from this service, so pgsty/silo:latest makes every CI run depend on a mutable registry tag and can introduce an unreviewed server change or regression. Pin the CI image to a verified immutable digest instead of latest.
    image: pgsty/silo:latest

openaev-dev/docker-compose.yml:32

  • issue (blocking): latest is mutable, so the default development stack can silently switch to a different Silo build without any repository change, making local failures hard to reproduce. Pin this image to a verified immutable digest (or provide an explicit, reviewed update mechanism) rather than using latest; apply the same policy to the test service below.
    image: pgsty/silo:latest

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

@SamuelHassine

Copy link
Copy Markdown
Member Author

For the record, on the three suppressed Copilot remarks about latest (production table in docs/docs/deployment/platform/overview.md, dev and CI compose files): tracking pgsty/silo:latest is the deliberate ecosystem-wide choice for now (#7927; OpenCTI-Platform/docker#607, OpenAEV-Platform/docker#163 and every chart make the same one), the way minio/minio was tracked before Docker Hub removed it, and no dated Silo release has been qualified as a fleet-wide pin yet. A deployment that must be frozen pins a RELEASE.* tag on the image line; the docs table will be updated when a pinned release becomes the recommendation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

filigran team Item from the Filigran team.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

chore(dev): replace the MinIO image by pgsty/silo in the development and CI stacks

2 participants