docs: rebrand the repository documentation, templates and dashboards

README, README_ZH, SECURITY, COMPLIANCE, CONTRIBUTING, NOTICE,
code_of_conduct, the vulnerability and PR-etiquette documents, the GitHub issue
and pull request templates, and the docs/ tree all present Silo as the product.
The Grafana dashboards under docs/metrics/prometheus/grafana/ have their panel
titles and descriptions rebranded while every minio_* query, label and
expression is left alone, so existing alerts and recording rules keep matching.

The distinction the review demanded is applied per hit rather than by
search-and-replace:

- Product and command text becomes Silo and silo: install and run instructions,
  systemd examples, compose services, download links, badges.
- Protocol and interface text keeps MinIO: MINIO_* variables, minio_* metrics,
  x-minio-* headers, /minio/* routes, .minio.sys, arn:minio, and API field and
  error names.
- Attribution keeps MinIO and gains the fork's own: the AGPL obligations,
  original copyright, CREDITS and NOTICE stay, with the modification notice
  added alongside rather than replacing them.
- Historical and third-party references are left as facts, not rewritten for
  brand tidiness.

README and README_ZH each carry an explicit non-affiliation notice, document
the side-by-side package migration including the
/etc/systemd/system/silo.service.d/10-legacy-user.conf drop-in for keeping a
legacy UID/GID, and state that recursive chown is never performed. The trademark
attribution uses the policy's approved "based on MinIO technology" wording, not
the shortened form the policy rejects.

github.com/pgsty/minio links are left in place and labelled transitional. The
repository has not been renamed, and rewriting them now would produce documented
URLs that 404 until the cutover; they change in the cutover commit together with
the goreleaser release target, the OCI source label and the raw-content branch.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Feng Ruohang
2026-08-06 08:49:30 +08:00
parent 6613c2a3cb
commit fd2ca1c6d2
94 changed files with 1613 additions and 1347 deletions
+41 -17
View File
@@ -1,4 +1,4 @@
# MinIO Multi-Tenant Deployment Guide [![Slack](https://slack.min.io/slack?type=svg)](https://slack.min.io) [![Docker Pulls](https://img.shields.io/docker/pulls/minio/minio.svg?maxAge=604800)](https://hub.docker.com/r/minio/minio/)
# Silo Multi-Tenant Deployment Guide [![Docker Pulls](https://img.shields.io/docker/pulls/pgsty/silo.svg?maxAge=604800)](https://hub.docker.com/r/pgsty/silo/)
This topic provides commands to set up different configurations of hosts, nodes, and drives. The examples provided here can be used as a starting point for other configurations.
@@ -8,35 +8,51 @@ This topic provides commands to set up different configurations of hosts, nodes,
## 1. Standalone Deployment
To host multiple tenants on a single machine, run one MinIO Server per tenant with a dedicated HTTPS port, configuration, and data directory.
To host multiple tenants on a single machine, run one Silo Server per tenant with a dedicated HTTPS port, configuration, and data directory.
### 1.1 Host Multiple Tenants on a Single Drive
Use the following commands to host 3 tenants on a single drive:
```sh
minio server --address :9001 /data/tenant1
minio server --address :9002 /data/tenant2
minio server --address :9003 /data/tenant3
silo server --address :9001 /data/tenant1
silo server --address :9002 /data/tenant2
silo server --address :9003 /data/tenant3
```
![Example-1](https://github.com/pgsty/minio/blob/master/docs/screenshots/Example-1.jpg?raw=true)
```mermaid
flowchart TB
tenant1["Tenant 1 :9001"] --> silo1["Silo process 1"]
tenant2["Tenant 2 :9002"] --> silo2["Silo process 2"]
tenant3["Tenant 3 :9003"] --> silo3["Silo process 3"]
silo1 --> disk["Shared host drive with isolated data directories"]
silo2 --> disk
silo3 --> disk
```
### 1.2 Host Multiple Tenants on Multiple Drives (Erasure Code)
Use the following commands to host 3 tenants on multiple drives:
```sh
minio server --address :9001 /disk{1...4}/data/tenant1
minio server --address :9002 /disk{1...4}/data/tenant2
minio server --address :9003 /disk{1...4}/data/tenant3
silo server --address :9001 /disk{1...4}/data/tenant1
silo server --address :9002 /disk{1...4}/data/tenant2
silo server --address :9003 /disk{1...4}/data/tenant3
```
![Example-2](https://github.com/pgsty/minio/blob/master/docs/screenshots/Example-2.jpg?raw=true)
```mermaid
flowchart TB
tenant1["Tenant 1 :9001"] --> silo1["Silo process 1"]
tenant2["Tenant 2 :9002"] --> silo2["Silo process 2"]
tenant3["Tenant 3 :9003"] --> silo3["Silo process 3"]
silo1 --> drives["Four shared drives with isolated tenant directories"]
silo2 --> drives
silo3 --> drives
```
## 2. Distributed Deployment
To host multiple tenants in a distributed environment, run several distributed MinIO Server instances concurrently.
To host multiple tenants in a distributed environment, run several distributed Silo Server instances concurrently.
### 2.1 Host Multiple Tenants on Multiple Drives (Erasure Code)
@@ -45,23 +61,31 @@ Use the following commands to host 3 tenants on a 4-node distributed configurati
```sh
export MINIO_ROOT_USER=<TENANT1_ACCESS_KEY>
export MINIO_ROOT_PASSWORD=<TENANT1_SECRET_KEY>
minio server --address :9001 http://192.168.10.1{1...4}/data/tenant1
silo server --address :9001 http://192.168.10.1{1...4}/data/tenant1
export MINIO_ROOT_USER=<TENANT2_ACCESS_KEY>
export MINIO_ROOT_PASSWORD=<TENANT2_SECRET_KEY>
minio server --address :9002 http://192.168.10.1{1...4}/data/tenant2
silo server --address :9002 http://192.168.10.1{1...4}/data/tenant2
export MINIO_ROOT_USER=<TENANT3_ACCESS_KEY>
export MINIO_ROOT_PASSWORD=<TENANT3_SECRET_KEY>
minio server --address :9003 http://192.168.10.1{1...4}/data/tenant3
silo server --address :9003 http://192.168.10.1{1...4}/data/tenant3
```
**Note:** Execute the commands on all 4 nodes.
![Example-3](https://github.com/pgsty/minio/blob/master/docs/screenshots/Example-3.jpg?raw=true)
```mermaid
flowchart TB
tenant1["Tenant 1 :9001"] --> pool1["Distributed Silo pool for tenant 1"]
tenant2["Tenant 2 :9002"] --> pool2["Distributed Silo pool for tenant 2"]
tenant3["Tenant 3 :9003"] --> pool3["Distributed Silo pool for tenant 3"]
pool1 --> nodes["Four nodes with isolated tenant data paths"]
pool2 --> nodes
pool3 --> nodes
```
**Note**: On distributed systems, root credentials are recommend to be defined by exporting the `MINIO_ROOT_USER` and `MINIO_ROOT_PASSWORD` environment variables. If no value is set MinIO setup will assume `minioadmin/minioadmin` as default credentials. If a domain is required, it must be specified by defining and exporting the `MINIO_DOMAIN` environment variable.
**Note**: On distributed systems, root credentials are recommend to be defined by exporting the `MINIO_ROOT_USER` and `MINIO_ROOT_PASSWORD` environment variables. If no value is set Silo setup will assume `minioadmin/minioadmin` as default credentials. If a domain is required, it must be specified by defining and exporting the `MINIO_DOMAIN` environment variable.
## Cloud Scale Deployment
A container orchestration platform (e.g. Kubernetes) is recommended for large-scale, multi-tenant MinIO deployments. See the [MinIO Deployment Quickstart Guide](https://silo.pgsty.com/operations/deployments/kubernetes/) to get started with MinIO on orchestration platforms.
A container orchestration platform (e.g. Kubernetes) is recommended for large-scale, multi-tenant Silo deployments. See the [Silo Deployment Quickstart Guide](https://silo.pgsty.com/operations/deployments/kubernetes/) to get started with Silo on orchestration platforms.