Files
minio/helm/silo
Feng Ruohang e071bb77e4 build(helm): replace the minio chart with a silo chart that preserves identity
helm/minio becomes helm/silo: chart name silo, version 6.0.0 -> 7.0.0, the
MinIO wordmark icon replaced with the project's own, image.repository and
mcImage.repository pointing at pgsty/silo, and the container command changed to
silo. User-visible titles, comments and documentation links are rebranded. The
MINIO_* environment variables and every existing values key are kept - the
first Silo chart is a rename, not a values-schema migration.

The hard problem is that a chart rename normally rewrites Kubernetes resource
identity, and a StatefulSet's selector and volumeClaimTemplate are immutable.
An existing release upgraded carelessly would either fail or orphan its PVCs.
Two things address that:

- Templates no longer derive the container name from .Chart.Name. It comes from
  a helper, so nameOverride can pin it, which means an existing release can be
  upgraded with nameOverride=minio, fullnameOverride=<existing-fullname> and
  serviceAccount.name=minio-sa and render byte-stable identity while switching
  chart and image.

- helm-migration-guard and verify-helm-migration.sh make that a gate rather
  than a documented hope. The script lints the chart, renders it in distributed
  and standalone modes plus the optional templates, then renders the legacy
  chart from a pinned commit and the new chart with those three overrides and
  compares resource identity. The guard additionally rejects any rendered
  container still pulling pgsty/minio or invoking /usr/bin/minio. It runs
  through a pinned alpine/helm image when helm is not installed locally, so the
  gate does not depend on the developer's machine. Currently green over 7
  compared resources.

Rollback is asymmetric and the README says so: the old chart with the new image
survives via the entrypoint argv shim, but the new chart with an old MinIO
image does not, because `silo server` is not a command that binary knows. Only
`helm rollback` is supported, never an image-only downgrade.

Not addressed here: the default image tag is pgsty/silo:RELEASE.2026-08-04T00-00-00Z,
which does not exist yet. The chart must not be published until the first Silo
image is pushed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-06 08:48:17 +08:00
..

Silo Helm Chart

This chart installs Silo, an independently maintained, S3-compatible object storage server, on Kubernetes. It supports standalone and distributed modes. The chart and server are licensed under AGPL-3.0-or-later.

Prerequisites

  • Kubernetes 1.19 or later
  • Helm 3
  • A PersistentVolume provisioner unless persistence.enabled=false

Install

From this repository:

helm install silo ./helm/silo \
  --namespace silo --create-namespace \
  --set rootUser=silo-admin \
  --set rootPassword='replace-with-a-long-random-secret'

For a disposable standalone installation:

helm install silo ./helm/silo \
  --namespace silo --create-namespace \
  --set mode=standalone \
  --set replicas=1 \
  --set persistence.enabled=false \
  --set resources.requests.memory=512Mi \
  --set rootUser=silo-admin \
  --set rootPassword='replace-with-a-long-random-secret'

The default server and post-install image is docker.io/pgsty/silo. The image contains the silo server, mcli, and an mc compatibility symlink. It does not contain a minio server binary.

Compatibility contract

The product and delivery names are Silo, while established interfaces remain compatible:

  • MINIO_* environment variables and existing values keys are unchanged.
  • /minio/* API and metrics routes are unchanged.
  • minio_* Prometheus metrics and x-minio-* protocol headers are unchanged.
  • Existing storage, including .minio.sys, is used without conversion.
  • nameOverride, fullnameOverride, and serviceAccount.name can pin existing Kubernetes resource identities during an upgrade.

New installations default to Silo resource names and the silo-sa service account.

Upgrade an existing release

Do not upgrade an existing release without first pinning its current resource names. Export the complete values and render the candidate chart offline:

helm get values my-release -n my-namespace -a > values.before-silo.yaml
SILO_TAG='<published-silo-release-tag>'

helm template my-release ./helm/silo \
  -n my-namespace \
  -f values.before-silo.yaml \
  --set nameOverride=minio \
  --set fullnameOverride=my-existing-fullname \
  --set serviceAccount.name=minio-sa \
  --set image.repository=pgsty/silo \
  --set mcImage.repository=pgsty/silo \
  --set-string image.tag="${SILO_TAG}" \
  --set-string mcImage.tag="${SILO_TAG}" \
  > rendered.silo.yaml

Compare the old and new manifests. Stop if the candidate changes immutable selectors, StatefulSet or Service identity, PVC names, Secrets, or storage mounts. After review, upgrade the chart and image together:

SILO_TAG='<published-silo-release-tag>'
helm upgrade my-release ./helm/silo \
  -n my-namespace \
  -f values.before-silo.yaml \
  --set nameOverride=minio \
  --set fullnameOverride=my-existing-fullname \
  --set serviceAccount.name=minio-sa \
  --set image.repository=pgsty/silo \
  --set mcImage.repository=pgsty/silo \
  --set-string image.tag="${SILO_TAG}" \
  --set-string mcImage.tag="${SILO_TAG}"

Rollback is chart-level: use helm rollback, not an image-only downgrade. The new chart invokes silo server; an old image does not provide that executable. The new image accepts a legacy first argv token of minio only to support old chart commands during the forward migration.

Persistence and TLS

The default PersistentVolumeClaim mounts at /export. Use an existing claim with:

helm install silo ./helm/silo --set persistence.existingClaim=PVC_NAME

Create a TLS Secret containing private.key and public.crt, then set:

helm upgrade --install silo ./helm/silo \
  --set tls.enabled=true \
  --set tls.certSecret=silo-tls

Additional trusted CAs can be supplied through trustedCertsSecret.

Existing Secrets and post-install resources

Set existingSecret to a Secret containing rootUser and rootPassword. Buckets, users, policies, service accounts, and custom commands can be created with the existing buckets, users, policies, svcaccts, and customCommands values. The post-install job uses mcli through its mc compatibility command. New custom commands should target mysilo; the legacy myminio target remains registered so existing values continue to work.

Configuration

See values.yaml for the complete values surface and the Silo documentation for server operations.

To uninstall the chart:

helm uninstall silo -n silo

PersistentVolumeClaims may remain after uninstall; inspect them before any manual deletion.