Files
minio/helm/silo
Feng Ruohang c46b16ec62 chore: cut over to pgsty/silo and main
The transitional references land in one commit, because they are only correct
together: the repository is pgsty/silo, its default branch is main, and nothing
in the tree should point a user at the old names.

Changed:

- Workflow branch filters. go.yml and vulncheck.yml gated on `branches: master`
  for both push and pull_request, so renaming the default branch would have
  taken automatic CI offline with no error and no signal - the workflows would
  simply never trigger again. They now name main.
- Release target. goreleaser's `release.github.name` becomes silo, which is
  what actually decides where a tagged build publishes. sign-release-rpms.sh's
  GH_REPO default follows.
- The OCI `image.source` label, the Helm chart `sources` entry, the security
  advisory link in the issue-template config, and the go.mod comment citing the
  LDAP TLS fix.
- 115 occurrences across README, README_ZH, SECURITY, CONTRIBUTING and 30 docs
  pages, including 72 links that also carried the master branch in their path.
  Those matter most: GitHub redirects clone, fetch, push and web URLs after a
  rename, but raw.githubusercontent.com does not, and neither follows a branch
  rename - every one of those links would 404 twice over.
- Three error strings in cmd/erasure-sets.go, cmd/storage-errors.go and
  internal/config/errors.go that print an issue URL to operators. These are Go
  string literals inside rebrand-guard's brand allowlist, so the baseline is
  regenerated. The regeneration removes exactly those three entries and adds
  none; all twelve other protected sets, including the 9014 exported symbols,
  are byte-identical.
- The transitional-naming disclaimers in README, README_ZH, SECURITY and
  CONTRIBUTING are dropped, since they no longer describe anything.

Deliberately unchanged, all three because they exist to reject or freeze the old
name rather than to point at it:

- buildscripts/minio-upgrade.sh pins pgsty/minio@sha256:b6bfe72... - the frozen
  pre-rebrand image is the control group for the MinIO-to-Silo upgrade test.
- helm-migration-guard rejects any rendered container still pulling pgsty/minio.
- verify-rebrand.sh rejects the same in the delivery surfaces.

Also unchanged: docs/config/README.md links to pgsty/mc/blob/master, and that
repository's default branch really is still master. It moves when mc does.

verify-rebrand.sh gains three assertions so this cannot silently regress: no
source reference may name pgsty/minio outside the three allowlisted guards, no
link may target pgsty/silo's master branch, and go.yml and vulncheck.yml must
filter on main. Both new rejections were negative-tested - reintroducing a
master branch filter and adding a pgsty/minio URL each fail the gate with the
specific message.

This commit assumes the rename actually happens. Until the GitHub branch and
repository renames are executed, the links it introduces do not resolve.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-06 09:28:06 +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.