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>

.github/ISSUE_TEMPLATE.md

@@ -8,9 +8,12 @@ assignees: ''
 ---
 
 ## NOTE
-All GitHub issues are addressed on a best-effort basis at MinIO's sole discretion. There are no Service Level Agreements (SLA) or Objectives (SLO). Remember our [Code of Conduct](https://github.com/minio/minio/blob/master/code_of_conduct.md) when engaging with MinIO Engineers and the larger community.
 
-For urgent issues (e.g. production down, etc.), subscribe to [SUBNET](https://min.io/pricing?jmp=github) for direct to engineering support.
+Silo issues are handled by community maintainers on a best-effort basis. There
+is no SLA, SLO, or emergency production-support channel. Follow the local
+[Code of Conduct](../code_of_conduct.md) when participating. Report suspected
+vulnerabilities through the private process in [SECURITY.md](../SECURITY.md),
+not in a public issue.
  
 <!--- Provide a general summary of the issue in the Title above -->
 
@@ -29,7 +32,7 @@ For urgent issues (e.g. production down, etc.), subscribe to [SUBNET](https://mi
 ## Steps to Reproduce (for bugs)
 <!--- Provide a link to a live example, or an unambiguous set of steps to -->
 <!--- reproduce this bug. Include code to reproduce, if relevant -->
-<!--- and make sure you have followed https://github.com/minio/minio/tree/release/docs/debugging to capture relevant logs -->
+<!--- and include relevant Silo logs with secrets and credentials removed -->
 
 1.
 2.
@@ -42,10 +45,10 @@ For urgent issues (e.g. production down, etc.), subscribe to [SUBNET](https://mi
 
 ## Regression
 <!-- Is this issue a regression? (Yes / No) -->
-<!-- If Yes, optionally please include minio version or commit id or PR# that caused this regression, if you have these details. -->
+<!-- If Yes, optionally include the Silo version, commit id, or PR that caused this regression. -->
 
 ## Your Environment
 <!--- Include as many relevant details about the environment you experienced the bug in -->
-* Version used (`minio --version`):
+* Version used (`silo --version`):
 * Server setup and configuration:
 * Operating System and version (`uname -a`):

.github/ISSUE_TEMPLATE/bug_report.md

@@ -24,7 +24,7 @@ assignees: ''
 ## Steps to Reproduce (for bugs)
 <!--- Provide a link to a live example, or an unambiguous set of steps to -->
 <!--- reproduce this bug. Include code to reproduce, if relevant -->
-<!--- and make sure you have followed https://github.com/minio/minio/tree/release/docs/debugging to capture relevant logs -->
+<!--- and include the relevant Silo logs with secrets and credentials removed -->
 
 1.
 2.
@@ -37,10 +37,10 @@ assignees: ''
 
 ## Regression
 <!-- Is this issue a regression? (Yes / No) -->
-<!-- If Yes, optionally please include minio version or commit id or PR# that caused this regression, if you have these details. -->
+<!-- If Yes, optionally include the Silo version, commit id, or PR that caused the regression. -->
 
 ## Your Environment
 <!--- Include as many relevant details about the environment you experienced the bug in -->
-* Version used (`minio --version`):
+* Version used (`silo --version`):
 * Server setup and configuration:
 * Operating System and version (`uname -a`):

.github/ISSUE_TEMPLATE/config.yml

@@ -1,8 +1,8 @@
 blank_issues_enabled: false
 contact_links:
-  - name: MinIO Community Support
+  - name: Silo Documentation
-    url: https://slack.min.io
+    url: https://silo.pgsty.com/docs/
-    about: Community support via Slack - for questions and discussions
+    about: Installation, configuration, operations, and compatibility guidance
-  - name: MinIO Enterprise Support (SUBNET)
+  - name: Private Security Report
-    url: https://min.io/pricing
+    url: https://github.com/pgsty/minio/security/advisories/new
-    about: Enterprise support with SLA - for production deployments and feature requests
+    about: Privately report a suspected vulnerability in Silo

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,8 +1,8 @@
-## Community Contribution License
+## Contribution License
-All community contributions in this pull request are licensed to the project maintainers
+
-under the terms of the [Apache 2 license](https://www.apache.org/licenses/LICENSE-2.0). 
+By submitting this pull request, I represent that I have the right to contribute
-By creating this pull request I represent that I have the right to license the 
+the changes and agree that they are distributed under this repository's
-contributions to the project maintainers under the Apache 2 license.
+[GNU Affero General Public License v3.0](../LICENSE).
 
 ## Description
 
@@ -13,6 +13,12 @@ contributions to the project maintainers under the Apache 2 license.
 ## How to test this PR?
 
 
+## Compatibility impact
+
+<!-- Note effects on APIs, clients, MINIO_* configuration, metrics, headers,
+routes, storage metadata, module/import paths, upgrades, or rollback. -->
+
+
 ## Types of changes
 - [ ] Bug fix (non-breaking change which fixes an issue)
 - [ ] New feature (non-breaking change which adds functionality)
@@ -22,5 +28,8 @@ contributions to the project maintainers under the Apache 2 license.
 ## Checklist:
 - [ ] Fixes a regression (If yes, please add `commit-id` or `PR #` here)
 - [ ] Unit tests added/updated
+- [ ] `make verifiers` passes
+- [ ] Relevant package tests and `make build` pass
+- [ ] Compatibility and rollback impact documented
 - [ ] Internal documentation updated
-- [ ] Create a documentation update request [here](https://github.com/minio/docs/issues/new?label=doc-change,title=Doc+Updated+Needed+For+PR+github.com%2fminio%2fminio%2fpull%2fNNNNN)
+- [ ] Public documentation update opened in `pgsty/silo.pgsty.com`, if needed

COMPLIANCE.md

@@ -1,7 +1,17 @@
 # AGPLv3 Compliance
 
-We have designed MinIO as an Open Source software for the Open Source software community. This requires applications to consider whether their usage of MinIO is in compliance with the GNU AGPLv3 [license](https://github.com/minio/minio/blob/master/LICENSE).
+Silo is distributed under the [GNU Affero General Public License v3.0](LICENSE).
+It incorporates source code from the MinIO project and preserves the original
+copyright, license, and attribution notices in [`NOTICE`](NOTICE),
+[`CREDITS`](CREDITS), and source-file headers.
 
-MinIO cannot make the determination as to whether your application's usage of MinIO is in compliance with the AGPLv3 license requirements. You should instead rely on your own legal counsel or licensing specialists to audit and ensure your application is in compliance with the licenses of MinIO and all other open-source projects with which your application integrates or interacts. We understand that AGPLv3 licensing is complex and nuanced. It is for that reason we strongly encourage using experts in licensing to make any such determinations around compliance instead of relying on apocryphal or anecdotal advice.
+You are responsible for determining how the AGPLv3 applies to your use,
+modification, deployment, and distribution of Silo and its dependencies. The
+Silo maintainers cannot provide legal advice or determine whether a particular
+application or service satisfies the license. Consult qualified counsel when
+the obligations are material to your deployment.
 
-[MinIO Commercial Licensing](https://min.io/pricing) is the best option for applications that trigger AGPLv3 obligations (e.g. open sourcing your application). Applications using MinIO - or any other OSS-licensed code - without validating their usage do so at their own risk.
+If you convey modified binaries or provide network access to a modified
+version, review the complete AGPLv3 text and ensure that the corresponding
+source and notices are made available as required. Dependency licenses and
+separate notices continue to apply independently.

CONTRIBUTING.md

@@ -1,55 +1,63 @@
-# MinIO Contribution 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/)
+# Contributing to Silo
 
-``MinIO`` community welcomes your contribution. To make the process as seamless as possible, we recommend you read this contribution guide.
+Silo welcomes focused contributions that improve security, reliability,
+compatibility, packaging, tests, or maintainability. This repository preserves
+MinIO-compatible interfaces and storage formats, so changes must identify and
+test any compatibility impact.
 
 ## Development Workflow
 
-Start by forking the MinIO GitHub repository, make changes in a branch and then send a pull request. We encourage pull requests to discuss code changes. Here are the steps in details:
+Fork the current Silo source repository, create a topic branch, and submit a
+pull request. Discuss broad or compatibility-sensitive changes in an issue
+before implementation.
 
-### Setup your MinIO GitHub Repository
+### Set up a checkout
-
-Fork [MinIO upstream](https://github.com/minio/minio/fork) source repository to your own personal repository. Copy the URL of your MinIO fork (you will need it for the `git clone` command below).
 
 ```sh
-git clone https://github.com/minio/minio
+git clone https://github.com/pgsty/minio
 cd minio
-go install -v
+go build -o silo .
-ls $(go env GOPATH)/bin/minio
+./silo --version
 ```
 
-### Set up git remote as ``upstream``
+The `pgsty/minio` source-repository name is transitional. Follow repository
+redirects after the coordinated `pgsty/silo` cutover.
+
+### Keep the lineage remote separate
 
 ```sh
-$ cd minio
+git remote add lineage https://github.com/minio/minio
-$ git remote add upstream https://github.com/minio/minio
+git fetch lineage
-$ git fetch upstream
-$ git merge upstream/master
-...
 ```
 
+Do not merge an upstream branch into a pull request unless the maintainers have
+agreed on the scope. Silo intentionally carries a small downstream delta.
+
 ### Create your feature branch
 
-Before making code changes, make sure you create a separate branch for these changes
+Create a separate branch before making code changes:
 
 ```
 git checkout -b my-new-feature
 ```
 
-### Test MinIO server changes
+### Test Silo server changes
 
-After your code changes, make sure
+Before opening a pull request:
 
-- To add test cases for the new code. If you have questions about how to do it, please ask on our [Slack](https://slack.min.io) channel.
+- Add or update tests for changed behavior.
-- To run `make verifiers`
+- Run `make verifiers`.
-- To squash your commits into a single commit. `git rebase -i`. It's okay to force update your pull request.
+- Run the smallest relevant package tests, then `make test` when practical.
-- To run `make test` and `make build` completes.
+- Run `make build` and confirm the generated executable is `silo`.
+- Explain any preserved `MINIO_*`, `minio_*`, `x-minio-*`, `/minio/*`,
+  `.minio.sys`, ARN, module/import-path, or serialized compatibility name.
 
 ### Commit changes
 
-After verification, commit your changes. This is a [great post](https://chris.beams.io/posts/git-commit/) on how to write useful commit messages
+After verification, commit your changes with a concise message:
 
 ```
-git commit -am 'Add some feature'
+git commit -am 'Fix object replication retry handling'
 ```
 
 ### Push to the branch
@@ -62,13 +70,17 @@ git push origin my-new-feature
 
 ### Create a Pull Request
 
-Pull requests can be created via GitHub. Refer to [this document](https://help.github.com/articles/creating-a-pull-request/) for detailed steps on how to create a pull request. After a Pull Request gets peer reviewed and approved, it will be merged.
+Pull requests should include motivation, reproduction steps where applicable,
+test evidence, compatibility notes, and documentation impact. Public product
+documentation is owned by the separate
+[`pgsty/silo.pgsty.com`](https://github.com/pgsty/silo.pgsty.com) repository.
 
 ## FAQs
 
-### How does ``MinIO`` manage dependencies?
+### How does Silo manage dependencies?
 
-``MinIO`` uses `go mod` to manage its dependencies.
+Silo uses Go modules. Preserve the compatibility module and import paths in
+`go.mod`; downstream forks are selected with explicit `replace` directives.
 
 - Run `go get foo/bar` in the source folder to add the dependency to `go.mod` file.
 
@@ -77,6 +89,7 @@ To remove a dependency
 - Edit your code and remove the import reference.
 - Run `go mod tidy` in the source folder to remove dependency from `go.mod` file.
 
-### What are the coding guidelines for MinIO?
+### What are the coding guidelines?
 
-``MinIO`` is fully conformant with Golang style. Refer: [Effective Go](https://github.com/golang/go/wiki/CodeReviewComments) article from Golang project. If you observe offending code, please feel free to send a pull request or ping us on [Slack](https://slack.min.io).
+Follow the existing Go style, run `gofmt` on changed Go files, and keep changes
+compact. See the Go project's [code review comments](https://go.dev/wiki/CodeReviewComments).

NOTICE

@@ -7,3 +7,9 @@ The MinIO project contains unmodified/modified subcomponents too with
 separate copyright notices and license terms. Your use of the source
 code for these subcomponents is subject to the terms and conditions
 of GNU Affero General Public License 3.0.
+
+Silo Project modifications, (C) 2025-2026 The Silo Authors.
+
+Silo is an independent community-maintained project incorporating MinIO
+source code. It is not affiliated with or endorsed by MinIO, Inc. Modified
+source and Silo release artifacts are maintained by the Silo project.

PULL_REQUESTS_ETIQUETTE.md

@@ -1,12 +1,12 @@
-# MinIO Pull Request Guidelines
+# Silo Pull Request Guidelines
 
-These guidelines ensure high-quality commits in MinIO’s GitHub repositories, maintaining 
+These guidelines ensure high-quality commits in Silo's GitHub repositories, maintaining
 a clear, valuable commit history for our open-source projects. They apply to all contributors,
 fostering efficient reviews and robust code.
 
 ## Why Pull Requests?
 
-Pull Requests (PRs) drive quality in MinIO’s codebase by:
+Pull Requests (PRs) drive quality in Silo's codebase by:
 - Enabling peer review without pair programming.
 - Documenting changes for future reference.
 - Ensuring commits tell a clear story of development.
@@ -15,12 +15,12 @@ Pull Requests (PRs) drive quality in MinIO’s codebase by:
 
 ## Crafting a Quality PR
 
-A strong MinIO PR:
+A strong Silo PR:
 - Delivers a complete, valuable change (feature, bug fix, or improvement).
 - Has a concise title (e.g., `[S3] Fix bucket policy parsing #1234`) and a summary with context, referencing issues (e.g., `#1234`).
 - Contains well-written, logical commits explaining *why* changes were made (e.g., “Add S3 bucket tagging support so that users can organize resources efficiently”).
 - Is small, focused, and easy to review—ideally one commit, unless multiple commits better narrate complex work.
-- Adheres to MinIO’s coding standards (e.g., Go style, error handling, testing).
+- Adheres to Silo's coding standards (e.g., Go style, error handling, testing).
 
 PRs must flow smoothly through review to reach production. Large PRs should be split into smaller, manageable ones.
 
@@ -48,14 +48,14 @@ PRs must flow smoothly through review to reach production. Large PRs should be s
 
 ## Reviewing PRs
 
-Reviewers ensure MinIO’s commit history remains a clear, reliable record. Responsibilities include:
+Reviewers ensure Silo's commit history remains a clear, reliable record. Responsibilities include:
 
 1. **Commit Quality**:
    - Verify each commit explains *why* the change was made (e.g., “So that…”).
    - Request rebasing if commits are unclear, redundant, or lack context (e.g., “Please squash typo fixes into the parent commit”).
 
 2. **Code Quality**:
-   - Check adherence to MinIO’s Go standards (e.g., error handling, documentation).
+   - Check adherence to Silo's Go standards (e.g., error handling, documentation).
    - Ensure tests cover new code and pass CI.
    - Flag bugs or critical issues for immediate fixes; suggest non-blocking improvements as follow-up issues.
 
@@ -65,7 +65,7 @@ Reviewers ensure MinIO’s commit history remains a clear, reliable record. Resp
    - If unable to complete the review, tag another reviewer (e.g., `@username please take over`).
 
 4. **Shared Responsibility**:
-   - All MinIO contributors are reviewers. The first commenter on a PR owns the review unless they delegate.
+   - All Silo contributors are reviewers. The first commenter on a PR owns the review unless they delegate.
    - Multiple reviewers are encouraged for complex PRs.
 
 5. **No Self-Edits**:
@@ -80,14 +80,14 @@ Reviewers ensure MinIO’s commit history remains a clear, reliable record. Resp
 
 - **Small PRs**: Easier to review, faster to merge. Split large changes logically.
 - **Clear Commits**: Use `git rebase -i` to refine history before submitting.
-- **Engage Early**: Discuss complex changes in issues or Slack (https://slack.min.io) before coding.
+- **Engage Early**: Discuss complex changes in a GitHub issue before coding.
 - **Be Responsive**: Address reviewer feedback promptly to keep PRs moving.
 - **Learn from Reviews**: Use feedback to improve future contributions.
 
 ## Resources
 
-- [MinIO Coding Standards](https://github.com/minio/minio/blob/master/CONTRIBUTING.md)
+- [Silo Contribution Guide](CONTRIBUTING.md)
 - [Effective Commit Messages](https://mislav.net/2014/02/hidden-documentation/)
 - [GitHub PR Tips](https://github.com/blog/1943-how-to-write-the-perfect-pull-request)
 
-By following these guidelines, we ensure MinIO’s codebase remains high-quality, maintainable, and a joy to contribute to. Happy coding!
+By following these guidelines, we ensure Silo's codebase remains high-quality, maintainable, and a joy to contribute to. Happy coding!

README.md

@@ -4,7 +4,7 @@
 
 
 <p align="center">
-  <strong>A conservatively maintained MinIO fork</strong><br>
+  <strong>Conservatively maintained S3-compatible object storage</strong><br>
   Security maintenance, versioned release artifacts, and operational continuity for existing deployments.
 </p>
 
@@ -20,7 +20,7 @@
 
 <p align="center">
   <a href="https://github.com/pgsty/minio/releases"><img alt="GitHub Release" src="https://img.shields.io/github/v/release/pgsty/minio?include_prereleases&label=release&logo=github"></a>
-  <a href="https://hub.docker.com/r/pgsty/minio"><img alt="Docker Pulls" src="https://img.shields.io/docker/pulls/pgsty/minio?logo=docker"></a>
+  <a href="https://hub.docker.com/r/pgsty/silo"><img alt="Docker Pulls" src="https://img.shields.io/docker/pulls/pgsty/silo?logo=docker"></a>
   <a href="go.mod"><img alt="Go Version" src="https://img.shields.io/github/go-mod/go-version/pgsty/minio?logo=go"></a>
   <a href="LICENSE"><img alt="License" src="https://img.shields.io/badge/license-AGPLv3-blue"></a>
 </p>
@@ -30,7 +30,7 @@
 
 ## Overview
 
-Silo maintains one downstream release line based on MinIO [`RELEASE.2025-12-03T12-00-00Z`](https://github.com/minio/minio/releases/tag/RELEASE.2025-12-03T12-00-00Z). It provides maintained builds and release artifacts for existing MinIO-compatible deployments after upstream community distribution ended. Pigsty uses this fork for object storage as an optional PG backup repo.
+Silo maintains one downstream release line derived from the open-source MinIO server. It provides maintained builds and release artifacts for existing MinIO-compatible deployments after upstream community distribution ended. Pigsty uses Silo for object storage, including as an optional PostgreSQL backup repository.
 
 The official project portal is [silo.pgsty.com](https://silo.pgsty.com/). It brings documentation, downloads, release and security notes, and project background together. English is served at the site root; Chinese is available under [/zh/](https://silo.pgsty.com/zh/).
 
@@ -70,8 +70,11 @@ Changes are kept narrow and tested where practical. Maintenance is best effort;
 
 Silo aims to preserve:
 
-- MinIO-compatible S3 APIs, configuration, environment variables, and CLI conventions;
+- the `github.com/minio/minio` module path and `github.com/minio/*` import paths;
-- `RELEASE.YYYY-MM-DDTHH-MM-SSZ` tags, container entrypoints, and common deployment workflows.
+- MinIO-compatible S3 APIs, wire behavior, `MINIO_*` environment variables, metrics, protocol headers, reserved routes, and storage metadata;
+- `RELEASE.YYYY-MM-DDTHH-MM-SSZ` tags and legacy `minio …` container argv translation.
+
+Silo-owned delivery surfaces use the `silo` executable, package, service, Helm chart, and `pgsty/silo` container image. Native artifacts intentionally do not install a `minio` binary alias.
 
 Compatibility is the default constraint. Silo preserves existing wire, client, configuration, and operational behavior whenever doing so remains safe. Compatibility is broken only when necessary to close a major security issue, and the release notes must identify the affected behavior and migration path. Treat each release as a downstream upgrade: pin versions, review [release notes](https://silo.pgsty.com/blog/release/) and [security advisories](docs/security/advisories.md), keep a rollback path, and test before production use.
 
@@ -82,12 +85,88 @@ Use [Download & Install](https://silo.pgsty.com/download/) to choose an installa
 | Artifact | Location |
 | :-- | :-- |
 | Source | [`github.com/pgsty/minio`](https://github.com/pgsty/minio) |
-| Container image | [`pgsty/minio`](https://hub.docker.com/r/pgsty/minio), multi-arch for `linux/amd64` and `linux/arm64` |
+| Container image | [`pgsty/silo`](https://hub.docker.com/r/pgsty/silo), multi-arch for `linux/amd64` and `linux/arm64` |
 | Server binaries and checksums | [GitHub Releases](https://github.com/pgsty/minio/releases) for Linux, macOS, and Windows on `amd64` and `arm64` |
 | Linux packages | RPM, DEB, and APK artifacts, also distributed through the [Pigsty repository](https://pigsty.io/docs/repo/) |
 | Client | [`pgsty/mc`](https://github.com/pgsty/mc), bundled in the container as `mcli` with an `mc` compatibility alias |
-| Console | Maintained [`georgmangold/console`](https://github.com/georgmangold/console) fork, embedded in the server build |
+| Console | [`pgsty/silo-console`](https://github.com/pgsty/silo-console), embedded through the compatibility import path `github.com/minio/console` |
-| Shared library | [`pgsty/silo-pkg`](https://github.com/pgsty/silo-pkg) v3.7.0, consumed through a `replace` directive while preserving `github.com/minio/pkg/v3` import paths ([release notes](https://silo.pgsty.com/blog/release/pkg-3.7.0/)) |
+| Shared library | [`pgsty/silo-pkg`](https://github.com/pgsty/silo-pkg) v3.11.0, consumed through a `replace` directive while preserving the `github.com/minio/pkg/v3` import path |
+
+Each new release publishes per-archive and per-package SPDX JSON SBOMs. The archive and package checksum manifests have detached keyless Sigstore bundles, while GitHub artifact attestations record signed provenance for every downloadable artifact and the multi-architecture container image.
+
+After downloading an archive and its release files, verify integrity, the
+published SBOM, the signed manifest, and build provenance independently:
+
+```bash
+# Integrity: choose the line for the artifact you downloaded.
+grep -F '  silo_<version>_linux_amd64.tar.gz' \
+  silo_<version>_checksums.txt | sha256sum --check
+
+# The archive SBOM is a separate checksummed release artifact.
+grep -F '  silo_<version>_linux_amd64.tar.gz.sbom.json' \
+  silo_<version>_checksums.txt | sha256sum --check
+
+# Signature over the archive/SBOM checksum manifest.
+cosign verify-blob \
+  --bundle silo_<version>_checksums.txt.sigstore.json \
+  --certificate-identity-regexp \
+    '^https://github.com/pgsty/(minio|silo)/\.github/workflows/release\.yml@refs/(tags/RELEASE\..+|heads/(master|main))$' \
+  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
+  silo_<version>_checksums.txt
+
+# Signed build provenance (online verification against this repository).
+gh attestation verify silo_<version>_linux_amd64.tar.gz \
+  --repo pgsty/minio
+```
+
+For packages, use `silo_<version>_packages_checksums.txt` and its adjacent
+Sigstore bundle with the same identity and issuer constraints. Inspect the
+verified SPDX JSON SBOM with your preferred SPDX tooling. Verify the
+multi-architecture container provenance by digest:
+
+```bash
+gh attestation verify \
+  oci://index.docker.io/pgsty/silo@sha256:<manifest-digest> \
+  --repo pgsty/minio
+```
+
+The platform SBOM attestations are attached to the `amd64` and `arm64` image
+digests rather than the multi-architecture manifest. Verify each one explicitly:
+
+```bash
+gh attestation verify \
+  oci://index.docker.io/pgsty/silo@sha256:<platform-digest> \
+  --repo pgsty/minio \
+  --predicate-type https://spdx.dev/Document/v2.3
+```
+
+Verification by digest avoids trusting a mutable image tag.
+
+### Native package migration
+
+The `silo` RPM, DEB, and APK do not declare `Provides`, `Obsoletes`,
+`Replaces`, or package-level `Conflicts` against `minio`. They can therefore be
+installed beside an existing MinIO package without silently replacing it. The
+two systemd units conflict at runtime, so switch them explicitly rather than
+starting both.
+
+Before switching, record the old unit's enabled/active state and `User`/`Group`,
+and back up `/etc/default/minio`. Silo reads that legacy defaults file first and
+then `/etc/default/silo`; administrator-set values in the latter take
+precedence. If the existing data must continue to run under its original
+UID/GID, create `/etc/systemd/system/silo.service.d/10-legacy-user.conf`:
+
+```ini
+[Service]
+User=<legacy-user>
+Group=<legacy-group>
+```
+
+Run `systemctl daemon-reload`, then disable and stop `minio.service` before
+enabling and starting `silo.service`. Verify health, S3, Admin API, metrics, and
+logs before masking or uninstalling the old service. Do not recursively change
+data ownership as part of the package migration; keep the old package and unit
+available during the rollback window.
 
 ## Quick Start
 
@@ -105,7 +184,7 @@ docker run -d --name silo \
   -e MINIO_ROOT_USER \
   -e MINIO_ROOT_PASSWORD \
   -v "$PWD/data:/data" \
-  pgsty/minio:latest server /data --console-address ":9001"
+  docker.io/pgsty/silo:latest server /data --console-address ":9001"
 ```
 
 Open the console at <http://localhost:9001>; the S3 API listens on <http://localhost:9000>.
@@ -125,15 +204,15 @@ docker exec silo mcli ls local
 Build the server from source:
 
 ```bash
-go build -o minio .
+go build -o silo .
-./minio --version
+./silo --version
 ```
 
 For other installation paths—including native packages, binaries, Podman, Kubernetes, source, and Pigsty Ansible—use [Download & Install](https://silo.pgsty.com/download/). For production deployment and administration, start with the [Silo documentation](https://silo.pgsty.com/docs/). Pigsty users can also use the [Pigsty MinIO module](https://pigsty.io/docs/minio/).
 
 ## Security
 
-Security fixes target the active `master` branch and are recorded in the [advisory log](docs/security/advisories.md) and the portal's [security notes](https://silo.pgsty.com/blog/security/). Report vulnerabilities privately as described in [`SECURITY.md`](SECURITY.md) and [`VULNERABILITY_REPORT.md`](VULNERABILITY_REPORT.md). Report issues that also affect upstream MinIO there as well.
+Security fixes target the active development branch and are recorded in the [advisory log](docs/security/advisories.md) and the portal's [security notes](https://silo.pgsty.com/blog/security/). Report vulnerabilities privately as described in [`SECURITY.md`](SECURITY.md) and [`VULNERABILITY_REPORT.md`](VULNERABILITY_REPORT.md). Report issues that also affect upstream MinIO there as well.
 
 ## Contributing
 
@@ -153,4 +232,4 @@ This project was created in response to changes in the upstream community distri
 
 ## License and Trademark
 
-The server remains licensed under the [GNU Affero General Public License v3.0](LICENSE). See [`CREDITS`](CREDITS) for upstream authorship and attribution. MinIO is a trademark of MinIO, Inc. Silo and `pgsty/minio` are independent community efforts and are not affiliated with or endorsed by MinIO, Inc.
+The server remains licensed under the [GNU Affero General Public License v3.0](LICENSE). See [`CREDITS`](CREDITS) and [`NOTICE`](NOTICE) for upstream authorship and attribution. MinIO is a trademark of MinIO, Inc. Silo is an independent community project and is not affiliated with or endorsed by MinIO, Inc. The source repository retains the transitional `pgsty/minio` name until the coordinated repository cutover.

README_ZH.md

@@ -4,7 +4,7 @@
 </h1>
 
 <p align="center">
-  <strong>审慎维护的 MinIO 社区分支</strong><br>
+  <strong>审慎维护的 S3 兼容对象存储</strong><br>
   为现有部署提供安全维护、带版本的发行产物与持续运维支持。
 </p>
 
@@ -20,7 +20,7 @@
 
 <p align="center">
   <a href="https://github.com/pgsty/minio/releases"><img alt="GitHub Release" src="https://img.shields.io/github/v/release/pgsty/minio?include_prereleases&label=release&logo=github"></a>
-  <a href="https://hub.docker.com/r/pgsty/minio"><img alt="Docker Pulls" src="https://img.shields.io/docker/pulls/pgsty/minio?logo=docker"></a>
+  <a href="https://hub.docker.com/r/pgsty/silo"><img alt="Docker Pulls" src="https://img.shields.io/docker/pulls/pgsty/silo?logo=docker"></a>
   <a href="go.mod"><img alt="Go Version" src="https://img.shields.io/github/go-mod/go-version/pgsty/minio?logo=go"></a>
   <a href="LICENSE"><img alt="License" src="https://img.shields.io/badge/license-AGPLv3-blue"></a>
 </p>
@@ -30,7 +30,7 @@
 
 ## 概述
 
-Silo 维护一条基于 MinIO [`RELEASE.2025-12-03T12-00-00Z`](https://github.com/minio/minio/releases/tag/RELEASE.2025-12-03T12-00-00Z) 的下游版本线，为上游停止社区发行后仍在运行 MinIO 兼容部署的用户提供持续构建与发行产物。
+Silo 维护一条源自开源 MinIO 服务端的下游版本线，为上游停止社区发行后仍在运行 MinIO 兼容部署的用户提供持续构建与发行产物。
 
 Pigsty 使用本分支提供对象存储，包括 PostgreSQL 备份存储。
 
@@ -73,9 +73,11 @@ Pigsty 使用本分支提供对象存储，包括 PostgreSQL 备份存储。
 
 Silo 尽量保留：
 
-- `minio` 可执行文件与 `github.com/minio/minio` module path；
+- `github.com/minio/minio` module path 与 `github.com/minio/*` 导入路径；
-- MinIO 兼容的 S3 API、配置、环境变量与命令行约定；
+- MinIO 兼容的 S3 API、线协议、`MINIO_*` 环境变量、指标、协议头、保留路由与存储元数据；
-- `RELEASE.YYYY-MM-DDTHH-MM-SSZ` 标签、容器入口与常见部署方式。
+- `RELEASE.YYYY-MM-DDTHH-MM-SSZ` 标签，以及容器入口对旧式 `minio …` 参数的转换。
+
+Silo 自有交付面统一使用 `silo` 可执行文件、软件包、服务、Helm Chart 与 `pgsty/silo` 容器镜像；原生交付物不会安装 `minio` 二进制别名。
 
 兼容性是默认约束。只要不会留下安全问题，Silo 就保留既有的协议、客户端、配置与运维行为；只有在修复重大安全问题确有必要时才会打破兼容，并在版本说明中明确受影响行为与迁移方式。每个版本仍应视为下游升级：锁定版本，阅读[版本说明](https://silo.pgsty.com/zh/blog/release/)与[安全公告](docs/security/advisories.md)，保留回滚路径，并在生产使用前完成测试。
 
@@ -86,12 +88,83 @@ Silo 尽量保留：
 | 产物 | 位置 |
 | :-- | :-- |
 | 源码 | [`github.com/pgsty/minio`](https://github.com/pgsty/minio) |
-| 容器镜像 | [`pgsty/minio`](https://hub.docker.com/r/pgsty/minio)，支持 `linux/amd64` 与 `linux/arm64` 多架构清单 |
+| 容器镜像 | [`pgsty/silo`](https://hub.docker.com/r/pgsty/silo)，支持 `linux/amd64` 与 `linux/arm64` 多架构清单 |
 | 服务端二进制与校验和 | [GitHub Releases](https://github.com/pgsty/minio/releases)，覆盖 Linux、macOS、Windows 的 `amd64` 与 `arm64` |
 | Linux 软件包 | RPM、DEB、APK，并通过 [Pigsty 软件仓库](https://pigsty.cc/docs/repo/) 分发 |
 | 客户端 | [`pgsty/mc`](https://github.com/pgsty/mc)，容器内以 `mcli` 提供，并保留 `mc` 兼容别名 |
-| 管理控制台 | 社区维护的 [`georgmangold/console`](https://github.com/georgmangold/console)，嵌入服务端构建 |
+| 管理控制台 | [`pgsty/silo-console`](https://github.com/pgsty/silo-console)，通过兼容导入路径 `github.com/minio/console` 嵌入服务端构建 |
-| 共享库 | [`pgsty/silo-pkg`](https://github.com/pgsty/silo-pkg) v3.7.0，通过 `replace` 指令使用，同时保留 `github.com/minio/pkg/v3` 导入路径（[版本说明](https://silo.pgsty.com/zh/blog/release/pkg-3.7.0/)） |
+| 共享库 | [`pgsty/silo-pkg`](https://github.com/pgsty/silo-pkg) v3.11.0，通过 `replace` 指令使用，同时保留 `github.com/minio/pkg/v3` 导入路径 |
+
+每个新版本都会为各平台归档和软件包发布 SPDX JSON SBOM。归档与软件包的校验和清单分别带有无长期密钥的 Sigstore 签名包；GitHub 制品证明则为全部可下载产物及多架构容器镜像记录已签名的构建来源。
+
+下载归档及配套文件后，请分别验证完整性、已发布 SBOM、签名清单与构建来源：
+
+```bash
+# 完整性：选择与你下载产物相符的一行。
+grep -F '  silo_<version>_linux_amd64.tar.gz' \
+  silo_<version>_checksums.txt | sha256sum --check
+
+# 归档 SBOM 是另一个独立校验的 Release 产物。
+grep -F '  silo_<version>_linux_amd64.tar.gz.sbom.json' \
+  silo_<version>_checksums.txt | sha256sum --check
+
+# 验证归档/SBOM 校验和清单的签名。
+cosign verify-blob \
+  --bundle silo_<version>_checksums.txt.sigstore.json \
+  --certificate-identity-regexp \
+    '^https://github.com/pgsty/(minio|silo)/\.github/workflows/release\.yml@refs/(tags/RELEASE\..+|heads/(master|main))$' \
+  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
+  silo_<version>_checksums.txt
+
+# 在线验证本仓库签发的构建来源。
+gh attestation verify silo_<version>_linux_amd64.tar.gz \
+  --repo pgsty/minio
+```
+
+软件包使用 `silo_<version>_packages_checksums.txt` 及其相邻的 Sigstore
+签名包，并使用相同的 identity 与 issuer 约束；请用 SPDX 工具检查已验证的
+SPDX JSON SBOM。按 digest 验证多架构容器清单的构建来源：
+
+```bash
+gh attestation verify \
+  oci://index.docker.io/pgsty/silo@sha256:<manifest-digest> \
+  --repo pgsty/minio
+```
+
+分架构 SBOM 证明附在 `amd64` 与 `arm64` 平台镜像的 digest 上，而非多架构
+清单上，需要分别显式验证：
+
+```bash
+gh attestation verify \
+  oci://index.docker.io/pgsty/silo@sha256:<platform-digest> \
+  --repo pgsty/minio \
+  --predicate-type https://spdx.dev/Document/v2.3
+```
+
+按 digest 验证可避免信任可变镜像标签。
+
+### 原生软件包迁移
+
+`silo` RPM、DEB 与 APK 不针对 `minio` 声明 `Provides`、`Obsoletes`、
+`Replaces` 或包级 `Conflicts`，因此可以与已有 MinIO 软件包并存安装，
+不会被普通升级静默替换。两个 systemd unit 在运行时互斥，应由管理员显式
+切换，不能同时启动。
+
+切换前请记录旧 unit 的 enabled/active 状态与 `User`/`Group`，并备份
+`/etc/default/minio`。Silo 先读取该旧配置，再读取 `/etc/default/silo`；后者
+中由管理员设置的同名变量优先。如现有数据必须继续使用原 UID/GID，请创建
+`/etc/systemd/system/silo.service.d/10-legacy-user.conf`：
+
+```ini
+[Service]
+User=<legacy-user>
+Group=<legacy-group>
+```
+
+执行 `systemctl daemon-reload`，先停用并停止 `minio.service`，再启用并启动
+`silo.service`。确认健康检查、S3、Admin API、指标与日志后，才 mask 或卸载
+旧服务。软件包迁移期间不要递归修改数据属主；在回滚观察窗口内保留旧包与
+旧 unit。
 
 ## 快速开始
 
@@ -109,7 +182,7 @@ docker run -d --name silo \
   -e MINIO_ROOT_USER \
   -e MINIO_ROOT_PASSWORD \
   -v "$PWD/data:/data" \
-  pgsty/minio:latest server /data --console-address ":9001"
+  docker.io/pgsty/silo:latest server /data --console-address ":9001"
 ```
 
 管理控制台位于 <http://localhost:9001>，S3 API 位于 <http://localhost:9000>。
@@ -129,15 +202,15 @@ docker exec silo mcli ls local
 从源码构建服务端：
 
 ```bash
-go build -o minio .
+go build -o silo .
-./minio --version
+./silo --version
 ```
 
 其他安装方式（包括原生软件包、二进制、Podman、Kubernetes、源码构建与 Pigsty Ansible）请前往[下载与安装](https://silo.pgsty.com/zh/download/)；生产部署与管理请从 [Silo 中文文档](https://silo.pgsty.com/zh/docs/)开始。Pigsty 用户也可以直接使用 [Pigsty MinIO 模块](https://pigsty.cc/docs/minio/)。
 
 ## 安全
 
-安全修复面向活跃的 `master` 分支，并记录在仓库[安全公告](docs/security/advisories.md)与门户[安全通告](https://silo.pgsty.com/zh/blog/security/)中。请按照 [`SECURITY.md`](SECURITY.md) 与 [`VULNERABILITY_REPORT.md`](VULNERABILITY_REPORT.md) 私密报告漏洞；同时影响上游 MinIO 的问题也应向上游报告。
+安全修复面向当前活跃开发分支，并记录在仓库[安全公告](docs/security/advisories.md)与门户[安全通告](https://silo.pgsty.com/zh/blog/security/)中。请按照 [`SECURITY.md`](SECURITY.md) 与 [`VULNERABILITY_REPORT.md`](VULNERABILITY_REPORT.md) 私密报告漏洞；同时影响上游 MinIO 的问题也应向上游报告。
 
 ## 参与贡献
 
@@ -158,6 +231,6 @@ Issue 与 Pull Request 应说明受影响版本、复现步骤、影响、预期
 
 ## 许可证与商标
 
-服务端继续采用 [GNU Affero General Public License v3.0](LICENSE) 发布。上游作者与署名信息见 [`CREDITS`](CREDITS)。
+服务端继续采用 [GNU Affero General Public License v3.0](LICENSE) 发布。上游作者与署名信息见 [`CREDITS`](CREDITS) 与 [`NOTICE`](NOTICE)。
 
-MinIO 是 MinIO, Inc. 的商标。Silo、Pigsty 与 `pgsty/minio` 均为独立社区项目，与 MinIO, Inc. 不存在隶属或背书关系。
+MinIO 是 MinIO, Inc. 的商标。Silo 是独立社区项目，与 MinIO, Inc. 不存在隶属或背书关系；源码仓库在协调切换完成前暂时保留过渡名称 `pgsty/minio`。

SECURITY.md

@@ -1,18 +1,25 @@
 # Security Policy
 
-This repository is the `pgsty/minio` community fork of `minio/minio`. Upstream MinIO security contacts do not handle fork-specific fixes or release notes for this repository.
+Silo is an independent, community-maintained object-storage server derived from
+the open-source MinIO server. The source repository retains the transitional
+name `pgsty/minio` until the coordinated repository cutover. Upstream MinIO
+security contacts do not handle Silo-specific fixes or release notes.
 
 ## Supported Versions
 
-Security fixes are tracked on the active `master` branch and summarized in [docs/security/advisories.md](docs/security/advisories.md).
+Security fixes are tracked on the active development branch and summarized in
+[docs/security/advisories.md](docs/security/advisories.md). Only the current
+Silo release line is supported unless an advisory says otherwise.
 
 ## Reporting a Vulnerability
 
 For vulnerabilities in this fork:
 
 1. Follow the fork-specific expectations in [VULNERABILITY_REPORT.md](VULNERABILITY_REPORT.md).
-2. Prefer the `pgsty/minio` repository's GitHub security reporting workflow when it is available.
+2. Prefer this repository's [private GitHub security advisory](https://github.com/pgsty/minio/security/advisories/new) workflow.
-3. If private reporting is not available, contact the maintainers through the `pgsty/minio` repository before publishing detailed exploit information.
+3. If private reporting is unavailable, contact the maintainers through the
+   repository without publishing exploit details until a private channel is
+   established.
 4. If you confirm the issue also affects upstream `minio/minio`, report it upstream separately.
 
 ## Disclosure Process

VULNERABILITY_REPORT.md

@@ -1,6 +1,6 @@
 # Vulnerability Management Policy
 
-This document describes how the `pgsty/minio` maintainers investigate,
+This document describes how the Silo maintainers investigate,
 assess, and remediate reported vulnerabilities affecting this fork, any
 directly shipped component, or a direct / indirect dependency used by this
 repository.
@@ -8,7 +8,7 @@ repository.
 ## Scope
 
 This policy covers vulnerability reports opened by repository maintainers or
-external third parties against `pgsty/minio` itself, its release artifacts, or
+external third parties against Silo itself, its release artifacts, or
 dependencies that materially affect this fork.
 
 It defines the information needed for triage and the expected remediation
@@ -24,7 +24,7 @@ A useful vulnerability report should contain the following information:
   a well-established vulnerability identifier, such as a CVE or GHSA ID, can
   be used instead.
 
-Based on the report, the `pgsty/minio` maintainers investigate:
+Based on the report, the Silo maintainers investigate:
 
 - Whether the reported vulnerability exists.
 - The conditions that are required such that the vulnerability can be exploited.

code_of_conduct.md

@@ -58,10 +58,11 @@ further defined and clarified by project maintainers.
 ## Enforcement
 
 Instances of abusive, harassing, or otherwise unacceptable behavior may be
-reported by contacting the project team at dev@min.io. The project team
+reported to the Silo maintainers through this repository. When confidentiality
-will review and investigate all complaints, and will respond in a way that it deems
+is required, ask a maintainer to establish a private channel before providing
-appropriate to the circumstances. The project team is obligated to maintain
+sensitive details. The project team will review and investigate complaints and
-confidentiality with regard to the reporter of an incident.
+respond as appropriate to the circumstances. The project team is obligated to
+maintain confidentiality with regard to the reporter of an incident.
 Further details of specific enforcement policies may be posted separately.
 
 Project maintainers who do not follow or enforce the Code of Conduct in good

docs/auditlog/auditlog-echo.md

@@ -1,4 +1,4 @@
-# `auditlog-echo`: A tool to view MinIO Audit logs on the console
+# `auditlog-echo`: A tool to view Silo Audit logs on the console
 
 1. Run the tool with:
 
@@ -8,10 +8,10 @@ go run docs/auditlog/auditlog-echo.go
 
 The listen port has a default value (8080), but can be set with the `-port` flag.
 
-2. Configure audit logging in MinIO with for example:
+2. Configure audit logging in Silo with for example:
 
 ```
-mc admin config set myminio audit_webhook enable=on endpoint=http://localhost:8080
+mc admin config set mysilo audit_webhook enable=on endpoint=http://localhost:8080
 ```
 
-3. Make any requests to MinIO and see audit logs printed to the tool's console.
+3. Make any requests to Silo and see audit logs printed to the tool's console.

docs/batch-jobs/README.md

@@ -1,12 +1,12 @@
-# MinIO Batch Job
+# Silo Batch Job
-MinIO Batch jobs is an MinIO object management feature that lets you manage objects at scale. Jobs currently supported by MinIO
+Silo Batch jobs is an Silo object management feature that lets you manage objects at scale. Jobs currently supported by Silo
 
 - Replicate objects between buckets on multiple sites
 
 Upcoming Jobs
 
-- Copy objects from NAS to MinIO
+- Copy objects from NAS to Silo
-- Copy objects from HDFS to MinIO
+- Copy objects from HDFS to Silo
 
 ## Replication Job
 To perform replication via batch jobs, you create a job. The job consists of a job description YAML that describes
@@ -15,7 +15,7 @@ To perform replication via batch jobs, you create a job. The job consists of a j
 - Target location from where the objects must be copied to
 - Fine grained filtering is available to pick relevant objects from source to copy from
 
-MinIO batch jobs framework also provides
+Silo batch jobs framework also provides
 
 - Retrying a failed job automatically driven by user input
 - Monitoring job progress in real-time
@@ -64,7 +64,7 @@ replicate:
 	  #   - key: "name"
 	  #     value: "pick*" # match objects with tag 'name', with all values starting with 'pick'
 
-	  ## NOTE: metadata filter not supported when "source" is non MinIO.
+	  ## NOTE: metadata filter not supported when "source" is non Silo.
 	  # metadata:
 	  #   - key: "content-type"
 	  #     value: "image/*" # match objects with 'content-type', with all values starting with 'image/'
@@ -83,13 +83,14 @@ You can create and run multiple 'replication' jobs at a time there are no predef
 ## Batch Jobs Terminology
 
 ### Job
-A job is the basic unit of work for MinIO Batch Job. A job is a self describing YAML, once this YAML is submitted and evaluated - MinIO performs the requested actions on each of the objects obtained under the described criteria in job YAML file.
+A job is the basic unit of work for Silo Batch Job. A job is a self describing YAML, once this YAML is submitted and evaluated - Silo performs the requested actions on each of the objects obtained under the described criteria in job YAML file.
 
 ### Type
-Type describes the job type, such as replicating objects between MinIO sites. Each job performs a single type of operation across all objects that match the job description criteria.
+Type describes the job type, such as replicating objects between Silo sites. Each job performs a single type of operation across all objects that match the job description criteria.
 
 ## Batch Jobs via Commandline
-[mc](http://github.com/minio/mc) provides 'mc batch' command to create, start and manage submitted jobs.
+The compatible [`mc`](https://github.com/pgsty/mc) client provides the
+`mc batch` command to create, start, and manage submitted jobs.
 
 ```
 NAME:
@@ -102,7 +103,7 @@ COMMANDS:
   generate  generate a new batch job definition
   start     start a new batch job
   list, ls  list all current batch jobs
-  status    summarize job events on MinIO server in real-time
+  status    summarize job events on Silo server in real-time
   describe  describe job definition for a job
 ```
 
@@ -133,7 +134,7 @@ E24HH4nNMcgY5taynaPfxu  replicate       minioadmin      1 minute ago
 
 ### Real-time 'status' for a batch job
 ```
-mc batch status myminio/ E24HH4nNMcgY5taynaPfxu
+mc batch status mysilo/ E24HH4nNMcgY5taynaPfxu
 ●∙∙
 Objects:        28766
 Versions:       28766
@@ -145,7 +146,7 @@ CurrObjName:    share/doc/xml-core/examples/foo.xmlcatalogs
 
 ### 'describe' the batch job yaml.
 ```
-mc batch describe myminio/ E24HH4nNMcgY5taynaPfxu
+mc batch describe mysilo/ E24HH4nNMcgY5taynaPfxu
 replicate:
   apiVersion: v1
 ...

docs/bigdata/README.md

@@ -1,4 +1,4 @@
-# **Disaggregated HDP Spark and Hive with MinIO**
+# **Disaggregated HDP Spark and Hive with Silo**
 
 ## **1. Cloud-native Architecture**
 
@@ -6,20 +6,20 @@
 
 Kubernetes manages stateless Spark and Hive containers elastically on the compute nodes. Spark has native scheduler integration with Kubernetes. Hive, for legacy reasons, uses YARN scheduler on top of Kubernetes.
 
-All access to MinIO object storage is via S3/SQL SELECT API. In addition to the compute nodes, MinIO containers are also managed by Kubernetes as stateful containers with local storage (JBOD/JBOF) mapped as persistent local volumes. This architecture enables multi-tenant MinIO, allowing isolation of data between customers.
+All access to Silo object storage is via S3/SQL SELECT API. In addition to the compute nodes, Silo containers are also managed by Kubernetes as stateful containers with local storage (JBOD/JBOF) mapped as persistent local volumes. This architecture enables multi-tenant Silo, allowing isolation of data between customers.
 
-MinIO also supports multi-cluster, multi-site federation similar to AWS regions and tiers. Using MinIO Information Lifecycle Management (ILM), you can configure data to be tiered between NVMe based hot storage, and HDD based warm storage. All data is encrypted with per-object key. Access Control and Identity Management between the tenants are managed by MinIO using OpenID Connect or Kerberos/LDAP/AD.
+Silo also supports multi-cluster, multi-site federation similar to AWS regions and tiers. Using Silo Information Lifecycle Management (ILM), you can configure data to be tiered between NVMe based hot storage, and HDD based warm storage. All data is encrypted with per-object key. Access Control and Identity Management between the tenants are managed by Silo using OpenID Connect or Kerberos/LDAP/AD.
 
 ## **2. Prerequisites**
 
 - Install Hortonworks Distribution using this [guide.](https://docs.hortonworks.com/HDPDocuments/Ambari-2.7.1.0/bk_ambari-installation/content/ch_Installing_Ambari.html)
   - [Setup Ambari](https://docs.hortonworks.com/HDPDocuments/Ambari-2.7.1.0/bk_ambari-installation/content/set_up_the_ambari_server.html) which automatically sets up YARN
   - [Installing Spark](https://docs.hortonworks.com/HDPDocuments/HDP3/HDP-3.0.1/installing-spark/content/installing_spark.html)
-- Install MinIO Distributed Server using one of the guides below.
+- Install Silo Distributed Server using one of the guides below.
   - [Deployment based on Kubernetes](https://silo.pgsty.com/operations/deployments/kubernetes/)
-  - [Deployment based on MinIO Helm Chart](https://github.com/helm/charts/tree/master/stable/minio)
+  - [Deployment based on the Silo Helm chart](../../helm/silo/README.md)
 
-## **3. Configure Hadoop, Spark, Hive to use MinIO**
+## **3. Configure Hadoop, Spark, Hive to use Silo**
 
 After successful installation navigate to the Ambari UI `http://<ambari-server>:8080/` and login using the default credentials: [**_username: admin, password: admin_**]
 
@@ -31,7 +31,7 @@ Navigate to **Services** -> **HDFS** -> **CONFIGS** -> **ADVANCED** as shown bel
 
 ![hdfs-configs](https://github.com/pgsty/minio/blob/master/docs/bigdata/images/image2.png?raw=true "hdfs advanced configs")
 
-Navigate to **Custom core-site** to configure MinIO parameters for `_s3a_` connector
+Navigate to **Custom core-site** to configure Silo parameters for `_s3a_` connector
 
 ![s3a-config](https://github.com/pgsty/minio/blob/master/docs/bigdata/images/image5.png?raw=true "custom core-site")
 
@@ -40,7 +40,7 @@ sudo pip install yq
 alias kv-pairify='yq ".configuration[]" | jq ".[]" | jq -r ".name + \"=\" + .value"'
 ```
 
-Let's take for example a set of 12 compute nodes with an aggregate memory of _1.2TiB_, we need to do following settings for optimal results. Add the following optimal entries for _core-site.xml_ to configure _s3a_ with **MinIO**. Most important options here are
+Let's take for example a set of 12 compute nodes with an aggregate memory of _1.2TiB_, we need to do following settings for optimal results. Add the following optimal entries for _core-site.xml_ to configure _s3a_ with **Silo**. Most important options here are
 
 ```
 cat ${HADOOP_CONF_DIR}/core-site.xml | kv-pairify | grep "mapred"
@@ -56,7 +56,7 @@ mapreduce.task.io.sort.factor=999 # Threshold before writing to disk
 mapreduce.task.sort.spill.percent=0.9 # Minimum % before spilling to disk
 ```
 
-S3A is the connector to use S3 and other S3-compatible object stores such as MinIO. MapReduce workloads typically interact with object stores in the same way they do with HDFS. These workloads rely on HDFS atomic rename functionality to complete writing data to the datastore. Object storage operations are atomic by nature and they do not require/implement rename API. The default S3A committer emulates renames through copy and delete APIs. This interaction pattern causes significant loss of performance because of the write amplification. _Netflix_, for example, developed two new staging committers - the Directory staging committer and the Partitioned staging committer - to take full advantage of native object storage operations. These committers do not require rename operation. The two staging committers were evaluated, along with another new addition called the Magic committer for benchmarking.
+S3A is the connector to use S3 and other S3-compatible object stores such as Silo. MapReduce workloads typically interact with object stores in the same way they do with HDFS. These workloads rely on HDFS atomic rename functionality to complete writing data to the datastore. Object storage operations are atomic by nature and they do not require/implement rename API. The default S3A committer emulates renames through copy and delete APIs. This interaction pattern causes significant loss of performance because of the write amplification. _Netflix_, for example, developed two new staging committers - the Directory staging committer and the Partitioned staging committer - to take full advantage of native object storage operations. These committers do not require rename operation. The two staging committers were evaluated, along with another new addition called the Magic committer for benchmarking.
 
 It was found that the directory staging committer was the fastest among the three, S3A connector should be configured with the following parameters for optimal results:
 
@@ -64,7 +64,7 @@ It was found that the directory staging committer was the fastest among the thre
 cat ${HADOOP_CONF_DIR}/core-site.xml | kv-pairify | grep "s3a"
 
 fs.s3a.access.key=minio
-fs.s3a.secret.key=minio123
+fs.s3a.secret.key=silo123
 fs.s3a.path.style.access=true
 fs.s3a.block.size=512M
 fs.s3a.buffer.dir=${hadoop.tmp.dir}/s3a
@@ -80,7 +80,7 @@ fs.s3a.connection.timeout=200000
 fs.s3a.endpoint=http://minio:9000
 fs.s3a.impl=org.apache.hadoop.fs.s3a.S3AFileSystem
 
-fs.s3a.committer.threads=2048 # Number of threads writing to MinIO
+fs.s3a.committer.threads=2048 # Number of threads writing to Silo
 fs.s3a.connection.maximum=8192 # Maximum number of concurrent conns
 fs.s3a.fast.upload.active.blocks=2048 # Number of parallel uploads
 fs.s3a.fast.upload.buffer=disk # Use disk as the buffer for uploads
@@ -108,15 +108,15 @@ Navigate to **Services** -> **Spark2** -> **CONFIGS** as shown below
 
 ![spark-config](https://github.com/pgsty/minio/blob/master/docs/bigdata/images/image6.png?raw=true "spark config")
 
-Navigate to “**Custom spark-defaults**” to configure MinIO parameters for `_s3a_` connector
+Navigate to “**Custom spark-defaults**” to configure Silo parameters for `_s3a_` connector
 
 ![spark-config](https://github.com/pgsty/minio/blob/master/docs/bigdata/images/image9.png?raw=true "spark defaults")
 
-Add the following optimal entries for _spark-defaults.conf_ to configure Spark with **MinIO**.
+Add the following optimal entries for _spark-defaults.conf_ to configure Spark with **Silo**.
 
 ```
 spark.hadoop.fs.s3a.access.key minio
-spark.hadoop.fs.s3a.secret.key minio123
+spark.hadoop.fs.s3a.secret.key silo123
 spark.hadoop.fs.s3a.path.style.access true
 spark.hadoop.fs.s3a.block.size 512M
 spark.hadoop.fs.s3a.buffer.dir ${hadoop.tmp.dir}/s3a
@@ -126,7 +126,7 @@ spark.hadoop.fs.s3a.committer.staging.abort.pending.uploads true
 spark.hadoop.fs.s3a.committer.staging.conflict-mode append
 spark.hadoop.fs.s3a.committer.staging.tmp.path /tmp/staging
 spark.hadoop.fs.s3a.committer.staging.unique-filenames true
-spark.hadoop.fs.s3a.committer.threads 2048 # number of threads writing to MinIO
+spark.hadoop.fs.s3a.committer.threads 2048 # number of threads writing to Silo
 spark.hadoop.fs.s3a.connection.establish.timeout 5000
 spark.hadoop.fs.s3a.connection.maximum 8192 # maximum number of concurrent conns
 spark.hadoop.fs.s3a.connection.ssl.enabled false
@@ -154,11 +154,11 @@ Navigate to **Services** -> **Hive** -> **CONFIGS**-> **ADVANCED** as shown belo
 
 ![hive-config](https://github.com/pgsty/minio/blob/master/docs/bigdata/images/image10.png?raw=true "hive advanced config")
 
-Navigate to “**Custom hive-site**” to configure MinIO parameters for `_s3a_` connector
+Navigate to “**Custom hive-site**” to configure Silo parameters for `_s3a_` connector
 
 ![hive-config](https://github.com/pgsty/minio/blob/master/docs/bigdata/images/image11.png?raw=true "hive advanced config")
 
-Add the following optimal entries for `hive-site.xml` to configure Hive with **MinIO**.
+Add the following optimal entries for `hive-site.xml` to configure Hive with **Silo**.
 
 ```
 hive.blobstore.use.blobstore.as.scratchdir=true
@@ -188,7 +188,7 @@ Test the Spark installation by running the following compute intensive example,
 Follow these steps to run the Spark Pi example:
 
 - Login as user **‘spark’**.
-- When the job runs, the library can now use **MinIO** during intermediate processing.
+- When the job runs, the library can now use **Silo** during intermediate processing.
 - Navigate to a node with the Spark client and access the spark2-client directory:
 
 ```
@@ -224,7 +224,7 @@ WordCount is a simple program that counts how often a word occurs in a text file
 The following example submits WordCount code to the Scala shell. Select an input file for the Spark WordCount example. We can use any text file as input.
 
 - Login as user **‘spark’**.
-- When the job runs, the library can now use **MinIO** during intermediate processing.
+- When the job runs, the library can now use **Silo** during intermediate processing.
 - Navigate to a node with Spark client and access the spark2-client directory:
 
 ```
@@ -290,7 +290,7 @@ scala> counts.count()
 364
 ```
 
-To view the output from MinIO exit the Scala shell. View WordCount job status:
+To view the output from Silo exit the Scala shell. View WordCount job status:
 
 ```
 hadoop fs -ls s3a://testbucket/wordcount

docs/bucket/lifecycle/DESIGN.md

@@ -1,15 +1,15 @@
-# ILM Tiering Design [![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/)
+# ILM Tiering Design [![Docker Pulls](https://img.shields.io/docker/pulls/pgsty/silo.svg?maxAge=604800)](https://hub.docker.com/r/pgsty/silo/)
 
-Lifecycle transition functionality provided in [bucket lifecycle guide](https://github.com/pgsty/minio/blob/master/docs/bucket/lifecycle/README.md) allows tiering of content from MinIO object store to public clouds or other MinIO clusters.
+Lifecycle transition functionality provided in [bucket lifecycle guide](https://github.com/pgsty/minio/blob/master/docs/bucket/lifecycle/README.md) allows tiering of content from Silo object store to public clouds or other Silo clusters.
 
-Transition tiers can be added to MinIO using `mc admin tier add` command to associate a `gcs`, `s3` or `azure` bucket or prefix path on a bucket to the tier name.
+Transition tiers can be added to Silo using `mc admin tier add` command to associate a `gcs`, `s3` or `azure` bucket or prefix path on a bucket to the tier name.
 Lifecycle transition rules can be applied to buckets (both versioned and un-versioned) by specifying the tier name defined above as the transition storage class for the lifecycle rule.
 
 ## Implementation
 
-ILM tiering takes place when a object placed in the bucket meets lifecycle transition rules and becomes eligible for tiering. MinIO scanner (which runs at one minute intervals, each time scanning one sixteenth of the namespace), picks up the object for tiering. The data is moved to the remote tier in entirety, leaving only the object metadata on MinIO.
+ILM tiering takes place when a object placed in the bucket meets lifecycle transition rules and becomes eligible for tiering. Silo scanner (which runs at one minute intervals, each time scanning one sixteenth of the namespace), picks up the object for tiering. The data is moved to the remote tier in entirety, leaving only the object metadata on Silo.
 
-The data on the backend is stored under the `bucket/prefix` specified in the tier configuration with a custom name derived from a randomly generated uuid - e.g. `0b/c4/0bc4fab7-2daf-4d2f-8e39-5c6c6fb7e2d3`. The first two prefixes are characters 1-2,3-4 from the uuid. This format allows tiering to any cloud irrespective of whether the cloud in question supports versioning. The reference to the transitioned object name and transitioned tier is stored as part of the internal metadata for the object (or its version) on MinIO.
+The data on the backend is stored under the `bucket/prefix` specified in the tier configuration with a custom name derived from a randomly generated uuid - e.g. `0b/c4/0bc4fab7-2daf-4d2f-8e39-5c6c6fb7e2d3`. The first two prefixes are characters 1-2,3-4 from the uuid. This format allows tiering to any cloud irrespective of whether the cloud in question supports versioning. The reference to the transitioned object name and transitioned tier is stored as part of the internal metadata for the object (or its version) on Silo.
 
 Extra metadata maintained internally in `xl.meta` for a transitioned object
 
@@ -22,7 +22,7 @@ Extra metadata maintained internally in `xl.meta` for a transitioned object
         },
 ```
 
-When a transitioned object is restored temporarily to local MinIO instance via PostRestoreObject API, the object data is copied back from the remote tier, and additional metadata for the restored object is maintained as referenced below. Once the restore period expires, the local copy of the object is removed by the scanner during its periodic runs.
+When a transitioned object is restored temporarily to local Silo instance via PostRestoreObject API, the object data is copied back from the remote tier, and additional metadata for the restored object is maintained as referenced below. Once the restore period expires, the local copy of the object is removed by the scanner during its periodic runs.
 
 ```
 ...
@@ -35,11 +35,11 @@ When a transitioned object is restored temporarily to local MinIO instance via P
 
 ### Encrypted/Object locked objects
 
-For objects under SSE-S3 or SSE-C encryption, the encrypted content from MinIO cluster is copied as is to the remote tier without any decryption. The content is decrypted as it is streamed from remote tier on `GET/HEAD`. Objects under retention are protected because the metadata present on MinIO server ensures that the object (version) is not deleted until retention period is over. Administrators need to ensure that the remote tier bucket is under proper access control.
+For objects under SSE-S3 or SSE-C encryption, the encrypted content from Silo cluster is copied as is to the remote tier without any decryption. The content is decrypted as it is streamed from remote tier on `GET/HEAD`. Objects under retention are protected because the metadata present on Silo server ensures that the object (version) is not deleted until retention period is over. Administrators need to ensure that the remote tier bucket is under proper access control.
 
 ### Transition Status
 
-MinIO specific extension header `X-Minio-Transition` is displayed on `HEAD/GET` to predict expected transition date on the object. Once object is transitioned to the remote tier,`x-amz-storage-class` shows the tier name to which object transitioned. Additional headers such as "X-Amz-Restore-Expiry-Days", "x-amz-restore", and "X-Amz-Restore-Request-Date" are displayed when a object is under restore/has been restored to local MinIO cluster.
+Silo specific extension header `X-Minio-Transition` is displayed on `HEAD/GET` to predict expected transition date on the object. Once object is transitioned to the remote tier,`x-amz-storage-class` shows the tier name to which object transitioned. Additional headers such as "X-Amz-Restore-Expiry-Days", "x-amz-restore", and "X-Amz-Restore-Request-Date" are displayed when a object is under restore/has been restored to local Silo cluster.
 
 ### Expiry or removal events
 
@@ -47,9 +47,9 @@ An object that is in transition tier will be deleted once the object hits expiry
 
 ### Additional notes
 
-Tiering and lifecycle transition are applicable only to erasure/distributed MinIO.
+Tiering and lifecycle transition are applicable only to erasure/distributed Silo.
 
 ## Explore Further
 
-- [MinIO | Golang Client API Reference](https://pkg.go.dev/github.com/minio/minio-go/v7#Client.SetBucketLifecycle)
+- [MinIO Go client API reference (S3-compatible SDK)](https://pkg.go.dev/github.com/minio/minio-go/v7#Client.SetBucketLifecycle)
 - [Object Lifecycle Management](https://docs.aws.amazon.com/AmazonS3/latest/dev/object-lifecycle-mgmt.html)

docs/bucket/lifecycle/README.md

@@ -1,10 +1,10 @@
-# Bucket Lifecycle Configuration Quickstart 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/)
+# Bucket Lifecycle Configuration Quickstart Guide [![Docker Pulls](https://img.shields.io/docker/pulls/pgsty/silo.svg?maxAge=604800)](https://hub.docker.com/r/pgsty/silo/)
 
 Enable object lifecycle configuration on buckets to setup automatic deletion of objects after a specified number of days or a specified date.
 
 ## 1. Prerequisites
 
-- Install MinIO - [MinIO Quickstart Guide](https://silo.pgsty.com/operations/deployments/baremetal-deploy-minio-on-redhat-linux/).
+- Install Silo - [Silo Quickstart Guide](https://silo.pgsty.com/operations/deployments/baremetal-deploy-minio-on-redhat-linux/).
 - Install `mc` - [mc Quickstart Guide](https://silo.pgsty.com/reference/minio-mc/#quickstart)
 
 ## 2. Enable bucket lifecycle configuration
@@ -84,9 +84,9 @@ e.g., To scan objects stored under `user-uploads/` prefix and remove versions ol
 }
 ```
 
-This JSON rule is equivalent to the following MinIO Client command:
+This JSON rule is equivalent to the following compatible `mc` command:
 ```
-mc ilm rule add --noncurrent-expire-days 365 --prefix "user-uploads/" myminio/mydata
+mc ilm rule add --noncurrent-expire-days 365 --prefix "user-uploads/" mysilo/mydata
 ```
 
 ### 3.2 Automatic removal of noncurrent versions keeping only most recent ones after noncurrent days
@@ -113,14 +113,14 @@ e.g, To remove noncurrent versions of all objects keeping the most recent 5 nonc
 }
 ```
 
-This JSON rule is equivalent to the following MinIO Client command:
+This JSON rule is equivalent to the following compatible `mc` command:
 ```
-mc ilm rule add --noncurrent-expire-days 30 --noncurrent-expire-newer 5 --prefix "user-uploads/" myminio/mydata
+mc ilm rule add --noncurrent-expire-days 30 --noncurrent-expire-newer 5 --prefix "user-uploads/" mysilo/mydata
 ```
 
-#### 3.2.a Automatic removal of noncurrent versions keeping only most recent ones immediately (MinIO only extension)
+#### 3.2.a Automatic removal of noncurrent versions keeping only most recent ones immediately (Silo only extension)
 
-This is available only on MinIO as an extension to the NewerNoncurrentVersions feature. The following rule makes it possible to remove older noncurrent versions
+This is available only on Silo as an extension to the NewerNoncurrentVersions feature. The following rule makes it possible to remove older noncurrent versions
 of objects under the prefix `user-uploads/` as soon as there are more than `N` noncurrent versions of an object.
 
 ```
@@ -141,9 +141,9 @@ of objects under the prefix `user-uploads/` as soon as there are more than `N` n
 ```
 Note: This rule has an implicit zero NoncurrentDays, which makes the expiry of those 'extra' noncurrent versions immediate.
 
-#### 3.2.b Automatic removal of all versions (MinIO only extension)
+#### 3.2.b Automatic removal of all versions (Silo only extension)
 
-This is available only on MinIO as an extension to the Expiration feature. The following rule makes it possible to remove all versions of an object under 
+This is available only on Silo as an extension to the Expiration feature. The following rule makes it possible to remove all versions of an object under
 the prefix `user-uploads/` as soon as the latest object satisfies the expiration criteria. 
 
 > NOTE: If the latest object is a delete marker then filtering based on `Filter.Tags` is ignored and 
@@ -188,9 +188,9 @@ When an object has only one version as a delete marker, the latter can be automa
 
 ## 4. Enable ILM transition feature
 
-In Erasure mode, MinIO supports tiering to public cloud providers such as GCS, AWS and Azure as well as to other MinIO clusters via the ILM transition feature. This will allow transitioning of older objects to a different cluster or the public cloud by setting up transition rules in the bucket lifecycle configuration. This feature enables applications to optimize storage costs by moving less frequently accessed data to a cheaper storage without compromising accessibility of data.
+In Erasure mode, Silo supports tiering to public cloud providers such as GCS, AWS and Azure as well as to other Silo clusters via the ILM transition feature. This will allow transitioning of older objects to a different cluster or the public cloud by setting up transition rules in the bucket lifecycle configuration. This feature enables applications to optimize storage costs by moving less frequently accessed data to a cheaper storage without compromising accessibility of data.
 
-To transition objects in a bucket to a destination bucket on a different cluster, applications need to specify a transition tier defined on MinIO instead of storage class while setting up the ILM lifecycle rule.
+To transition objects in a bucket to a destination bucket on a different cluster, applications need to specify a transition tier defined on Silo instead of storage class while setting up the ILM lifecycle rule.
 
 > To create a transition tier for transitioning objects to a prefix `testprefix` in `azurebucket` on Azure blob using `mc`:
 
@@ -203,10 +203,10 @@ To transition objects in a bucket to a destination bucket on a different cluster
 Using above tier, set up a lifecycle rule with transition:
 
 ```
- mc ilm add --expiry-days 365 --transition-days 45 --storage-class "AZURETIER" myminio/srcbucket
+ mc ilm add --expiry-days 365 --transition-days 45 --storage-class "AZURETIER" mysilo/srcbucket
 ```
 
-Note: In the case of S3, it is possible to create a tier from MinIO running in EC2 to S3 using AWS role attached to EC2 as credentials instead of accesskey/secretkey:
+Note: In the case of S3, it is possible to create a tier from Silo running in EC2 to S3 using AWS role attached to EC2 as credentials instead of accesskey/secretkey:
 
 ```
 mc admin tier add s3 source S3TIER --bucket s3bucket --prefix testprefix/ --use-aws-role
@@ -224,9 +224,9 @@ aws s3api restore-object --bucket srcbucket \
 
 `s3:ObjectTransition:Complete` and `s3:ObjectTransition:Failed` events can be used to monitor transition events between the source cluster and transition tier. To watch lifecycle events, you can enable bucket notification on the source bucket with `mc event add`  and specify `--event ilm` flag.
 
-Note that transition event notification is a MinIO extension.
+Note that transition event notification is a Silo extension.
 
 ## Explore Further
 
-- [MinIO | Golang Client API Reference](https://pkg.go.dev/github.com/minio/minio-go/v7)
+- [MinIO Go client API reference (S3-compatible SDK)](https://pkg.go.dev/github.com/minio/minio-go/v7)
 - [Object Lifecycle Management](https://docs.aws.amazon.com/AmazonS3/latest/dev/object-lifecycle-mgmt.html)

docs/bucket/notifications/README.md

@@ -1,8 +1,8 @@
-# MinIO Bucket Notification Guide [![Slack](https://slack.min.io/slack?type=svg)](https://slack.min.io)
+# Silo Bucket Notification Guide
 
 Events occurring on objects in a bucket can be monitored using bucket event notifications.
 
-Various event types supported by MinIO server are
+Various event types supported by Silo server are
 
 | Supported Object Event Types     |                                            |                                        |
 | :----------------------          | ------------------------------------------ | -------------------------------------  |
@@ -30,7 +30,11 @@ Various event types supported by MinIO server are
 | `s3:BucketCreated`                                                           |
 | `s3:BucketRemoved`                                                           |
 
-Use client tools like `mc` to set and listen for event notifications using the [`event` sub-command](https://silo.pgsty.com/reference/minio-mc/mc-event-add/). MinIO SDK's [`BucketNotification` APIs](https://pkg.go.dev/github.com/minio/minio-go/v7#Client.SetBucketNotification) can also be used. The notification message MinIO sends to publish an event is a JSON message with the following [structure](https://docs.aws.amazon.com/AmazonS3/latest/dev/notification-content-structure.html).
+Use compatible client tools like `mc` to set and listen for event notifications
+with the [`event` sub-command](https://silo.pgsty.com/reference/minio-mc/mc-event-add/).
+The technical [`minio-go` BucketNotification API](https://pkg.go.dev/github.com/minio/minio-go/v7#Client.SetBucketNotification)
+can also be used. Silo publishes the standard S3-compatible JSON event
+[structure](https://docs.aws.amazon.com/AmazonS3/latest/dev/notification-content-structure.html).
 
 Bucket events can be published to the following targets:
 
@@ -43,11 +47,11 @@ Bucket events can be published to the following targets:
 
 ## Prerequisites
 
-- Install and configure MinIO Server from [here](https://silo.pgsty.com/operations/deployments/baremetal-deploy-minio-on-redhat-linux/#procedure).
+- Install and configure Silo Server from [here](https://silo.pgsty.com/operations/deployments/baremetal-deploy-minio-on-redhat-linux/#procedure).
-- Install and configure MinIO Client from [here](https://silo.pgsty.com/reference/minio-mc/#quickstart).
+- Install and configure the compatible client from [here](https://silo.pgsty.com/reference/minio-mc/#quickstart).
 
 ```
-$ mc admin config get myminio | grep notify
+$ mc admin config get mysilo | grep notify
 notify_webhook        publish bucket notifications to webhook endpoints
 notify_amqp           publish bucket notifications to AMQP endpoints
 notify_kafka          publish bucket notifications to Kafka endpoints
@@ -66,11 +70,11 @@ notify_redis          publish bucket notifications to Redis datastores
 > - '\*' at the end of the values, means its the default value for the arg.
 > - When configured using environment variables, the `:name` can be specified using this format `MINIO_NOTIFY_WEBHOOK_ENABLE_<name>`.
 
-## Publish MinIO events via AMQP
+## Publish Silo events via AMQP
 
 Install RabbitMQ from [here](https://www.rabbitmq.com/).
 
-### Step 1: Add AMQP endpoint to MinIO
+### Step 1: Add AMQP endpoint to Silo
 
 The AMQP configuration is located under the sub-system `notify_amqp` top-level key. Create a configuration key-value pair here for your AMQP instance. The key is a name for your AMQP endpoint, and the value is a collection of key-value parameters described in the table below.
 
@@ -117,37 +121,37 @@ MINIO_NOTIFY_AMQP_QUEUE_LIMIT    (number)    maximum limit for undelivered messa
 MINIO_NOTIFY_AMQP_COMMENT        (sentence)  optionally add a comment to this setting
 ```
 
-MinIO supports persistent event store. The persistent store will backup events when the AMQP broker goes offline and replays it when the broker comes back online. The event store can be configured by setting the directory path in `queue_dir` field and the maximum limit of events in the queue_dir in `queue_limit` field. For eg, the `queue_dir` can be `/home/events` and `queue_limit` can be `1000`. By default, the `queue_limit` is set to 100000.
+Silo supports persistent event store. The persistent store will backup events when the AMQP broker goes offline and replays it when the broker comes back online. The event store can be configured by setting the directory path in `queue_dir` field and the maximum limit of events in the queue_dir in `queue_limit` field. For eg, the `queue_dir` can be `/home/events` and `queue_limit` can be `1000`. By default, the `queue_limit` is set to 100000.
 
 To update the configuration, use `mc admin config get notify_amqp` command to get the current configuration for `notify_amqp`.
 
 ```sh
-$ mc admin config get myminio/ notify_amqp
+$ mc admin config get mysilo/ notify_amqp
 notify_amqp:1 delivery_mode="0" exchange_type="" no_wait="off" queue_dir="" queue_limit="0"  url="" auto_deleted="off" durable="off" exchange="" internal="off" mandatory="off" routing_key=""
 ```
 
-Use `mc admin config set` command to update the configuration for the deployment.Restart the MinIO server to put the changes into effect. The server will print a line like `SQS ARNs: arn:minio:sqs::1:amqp` at start-up if there were no errors.
+Use `mc admin config set` command to update the configuration for the deployment.Restart the Silo server to put the changes into effect. The server will print a line like `SQS ARNs: arn:minio:sqs::1:amqp` at start-up if there were no errors.
 
 An example configuration for RabbitMQ is shown below:
 
 ```sh
-mc admin config set myminio/ notify_amqp:1 exchange="bucketevents" exchange_type="fanout" mandatory="off" no_wait="off"  url="amqp://myuser:mypassword@localhost:5672" auto_deleted="off" delivery_mode="0" durable="off" internal="off" routing_key="bucketlogs"
+mc admin config set mysilo/ notify_amqp:1 exchange="bucketevents" exchange_type="fanout" mandatory="off" no_wait="off"  url="amqp://myuser:mypassword@localhost:5672" auto_deleted="off" delivery_mode="0" durable="off" internal="off" routing_key="bucketlogs"
 ```
 
-MinIO supports all the exchanges available in [RabbitMQ](https://www.rabbitmq.com/). For this setup, we are using `fanout` exchange.
+Silo supports all the exchanges available in [RabbitMQ](https://www.rabbitmq.com/). For this setup, we are using `fanout` exchange.
 
-MinIO also sends with the notifications two headers: `minio-bucket` and `minio-event`. An exchange using the type "headers" can use this information to route the notifications to proper queues.
+Silo also sends with the notifications two headers: `minio-bucket` and `minio-event`. An exchange using the type "headers" can use this information to route the notifications to proper queues.
 
 Note that, you can add as many AMQP server endpoint configurations as needed by providing an identifier (like "1" in the example above) for the AMQP instance and an object of per-server configuration parameters.
 
-### Step 2: Enable RabbitMQ bucket notification using MinIO client
+### Step 2: Enable RabbitMQ bucket notification using Silo client
 
-We will enable bucket event notification to trigger whenever a JPEG image is uploaded or deleted `images` bucket on `myminio` server. Here ARN value is `arn:minio:sqs::1:amqp`. To understand more about ARN please follow [AWS ARN](http://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html) documentation.
+We will enable bucket event notification to trigger whenever a JPEG image is uploaded or deleted `images` bucket on `mysilo` server. Here ARN value is `arn:minio:sqs::1:amqp`. To understand more about ARN please follow [AWS ARN](http://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html) documentation.
 
 ```
-mc mb myminio/images
+mc mb mysilo/images
-mc event add myminio/images arn:minio:sqs::1:amqp --suffix .jpg
+mc event add mysilo/images arn:minio:sqs::1:amqp --suffix .jpg
-mc event list myminio/images
+mc event list mysilo/images
 arn:minio:sqs::1:amqp s3:ObjectCreated:*,s3:ObjectRemoved:* Filter: suffix=”.jpg”
 ```
 
@@ -193,7 +197,7 @@ python rabbit.py
 Open another terminal and upload a JPEG image into `images` bucket.
 
 ```
-mc cp myphoto.jpg myminio/images
+mc cp myphoto.jpg mysilo/images
 ```
 
 You should receive the following event notification via RabbitMQ once the upload completes.
@@ -203,11 +207,11 @@ python rabbit.py
 '{"Records":[{"eventVersion":"2.0","eventSource":"aws:s3","awsRegion":"","eventTime":"2016–09–08T22:34:38.226Z","eventName":"s3:ObjectCreated:Put","userIdentity":{"principalId":"minio"},"requestParameters":{"sourceIPAddress":"10.1.10.150:44576"},"responseElements":{},"s3":{"s3SchemaVersion":"1.0","configurationId":"Config","bucket":{"name":"images","ownerIdentity":{"principalId":"minio"},"arn":"arn:aws:s3:::images"},"object":{"key":"myphoto.jpg","size":200436,"sequencer":"147279EAF9F40933"}}}],"level":"info","msg":"","time":"2016–09–08T15:34:38–07:00"}'
 ```
 
-## Publish MinIO events MQTT
+## Publish Silo events MQTT
 
 Install an MQTT Broker from [here](https://mosquitto.org/).
 
-### Step 1: Add MQTT endpoint to MinIO
+### Step 1: Add MQTT endpoint to Silo
 
 The MQTT configuration is located as `notify_mqtt` key. Create a configuration key-value pair here for your MQTT instance. The key is a name for your MQTT endpoint, and the value is a collection of key-value parameters described in the table below.
 
@@ -248,33 +252,33 @@ MINIO_NOTIFY_MQTT_QUEUE_LIMIT          (number)    maximum limit for undelivered
 MINIO_NOTIFY_MQTT_COMMENT              (sentence)  optionally add a comment to this setting
 ```
 
-MinIO supports persistent event store. The persistent store will backup events when the MQTT broker goes offline and replays it when the broker comes back online. The event store can be configured by setting the directory path in `queue_dir` field and the maximum limit of events in the queue_dir in `queue_limit` field. For eg, the `queue_dir` can be `/home/events` and `queue_limit` can be `1000`. By default, the `queue_limit` is set to 100000.
+Silo supports persistent event store. The persistent store will backup events when the MQTT broker goes offline and replays it when the broker comes back online. The event store can be configured by setting the directory path in `queue_dir` field and the maximum limit of events in the queue_dir in `queue_limit` field. For eg, the `queue_dir` can be `/home/events` and `queue_limit` can be `1000`. By default, the `queue_limit` is set to 100000.
 
 To update the configuration, use `mc admin config get` command to get the current configuration.
 
 ```sh
-$ mc admin config get myminio/ notify_mqtt
+$ mc admin config get mysilo/ notify_mqtt
 notify_mqtt:1 broker="" password="" queue_dir="" queue_limit="0" reconnect_interval="0s"  keep_alive_interval="0s" qos="0" topic="" username=""
 ```
 
-Use `mc admin config set` command to update the configuration for the deployment. Restart the MinIO server to put the changes into effect. The server will print a line like `SQS ARNs: arn:minio:sqs::1:mqtt` at start-up if there were no errors.
+Use `mc admin config set` command to update the configuration for the deployment. Restart the Silo server to put the changes into effect. The server will print a line like `SQS ARNs: arn:minio:sqs::1:mqtt` at start-up if there were no errors.
 
 ```sh
-mc admin config set myminio notify_mqtt:1 broker="tcp://localhost:1883" password="" queue_dir="" queue_limit="0" reconnect_interval="0s"  keep_alive_interval="0s" qos="1" topic="minio" username=""
+mc admin config set mysilo notify_mqtt:1 broker="tcp://localhost:1883" password="" queue_dir="" queue_limit="0" reconnect_interval="0s"  keep_alive_interval="0s" qos="1" topic="minio" username=""
 ```
 
-MinIO supports any MQTT server that supports MQTT 3.1 or 3.1.1 and can connect to them over TCP, TLS, or a Websocket connection using `tcp://`, `tls://`, or `ws://` respectively as the scheme for the broker url. See the [Go Client](http://www.eclipse.org/paho/clients/golang/) documentation for more information.
+Silo supports any MQTT server that supports MQTT 3.1 or 3.1.1 and can connect to them over TCP, TLS, or a Websocket connection using `tcp://`, `tls://`, or `ws://` respectively as the scheme for the broker url. See the [Go Client](http://www.eclipse.org/paho/clients/golang/) documentation for more information.
 
 Note that, you can add as many MQTT server endpoint configurations as needed by providing an identifier (like "1" in the example above) for the MQTT instance and an object of per-server configuration parameters.
 
-### Step 2: Enable MQTT bucket notification using MinIO client
+### Step 2: Enable MQTT bucket notification using Silo client
 
-We will enable bucket event notification to trigger whenever a JPEG image is uploaded or deleted `images` bucket on `myminio` server. Here ARN value is `arn:minio:sqs::1:mqtt`.
+We will enable bucket event notification to trigger whenever a JPEG image is uploaded or deleted `images` bucket on `mysilo` server. Here ARN value is `arn:minio:sqs::1:mqtt`.
 
 ```
-mc mb myminio/images
+mc mb mysilo/images
-mc event add  myminio/images arn:minio:sqs::1:mqtt --suffix .jpg
+mc event add  mysilo/images arn:minio:sqs::1:mqtt --suffix .jpg
-mc event list myminio/images
+mc event list mysilo/images
 arn:minio:sqs::1:amqp s3:ObjectCreated:*,s3:ObjectRemoved:* Filter: suffix=”.jpg”
 ```
 
@@ -316,7 +320,7 @@ python mqtt.py
 Open another terminal and upload a JPEG image into `images` bucket.
 
 ```
-mc cp myphoto.jpg myminio/images
+mc cp myphoto.jpg mysilo/images
 ```
 
 You should receive the following event notification via MQTT once the upload completes.
@@ -326,23 +330,23 @@ python mqtt.py
 {“Records”:[{“eventVersion”:”2.0",”eventSource”:”aws:s3",”awsRegion”:”",”eventTime”:”2016–09–08T22:34:38.226Z”,”eventName”:”s3:ObjectCreated:Put”,”userIdentity”:{“principalId”:”minio”},”requestParameters”:{“sourceIPAddress”:”10.1.10.150:44576"},”responseElements”:{},”s3":{“s3SchemaVersion”:”1.0",”configurationId”:”Config”,”bucket”:{“name”:”images”,”ownerIdentity”:{“principalId”:”minio”},”arn”:”arn:aws:s3:::images”},”object”:{“key”:”myphoto.jpg”,”size”:200436,”sequencer”:”147279EAF9F40933"}}}],”level”:”info”,”msg”:””,”time”:”2016–09–08T15:34:38–07:00"}
 ```
 
-## Publish MinIO events via Elasticsearch
+## Publish Silo events via Elasticsearch
 
 Install [Elasticsearch](https://www.elastic.co/downloads/elasticsearch) server.
 
 This notification target supports two formats: _namespace_ and _access_.
 
-When the _namespace_ format is used, MinIO synchronizes objects in the bucket with documents in the index. For each event in the MinIO, the server creates a document with the bucket and object name from the event as the document ID. Other details of the event are stored in the body of the document. Thus if an existing object is over-written in MinIO, the corresponding document in the Elasticsearch index is updated. If an object is deleted, the corresponding document is deleted from the index.
+When the _namespace_ format is used, Silo synchronizes objects in the bucket with documents in the index. For each event in the Silo, the server creates a document with the bucket and object name from the event as the document ID. Other details of the event are stored in the body of the document. Thus if an existing object is over-written in Silo, the corresponding document in the Elasticsearch index is updated. If an object is deleted, the corresponding document is deleted from the index.
 
-When the _access_ format is used, MinIO appends events as documents in an Elasticsearch index. For each event, a document with the event details, with the timestamp of document set to the event's timestamp is appended to an index. The ID of the documented is randomly generated by Elasticsearch. No documents are deleted or modified in this format.
+When the _access_ format is used, Silo appends events as documents in an Elasticsearch index. For each event, a document with the event details, with the timestamp of document set to the event's timestamp is appended to an index. The ID of the documented is randomly generated by Elasticsearch. No documents are deleted or modified in this format.
 
 The steps below show how to use this notification target in `namespace` format. The other format is very similar and is omitted for brevity.
 
 ### Step 1: Ensure Elasticsearch minimum requirements are met
 
-MinIO requires a 5.x series version of Elasticsearch. This is the latest major release series. Elasticsearch provides version upgrade migration guidelines [here](https://www.elastic.co/guide/en/elasticsearch/reference/current/setup-upgrade.html).
+Silo requires a 5.x series version of Elasticsearch. This is the latest major release series. Elasticsearch provides version upgrade migration guidelines [here](https://www.elastic.co/guide/en/elasticsearch/reference/current/setup-upgrade.html).
 
-### Step 2: Add Elasticsearch endpoint to MinIO
+### Step 2: Add Elasticsearch endpoint to Silo
 
 The Elasticsearch configuration is located in the `notify_elasticsearch` key. Create a configuration key-value pair here for your Elasticsearch instance. The key is a name for your Elasticsearch endpoint, and the value is a collection of key-value parameters described in the table below.
 
@@ -381,37 +385,37 @@ MINIO_NOTIFY_ELASTICSEARCH_COMMENT      (sentence)           optionally add a co
 
 For example: `http://localhost:9200` or with authentication info `http://elastic:MagicWord@127.0.0.1:9200`.
 
-MinIO supports persistent event store. The persistent store will backup events when the Elasticsearch broker goes offline and replays it when the broker comes back online. The event store can be configured by setting the directory path in `queue_dir` field and the maximum limit of events in the queue_dir in `queue_limit` field. For eg, the `queue_dir` can be `/home/events` and `queue_limit` can be `1000`. By default, the `queue_limit` is set to 100000.
+Silo supports persistent event store. The persistent store will backup events when the Elasticsearch broker goes offline and replays it when the broker comes back online. The event store can be configured by setting the directory path in `queue_dir` field and the maximum limit of events in the queue_dir in `queue_limit` field. For eg, the `queue_dir` can be `/home/events` and `queue_limit` can be `1000`. By default, the `queue_limit` is set to 100000.
 
-If Elasticsearch has authentication enabled, the credentials can be supplied to MinIO via the `url` parameter formatted as `PROTO://USERNAME:PASSWORD@ELASTICSEARCH_HOST:PORT`.
+If Elasticsearch has authentication enabled, the credentials can be supplied to Silo via the `url` parameter formatted as `PROTO://USERNAME:PASSWORD@ELASTICSEARCH_HOST:PORT`.
 
 To update the configuration, use `mc admin config get` command to get the current configuration.
 
 ```sh
-$ mc admin config get myminio/ notify_elasticsearch
+$ mc admin config get mysilo/ notify_elasticsearch
 notify_elasticsearch:1 queue_limit="0"  url="" format="namespace" index="" queue_dir=""
 ```
 
-Use `mc admin config set` command to update the configuration for the deployment. Restart the MinIO server to put the changes into effect. The server will print a line like `SQS ARNs: arn:minio:sqs::1:elasticsearch` at start-up if there were no errors.
+Use `mc admin config set` command to update the configuration for the deployment. Restart the Silo server to put the changes into effect. The server will print a line like `SQS ARNs: arn:minio:sqs::1:elasticsearch` at start-up if there were no errors.
 
 ```sh
-mc admin config set myminio notify_elasticsearch:1 queue_limit="0"  url="http://127.0.0.1:9200" format="namespace" index="minio_events" queue_dir="" username="" password=""
+mc admin config set mysilo notify_elasticsearch:1 queue_limit="0"  url="http://127.0.0.1:9200" format="namespace" index="minio_events" queue_dir="" username="" password=""
 ```
 
 Note that, you can add as many Elasticsearch server endpoint configurations as needed by providing an identifier (like "1" in the example above) for the Elasticsearch instance and an object of per-server configuration parameters.
 
-### Step 3: Enable Elastichsearch bucket notification using MinIO client
+### Step 3: Enable Elastichsearch bucket notification using Silo client
 
 We will now enable bucket event notifications on a bucket named `images`. Whenever a JPEG image is created/overwritten, a new document is added or an existing document is updated in the Elasticsearch index configured above. When an existing object is deleted, the corresponding document is deleted from the index. Thus, the rows in the Elasticsearch index, reflect the `.jpg` objects in the `images` bucket.
 
-To configure this bucket notification, we need the ARN printed by MinIO in the previous step. Additional information about ARN is available [here](http://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html).
+To configure this bucket notification, we need the ARN printed by Silo in the previous step. Additional information about ARN is available [here](http://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html).
 
-With the `mc` tool, the configuration is very simple to add. Let us say that the MinIO server is aliased as `myminio` in our mc configuration. Execute the following:
+With the `mc` tool, the configuration is very simple to add. Let us say that the Silo server is aliased as `mysilo` in our mc configuration. Execute the following:
 
 ```
-mc mb myminio/images
+mc mb mysilo/images
-mc event add  myminio/images arn:minio:sqs::1:elasticsearch --suffix .jpg
+mc event add  mysilo/images arn:minio:sqs::1:elasticsearch --suffix .jpg
-mc event list myminio/images
+mc event list mysilo/images
 arn:minio:sqs::1:elasticsearch s3:ObjectCreated:*,s3:ObjectRemoved:* Filter: suffix=”.jpg”
 ```
 
@@ -420,7 +424,7 @@ arn:minio:sqs::1:elasticsearch s3:ObjectCreated:*,s3:ObjectRemoved:* Filter: suf
 Upload a JPEG image into `images` bucket.
 
 ```
-mc cp myphoto.jpg myminio/images
+mc cp myphoto.jpg mysilo/images
 ```
 
 Use curl to view contents of `minio_events` index.
@@ -482,7 +486,7 @@ $ curl  "http://localhost:9200/minio_events/_search?pretty=true"
               "source" : {
                 "host" : "127.0.0.1",
                 "port" : "38062",
-                "userAgent" : "MinIO (linux; amd64) minio-go/2.0.3 mc/2017-02-15T17:57:25Z"
+                "userAgent" : "Silo (linux; amd64) minio-go/2.0.3 mc/2017-02-15T17:57:25Z"
               }
             }
           ]
@@ -497,21 +501,21 @@ This output shows that a document has been created for the event in Elasticsearc
 
 Here we see that the document ID is the bucket and object name. In case `access` format was used, the document ID would be automatically generated by Elasticsearch.
 
-## Publish MinIO events via Redis
+## Publish Silo events via Redis
 
 Install [Redis](http://redis.io/download) server. For illustrative purposes, we have set the database password as "yoursecret".
 
 This notification target supports two formats: _namespace_ and _access_.
 
-When the _namespace_ format is used, MinIO synchronizes objects in the bucket with entries in a hash. For each entry, the key is formatted as "bucketName/objectName" for an object that exists in the bucket, and the value is the JSON-encoded event data about the operation that created/replaced the object in MinIO. When objects are updated or deleted, the corresponding entry in the hash is also updated or deleted.
+When the _namespace_ format is used, Silo synchronizes objects in the bucket with entries in a hash. For each entry, the key is formatted as "bucketName/objectName" for an object that exists in the bucket, and the value is the JSON-encoded event data about the operation that created/replaced the object in Silo. When objects are updated or deleted, the corresponding entry in the hash is also updated or deleted.
 
-When the _access_ format is used, MinIO appends events to a list using [RPUSH](https://redis.io/commands/rpush). Each item in the list is a JSON encoded list with two items, where the first item is a timestamp string, and the second item is a JSON object containing event data about the operation that happened in the bucket. No entries appended to the list are updated or deleted by MinIO in this format.
+When the _access_ format is used, Silo appends events to a list using [RPUSH](https://redis.io/commands/rpush). Each item in the list is a JSON encoded list with two items, where the first item is a timestamp string, and the second item is a JSON object containing event data about the operation that happened in the bucket. No entries appended to the list are updated or deleted by Silo in this format.
 
 The steps below show how to use this notification target in `namespace` and `access` format.
 
-### Step 1: Add Redis endpoint to MinIO
+### Step 1: Add Redis endpoint to Silo
 
-The MinIO server configuration file is stored on the backend in json format.The Redis configuration is located in the `redis` key under the `notify` top-level key. Create a configuration key-value pair here for your Redis instance. The key is a name for your Redis endpoint, and the value is a collection of key-value parameters described in the table below.
+The Silo server configuration file is stored on the backend in json format.The Redis configuration is located in the `redis` key under the `notify` top-level key. Create a configuration key-value pair here for your Redis instance. The key is a name for your Redis endpoint, and the value is a collection of key-value parameters described in the table below.
 
 ```
 KEY:
@@ -543,35 +547,35 @@ MINIO_NOTIFY_REDIS_QUEUE_LIMIT  (number)             maximum limit for undeliver
 MINIO_NOTIFY_REDIS_COMMENT      (sentence)           optionally add a comment to this setting
 ```
 
-MinIO supports persistent event store. The persistent store will backup events when the Redis broker goes offline and replays it when the broker comes back online. The event store can be configured by setting the directory path in `queue_dir` field and the maximum limit of events in the queue_dir in `queue_limit` field. For eg, the `queue_dir` can be `/home/events` and `queue_limit` can be `1000`. By default, the `queue_limit` is set to 100000.
+Silo supports persistent event store. The persistent store will backup events when the Redis broker goes offline and replays it when the broker comes back online. The event store can be configured by setting the directory path in `queue_dir` field and the maximum limit of events in the queue_dir in `queue_limit` field. For eg, the `queue_dir` can be `/home/events` and `queue_limit` can be `1000`. By default, the `queue_limit` is set to 100000.
 
 To update the configuration, use `mc admin config get` command to get the current configuration.
 
 ```sh
-$ mc admin config get myminio/ notify_redis
+$ mc admin config get mysilo/ notify_redis
 notify_redis:1 address="" format="namespace" key="" password="" queue_dir="" queue_limit="0"
 ```
 
-Use `mc admin config set` command to update the configuration for the deployment.Restart the MinIO server to put the changes into effect. The server will print a line like `SQS ARNs: arn:minio:sqs::1:redis` at start-up if there were no errors.
+Use `mc admin config set` command to update the configuration for the deployment.Restart the Silo server to put the changes into effect. The server will print a line like `SQS ARNs: arn:minio:sqs::1:redis` at start-up if there were no errors.
 
 ```sh
-mc admin config set myminio/ notify_redis:1 address="127.0.0.1:6379" format="namespace" key="bucketevents" password="yoursecret" queue_dir="" queue_limit="0"
+mc admin config set mysilo/ notify_redis:1 address="127.0.0.1:6379" format="namespace" key="bucketevents" password="yoursecret" queue_dir="" queue_limit="0"
 ```
 
 Note that, you can add as many Redis server endpoint configurations as needed by providing an identifier (like "1" in the example above) for the Redis instance and an object of per-server configuration parameters.
 
-### Step 2: Enable Redis bucket notification using MinIO client
+### Step 2: Enable Redis bucket notification using Silo client
 
 We will now enable bucket event notifications on a bucket named `images`. Whenever a JPEG image is created/overwritten, a new key is added or an existing key is updated in the Redis hash configured above. When an existing object is deleted, the corresponding key is deleted from the Redis hash. Thus, the rows in the Redis hash, reflect the `.jpg` objects in the `images` bucket.
 
-To configure this bucket notification, we need the ARN printed by MinIO in the previous step. Additional information about ARN is available [here](http://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html).
+To configure this bucket notification, we need the ARN printed by Silo in the previous step. Additional information about ARN is available [here](http://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html).
 
-With the `mc` tool, the configuration is very simple to add. Let us say that the MinIO server is aliased as `myminio` in our mc configuration. Execute the following:
+With the `mc` tool, the configuration is very simple to add. Let us say that the Silo server is aliased as `mysilo` in our mc configuration. Execute the following:
 
 ```
-mc mb myminio/images
+mc mb mysilo/images
-mc event add myminio/images arn:minio:sqs::1:redis --suffix .jpg
+mc event add mysilo/images arn:minio:sqs::1:redis --suffix .jpg
-mc event list myminio/images
+mc event list mysilo/images
 arn:minio:sqs::1:redis s3:ObjectCreated:*,s3:ObjectRemoved:* Filter: suffix=”.jpg”
 ```
 
@@ -588,29 +592,29 @@ OK
 Open another terminal and upload a JPEG image into `images` bucket.
 
 ```
-mc cp myphoto.jpg myminio/images
+mc cp myphoto.jpg mysilo/images
 ```
 
-In the previous terminal, you will now see the operation that MinIO performs on Redis:
+In the previous terminal, you will now see the operation that Silo performs on Redis:
 
 ```
 127.0.0.1:6379> monitor
 OK
 1490686879.650649 [0 172.17.0.1:44710] "PING"
-1490686879.651061 [0 172.17.0.1:44710] "HSET" "minio_events" "images/myphoto.jpg" "{\"Records\":[{\"eventVersion\":\"2.0\",\"eventSource\":\"minio:s3\",\"awsRegion\":\"\",\"eventTime\":\"2017-03-28T07:41:19Z\",\"eventName\":\"s3:ObjectCreated:Put\",\"userIdentity\":{\"principalId\":\"minio\"},\"requestParameters\":{\"sourceIPAddress\":\"127.0.0.1:52234\"},\"responseElements\":{\"x-amz-request-id\":\"14AFFBD1ACE5F632\",\"x-minio-origin-endpoint\":\"http://192.168.86.115:9000\"},\"s3\":{\"s3SchemaVersion\":\"1.0\",\"configurationId\":\"Config\",\"bucket\":{\"name\":\"images\",\"ownerIdentity\":{\"principalId\":\"minio\"},\"arn\":\"arn:aws:s3:::images\"},\"object\":{\"key\":\"myphoto.jpg\",\"size\":2586,\"eTag\":\"5d284463f9da279f060f0ea4d11af098\",\"sequencer\":\"14AFFBD1ACE5F632\"}},\"source\":{\"host\":\"127.0.0.1\",\"port\":\"52234\",\"userAgent\":\"MinIO (linux; amd64) minio-go/2.0.3 mc/2017-02-15T17:57:25Z\"}}]}"
+1490686879.651061 [0 172.17.0.1:44710] "HSET" "minio_events" "images/myphoto.jpg" "{\"Records\":[{\"eventVersion\":\"2.0\",\"eventSource\":\"minio:s3\",\"awsRegion\":\"\",\"eventTime\":\"2017-03-28T07:41:19Z\",\"eventName\":\"s3:ObjectCreated:Put\",\"userIdentity\":{\"principalId\":\"minio\"},\"requestParameters\":{\"sourceIPAddress\":\"127.0.0.1:52234\"},\"responseElements\":{\"x-amz-request-id\":\"14AFFBD1ACE5F632\",\"x-minio-origin-endpoint\":\"http://192.168.86.115:9000\"},\"s3\":{\"s3SchemaVersion\":\"1.0\",\"configurationId\":\"Config\",\"bucket\":{\"name\":\"images\",\"ownerIdentity\":{\"principalId\":\"minio\"},\"arn\":\"arn:aws:s3:::images\"},\"object\":{\"key\":\"myphoto.jpg\",\"size\":2586,\"eTag\":\"5d284463f9da279f060f0ea4d11af098\",\"sequencer\":\"14AFFBD1ACE5F632\"}},\"source\":{\"host\":\"127.0.0.1\",\"port\":\"52234\",\"userAgent\":\"Silo (linux; amd64) minio-go/2.0.3 mc/2017-02-15T17:57:25Z\"}}]}"
 ```
 
-Here we see that MinIO performed `HSET` on `minio_events` key.
+Here we see that Silo performed `HSET` on `minio_events` key.
 
-In case, `access` format was used, then `minio_events` would be a list, and the MinIO server would have performed an `RPUSH` to append to the list. A consumer of this list would ideally use `BLPOP` to remove list items from the left-end of the list.
+In case, `access` format was used, then `minio_events` would be a list, and the Silo server would have performed an `RPUSH` to append to the list. A consumer of this list would ideally use `BLPOP` to remove list items from the left-end of the list.
 
-## Publish MinIO events via NATS
+## Publish Silo events via NATS
 
 Install NATS from [here](http://nats.io/).
 
-### Step 1: Add NATS endpoint to MinIO
+### Step 1: Add NATS endpoint to Silo
 
-MinIO supports persistent event store. The persistent store will backup events when the NATS broker goes offline and replays it when the broker comes back online. The event store can be configured by setting the directory path in `queue_dir` field and the maximum limit of events in the queue_dir in `queue_limit` field. For eg, the `queue_dir` can be `/home/events` and `queue_limit` can be `1000`. By default, the `queue_limit` is set to 100000.
+Silo supports persistent event store. The persistent store will backup events when the NATS broker goes offline and replays it when the broker comes back online. The event store can be configured by setting the directory path in `queue_dir` field and the maximum limit of events in the queue_dir in `queue_limit` field. For eg, the `queue_dir` can be `/home/events` and `queue_limit` can be `1000`. By default, the `queue_limit` is set to 100000.
 
 ```
 KEY:
@@ -665,31 +669,32 @@ MINIO_NOTIFY_NATS_QUEUE_LIMIT                       (number)    maximum limit fo
 MINIO_NOTIFY_NATS_COMMENT                           (sentence)  optionally add a comment to this setting
 ```
 
-To update the configuration, use `mc admin config get` command to get the current configuration file for the minio deployment.
+To update the configuration, use `mc admin config get` to retrieve the current
+configuration for the Silo deployment.
 
 ```sh
-$ mc admin config get myminio/ notify_nats
+$ mc admin config get mysilo/ notify_nats
 notify_nats:1 password="yoursecret" streaming_max_pub_acks_in_flight="10" subject="" address="0.0.0.0:4222"  token="" username="yourusername" ping_interval="0" queue_limit="0" tls="off" tls_skip_verify="off" streaming_async="on" queue_dir="" streaming_cluster_id="test-cluster" streaming_enable="on"
 ```
 
-Use `mc admin config set` command to update the configuration for the deployment.Restart MinIO server to reflect config changes. `bucketevents` is the subject used by NATS in this example.
+Use `mc admin config set` command to update the configuration for the deployment.Restart Silo server to reflect config changes. `bucketevents` is the subject used by NATS in this example.
 
 ```sh
-mc admin config set myminio notify_nats:1 password="yoursecret" streaming_max_pub_acks_in_flight="10" subject="" address="0.0.0.0:4222"  token="" username="yourusername" ping_interval="0" queue_limit="0" tls="off" streaming_async="on" queue_dir="" streaming_cluster_id="test-cluster" streaming_enable="on"
+mc admin config set mysilo notify_nats:1 password="yoursecret" streaming_max_pub_acks_in_flight="10" subject="" address="0.0.0.0:4222"  token="" username="yourusername" ping_interval="0" queue_limit="0" tls="off" streaming_async="on" queue_dir="" streaming_cluster_id="test-cluster" streaming_enable="on"
 ```
 
-MinIO server also supports [NATS Streaming mode](http://nats.io/documentation/streaming/nats-streaming-intro/) that offers additional functionality like `At-least-once-delivery`, and `Publisher rate limiting`. To configure MinIO server to send notifications to NATS Streaming server, update the MinIO server configuration file as follows:
+Silo server also supports [NATS Streaming mode](http://nats.io/documentation/streaming/nats-streaming-intro/) that offers additional functionality like `At-least-once-delivery`, and `Publisher rate limiting`. To configure Silo server to send notifications to NATS Streaming server, update the Silo server configuration file as follows:
 
 Read more about sections `cluster_id`, `client_id` on [NATS documentation](https://github.com/nats-io/nats-streaming-server/blob/master/README.md). Section `maxPubAcksInflight` is explained [here](https://github.com/nats-io/stan.go#publisher-rate-limiting).
 
-### Step 2: Enable NATS bucket notification using MinIO client
+### Step 2: Enable NATS bucket notification using Silo client
 
-We will enable bucket event notification to trigger whenever a JPEG image is uploaded or deleted from `images` bucket on `myminio` server. Here ARN value is `arn:minio:sqs::1:nats`. To understand more about ARN please follow [AWS ARN](http://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html) documentation.
+We will enable bucket event notification to trigger whenever a JPEG image is uploaded or deleted from `images` bucket on `mysilo` server. Here ARN value is `arn:minio:sqs::1:nats`. To understand more about ARN please follow [AWS ARN](http://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html) documentation.
 
 ```
-mc mb myminio/images
+mc mb mysilo/images
-mc event add myminio/images arn:minio:sqs::1:nats --suffix .jpg
+mc event add mysilo/images arn:minio:sqs::1:nats --suffix .jpg
-mc event list myminio/images
+mc event list mysilo/images
 arn:minio:sqs::1:nats s3:ObjectCreated:*,s3:ObjectRemoved:* Filter: suffix=”.jpg”
 ```
 
@@ -736,7 +741,7 @@ go run nats.go
 Open another terminal and upload a JPEG image into `images` bucket.
 
 ```
-mc cp myphoto.jpg myminio/images
+mc cp myphoto.jpg mysilo/images
 ```
 
 The example `nats.go` program prints event notification to console.
@@ -814,16 +819,16 @@ go run nats.go
 Open another terminal and upload a JPEG image into `images` bucket.
 
 ```
-mc cp myphoto.jpg myminio/images
+mc cp myphoto.jpg mysilo/images
 ```
 
 The example `nats.go` program prints event notification to console.
 
 ```
-Received a message: {"EventType":"s3:ObjectCreated:Put","Key":"images/myphoto.jpg","Records":[{"eventVersion":"2.0","eventSource":"minio:s3","awsRegion":"","eventTime":"2017-07-07T18:46:37Z","eventName":"s3:ObjectCreated:Put","userIdentity":{"principalId":"minio"},"requestParameters":{"sourceIPAddress":"192.168.1.80:55328"},"responseElements":{"x-amz-request-id":"14CF20BD1EFD5B93","x-minio-origin-endpoint":"http://127.0.0.1:9000"},"s3":{"s3SchemaVersion":"1.0","configurationId":"Config","bucket":{"name":"images","ownerIdentity":{"principalId":"minio"},"arn":"arn:aws:s3:::images"},"object":{"key":"myphoto.jpg","size":248682,"eTag":"f1671feacb8bbf7b0397c6e9364e8c92","contentType":"image/jpeg","userDefined":{"content-type":"image/jpeg"},"versionId":"1","sequencer":"14CF20BD1EFD5B93"}},"source":{"host":"192.168.1.80","port":"55328","userAgent":"MinIO (linux; amd64) minio-go/2.0.4 mc/DEVELOPMENT.GOGET"}}],"level":"info","msg":"","time":"2017-07-07T11:46:37-07:00"}
+Received a message: {"EventType":"s3:ObjectCreated:Put","Key":"images/myphoto.jpg","Records":[{"eventVersion":"2.0","eventSource":"minio:s3","awsRegion":"","eventTime":"2017-07-07T18:46:37Z","eventName":"s3:ObjectCreated:Put","userIdentity":{"principalId":"minio"},"requestParameters":{"sourceIPAddress":"192.168.1.80:55328"},"responseElements":{"x-amz-request-id":"14CF20BD1EFD5B93","x-minio-origin-endpoint":"http://127.0.0.1:9000"},"s3":{"s3SchemaVersion":"1.0","configurationId":"Config","bucket":{"name":"images","ownerIdentity":{"principalId":"minio"},"arn":"arn:aws:s3:::images"},"object":{"key":"myphoto.jpg","size":248682,"eTag":"f1671feacb8bbf7b0397c6e9364e8c92","contentType":"image/jpeg","userDefined":{"content-type":"image/jpeg"},"versionId":"1","sequencer":"14CF20BD1EFD5B93"}},"source":{"host":"192.168.1.80","port":"55328","userAgent":"Silo (linux; amd64) minio-go/2.0.4 mc/DEVELOPMENT.GOGET"}}],"level":"info","msg":"","time":"2017-07-07T11:46:37-07:00"}
 ```
 
-## Publish MinIO events via PostgreSQL
+## Publish Silo events via PostgreSQL
 
 > NOTE: Until release RELEASE.2020-04-10T03-34-42Z PostgreSQL notification used to support following options:
 >
@@ -840,28 +845,28 @@ Received a message: {"EventType":"s3:ObjectCreated:Put","Key":"images/myphoto.jp
 > following command to update the existing notification targets.
 >
 > ```
-> mc admin config set myminio/ notify_postgres[:name] connection_string="host=hostname port=2832 username=psqluser password=psqlpass database=bucketevents"
+> mc admin config set mysilo/ notify_postgres[:name] connection_string="host=hostname port=2832 username=psqluser password=psqlpass database=bucketevents"
 > ```
 >
 > Please make sure this step is carried out, without this step PostgreSQL notification targets will not work,
 > an error message will be shown on the console upon server upgrade/restart, make sure to follow the above
-> instructions appropriately. For further questions please join our <https://slack.min.io>
+> instructions appropriately. For further guidance, use the [Silo documentation](https://silo.pgsty.com/docs/).
 
 Install [PostgreSQL](https://www.postgresql.org/) database server. For illustrative purposes, we have set the "postgres" user password as `password` and created a database called `minio_events` to store the events.
 
 This notification target supports two formats: _namespace_ and _access_.
 
-When the _namespace_ format is used, MinIO synchronizes objects in the bucket with rows in the table. It creates rows with two columns: key and value. The key is the bucket and object name of an object that exists in MinIO. The value is JSON encoded event data about the operation that created/replaced the object in MinIO. When objects are updated or deleted, the corresponding row from this table is updated or deleted respectively.
+When the _namespace_ format is used, Silo synchronizes objects in the bucket with rows in the table. It creates rows with two columns: key and value. The key is the bucket and object name of an object that exists in Silo. The value is JSON encoded event data about the operation that created/replaced the object in Silo. When objects are updated or deleted, the corresponding row from this table is updated or deleted respectively.
 
-When the _access_ format is used, MinIO appends events to a table. It creates rows with two columns: event_time and event_data. The event_time is the time at which the event occurred in the MinIO server. The event_data is the JSON encoded event data about the operation on an object. No rows are deleted or modified in this format.
+When the _access_ format is used, Silo appends events to a table. It creates rows with two columns: event_time and event_data. The event_time is the time at which the event occurred in the Silo server. The event_data is the JSON encoded event data about the operation on an object. No rows are deleted or modified in this format.
 
 The steps below show how to use this notification target in `namespace` format. The other format is very similar and is omitted for brevity.
 
 ### Step 1: Ensure postgresql minimum requirements are met
 
-MinIO requires PostgreSQL version 9.5 or above. MinIO uses the [`INSERT ON CONFLICT`](https://www.postgresql.org/docs/9.5/static/sql-insert.html#SQL-ON-CONFLICT) (aka UPSERT) feature, introduced in version 9.5 and the [JSONB](https://www.postgresql.org/docs/9.4/static/datatype-json.html) data-type introduced in version 9.4.
+Silo requires PostgreSQL version 9.5 or above. Silo uses the [`INSERT ON CONFLICT`](https://www.postgresql.org/docs/9.5/static/sql-insert.html#SQL-ON-CONFLICT) (aka UPSERT) feature, introduced in version 9.5 and the [JSONB](https://www.postgresql.org/docs/9.4/static/datatype-json.html) data-type introduced in version 9.4.
 
-### Step 2: Add PostgreSQL endpoint to MinIO
+### Step 2: Add PostgreSQL endpoint to Silo
 
 The PostgreSQL configuration is located in the `notify_postgresql` key. Create a configuration key-value pair here for your PostgreSQL instance. The key is a name for your PostgreSQL endpoint, and the value is a collection of key-value parameters described in the table below.
 
@@ -899,40 +904,40 @@ MINIO_NOTIFY_POSTGRES_MAX_OPEN_CONNECTIONS (number)             maximum number o
 > NOTE: If the `max_open_connections` key or the environment variable `MINIO_NOTIFY_POSTGRES_MAX_OPEN_CONNECTIONS` is set to `0`, There will be no limit set on the number of
 > open connections to the database. This setting is generally NOT recommended as the behavior may be inconsistent during recursive deletes in `namespace` format.
 
-MinIO supports persistent event store. The persistent store will backup events when the PostgreSQL connection goes offline and replays it when the broker comes back online. The event store can be configured by setting the directory path in `queue_dir` field and the maximum limit of events in the queue_dir in `queue_limit` field. For eg, the `queue_dir` can be `/home/events` and `queue_limit` can be `1000`. By default, the `queue_limit` is set to 100000.
+Silo supports persistent event store. The persistent store will backup events when the PostgreSQL connection goes offline and replays it when the broker comes back online. The event store can be configured by setting the directory path in `queue_dir` field and the maximum limit of events in the queue_dir in `queue_limit` field. For eg, the `queue_dir` can be `/home/events` and `queue_limit` can be `1000`. By default, the `queue_limit` is set to 100000.
 
 Note that for illustration here, we have disabled SSL. In the interest of security, for production this is not recommended.
 To update the configuration, use `mc admin config get` command to get the current configuration.
 
 ```sh
-$ mc admin config get myminio notify_postgres
+$ mc admin config get mysilo notify_postgres
 notify_postgres:1 queue_dir="" connection_string="" queue_limit="0"  table="" format="namespace"
 ```
 
-Use `mc admin config set` command to update the configuration for the deployment. Restart the MinIO server to put the changes into effect. The server will print a line like `SQS ARNs: arn:minio:sqs::1:postgresql` at start-up if there were no errors.
+Use `mc admin config set` command to update the configuration for the deployment. Restart the Silo server to put the changes into effect. The server will print a line like `SQS ARNs: arn:minio:sqs::1:postgresql` at start-up if there were no errors.
 
 ```sh
-mc admin config set myminio notify_postgres:1 connection_string="host=localhost port=5432 dbname=minio_events user=postgres password=password sslmode=disable" table="bucketevents" format="namespace"
+mc admin config set mysilo notify_postgres:1 connection_string="host=localhost port=5432 dbname=minio_events user=postgres password=password sslmode=disable" table="bucketevents" format="namespace"
 ```
 
 Note that, you can add as many PostgreSQL server endpoint configurations as needed by providing an identifier (like "1" in the example above) for the PostgreSQL instance and an object of per-server configuration parameters.
 
-### Step 3: Enable PostgreSQL bucket notification using MinIO client
+### Step 3: Enable PostgreSQL bucket notification using Silo client
 
 We will now enable bucket event notifications on a bucket named `images`. Whenever a JPEG image is created/overwritten, a new row is added or an existing row is updated in the PostgreSQL configured above. When an existing object is deleted, the corresponding row is deleted from the PostgreSQL table. Thus, the rows in the PostgreSQL table, reflect the `.jpg` objects in the `images` bucket.
 
-To configure this bucket notification, we need the ARN printed by MinIO in the previous step. Additional information about ARN is available [here](http://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html).
+To configure this bucket notification, we need the ARN printed by Silo in the previous step. Additional information about ARN is available [here](http://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html).
 
-With the `mc` tool, the configuration is very simple to add. Let us say that the MinIO server is aliased as `myminio` in our mc configuration. Execute the following:
+With the `mc` tool, the configuration is very simple to add. Let us say that the Silo server is aliased as `mysilo` in our mc configuration. Execute the following:
 
 ```
-# Create bucket named `images` in myminio
+# Create bucket named `images` in mysilo
-mc mb myminio/images
+mc mb mysilo/images
 # Add notification configuration on the `images` bucket using the MySQL ARN. The --suffix argument filters events.
-mc event add myminio/images arn:minio:sqs::1:postgresql --suffix .jpg
+mc event add mysilo/images arn:minio:sqs::1:postgresql --suffix .jpg
 # Print out the notification configuration on the `images` bucket.
-mc event list myminio/images
+mc event list mysilo/images
-mc event list myminio/images
+mc event list mysilo/images
 arn:minio:sqs::1:postgresql s3:ObjectCreated:*,s3:ObjectRemoved:* Filter: suffix=”.jpg”
 ```
 
@@ -941,7 +946,7 @@ arn:minio:sqs::1:postgresql s3:ObjectCreated:*,s3:ObjectRemoved:* Filter: suffix
 Open another terminal and upload a JPEG image into `images` bucket.
 
 ```
-mc cp myphoto.jpg myminio/images
+mc cp myphoto.jpg mysilo/images
 ```
 
 Open PostgreSQL terminal to list the rows in the `bucketevents` table.
@@ -956,7 +961,7 @@ key                 |                      value
 (1 row)
 ```
 
-## Publish MinIO events via MySQL
+## Publish Silo events via MySQL
 
 > NOTE: Until release RELEASE.2020-04-10T03-34-42Z MySQL notification used to support following options:
 >
@@ -973,28 +978,28 @@ key                 |                      value
 > following command to update the existing notification targets.
 >
 > ```
-> mc admin config set myminio/ notify_mysql[:name] dsn_string="mysqluser:mysqlpass@tcp(localhost:2832)/bucketevents"
+> mc admin config set mysilo/ notify_mysql[:name] dsn_string="mysqluser:mysqlpass@tcp(localhost:2832)/bucketevents"
 > ```
 >
 > Please make sure this step is carried out, without this step MySQL notification targets will not work,
 > an error message will be shown on the console upon server upgrade/restart, make sure to follow the above
-> instructions appropriately. For further questions please join our <https://slack.min.io>
+> instructions appropriately. For further guidance, use the [Silo documentation](https://silo.pgsty.com/docs/).
 
 Install MySQL from [here](https://dev.mysql.com/downloads/mysql/). For illustrative purposes, we have set the root password as `password` and created a database called `miniodb` to store the events.
 
 This notification target supports two formats: _namespace_ and _access_.
 
-When the _namespace_ format is used, MinIO synchronizes objects in the bucket with rows in the table. It creates rows with two columns: key_name and value. The key_name is the bucket and object name of an object that exists in MinIO. The value is JSON encoded event data about the operation that created/replaced the object in MinIO. When objects are updated or deleted, the corresponding row from this table is updated or deleted respectively.
+When the _namespace_ format is used, Silo synchronizes objects in the bucket with rows in the table. It creates rows with two columns: key_name and value. The key_name is the bucket and object name of an object that exists in Silo. The value is JSON encoded event data about the operation that created/replaced the object in Silo. When objects are updated or deleted, the corresponding row from this table is updated or deleted respectively.
 
-When the _access_ format is used, MinIO appends events to a table. It creates rows with two columns: event_time and event_data. The event_time is the time at which the event occurred in the MinIO server. The event_data is the JSON encoded event data about the operation on an object. No rows are deleted or modified in this format.
+When the _access_ format is used, Silo appends events to a table. It creates rows with two columns: event_time and event_data. The event_time is the time at which the event occurred in the Silo server. The event_data is the JSON encoded event data about the operation on an object. No rows are deleted or modified in this format.
 
 The steps below show how to use this notification target in `namespace` format. The other format is very similar and is omitted for brevity.
 
 ### Step 1: Ensure MySQL minimum requirements are met
 
-MinIO requires MySQL version 5.7.8 or above. MinIO uses the [JSON](https://dev.mysql.com/doc/refman/5.7/en/json.html) data-type introduced in version 5.7.8. We tested this setup on MySQL 5.7.17.
+Silo requires MySQL version 5.7.8 or above. Silo uses the [JSON](https://dev.mysql.com/doc/refman/5.7/en/json.html) data-type introduced in version 5.7.8. We tested this setup on MySQL 5.7.17.
 
-### Step 2: Add MySQL server endpoint configuration to MinIO
+### Step 2: Add MySQL server endpoint configuration to Silo
 
 The MySQL configuration is located in the `notify_mysql` key. Create a configuration key-value pair here for your MySQL instance. The key is a name for your MySQL endpoint, and the value is a collection of key-value parameters described in the table below.
 
@@ -1034,40 +1039,40 @@ MINIO_NOTIFY_MYSQL_COMMENT              (sentence)           optionally add a co
 
 `dsn_string` is required and is of form `"<user>:<password>@tcp(<host>:<port>)/<database>"`
 
-MinIO supports persistent event store. The persistent store will backup events if MySQL connection goes offline and then replays the stored events when the broken connection comes back up. The event store can be configured by setting a directory path in `queue_dir` field, and the maximum number of events, which can be stored in a `queue_dir`, in `queue_limit` field. For example, `queue_dir` can be set to `/home/events` and `queue_limit` can be set to `1000`. By default, the `queue_limit` is set to `100000`.
+Silo supports persistent event store. The persistent store will backup events if MySQL connection goes offline and then replays the stored events when the broken connection comes back up. The event store can be configured by setting a directory path in `queue_dir` field, and the maximum number of events, which can be stored in a `queue_dir`, in `queue_limit` field. For example, `queue_dir` can be set to `/home/events` and `queue_limit` can be set to `1000`. By default, the `queue_limit` is set to `100000`.
 
 Before updating the configuration, let's start with `mc admin config get` command to get the current configuration.
 
 ```sh
-$ mc admin config get myminio/ notify_mysql
+$ mc admin config get mysilo/ notify_mysql
 notify_mysql:myinstance enable=off format=namespace host= port= username= password= database= dsn_string= table= queue_dir= queue_limit=0
 ```
 
 Use `mc admin config set` command to update MySQL notification configuration for the deployment with `dsn_string` parameter:
 
 ```sh
-mc admin config set myminio notify_mysql:myinstance table="minio_images" dsn_string="root:xxxx@tcp(172.17.0.1:3306)/miniodb"
+mc admin config set mysilo notify_mysql:myinstance table="minio_images" dsn_string="root:xxxx@tcp(172.17.0.1:3306)/miniodb"
 ```
 
 Note that, you can add as many MySQL server endpoint configurations as needed by providing an identifier (like "myinstance" in the example above) for each MySQL instance desired.
 
-Restart the MinIO server to put the changes into effect. The server will print a line like `SQS ARNs: arn:minio:sqs::myinstance:mysql` at start-up, if there are no errors.
+Restart the Silo server to put the changes into effect. The server will print a line like `SQS ARNs: arn:minio:sqs::myinstance:mysql` at start-up, if there are no errors.
 
-### Step 3: Enable MySQL bucket notification using MinIO client
+### Step 3: Enable MySQL bucket notification using Silo client
 
 We will now setup bucket notifications on a bucket named `images`. Whenever a JPEG image object is created/overwritten, a new row is added or an existing row is updated in the MySQL table configured above. When an existing object is deleted, the corresponding row is deleted from the MySQL table. Thus, the rows in the MySQL table, reflect the `.jpg` objects in the `images` bucket.
 
-To configure this bucket notification, we need the ARN printed by MinIO in the previous step. Additional information about ARN is available [here](http://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html).
+To configure this bucket notification, we need the ARN printed by Silo in the previous step. Additional information about ARN is available [here](http://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html).
 
-With the `mc` tool, the configuration is very simple to add. Let us say that the MinIO server is aliased as `myminio` in our mc configuration. Execute the following:
+With the `mc` tool, the configuration is very simple to add. Let us say that the Silo server is aliased as `mysilo` in our mc configuration. Execute the following:
 
 ```
-# Create bucket named `images` in myminio
+# Create bucket named `images` in mysilo
-mc mb myminio/images
+mc mb mysilo/images
 # Add notification configuration on the `images` bucket using the MySQL ARN. The --suffix argument filters events.
-mc event add myminio/images arn:minio:sqs::myinstance:mysql --suffix .jpg
+mc event add mysilo/images arn:minio:sqs::myinstance:mysql --suffix .jpg
 # Print out the notification configuration on the `images` bucket.
-mc event list myminio/images
+mc event list mysilo/images
 arn:minio:sqs::myinstance:mysql s3:ObjectCreated:*,s3:ObjectRemoved:*,s3:ObjectAccessed:* Filter: suffix=”.jpg”
 ```
 
@@ -1076,7 +1081,7 @@ arn:minio:sqs::myinstance:mysql s3:ObjectCreated:*,s3:ObjectRemoved:*,s3:ObjectA
 Open another terminal and upload a JPEG image into `images` bucket:
 
 ```
-mc cp myphoto.jpg myminio/images
+mc cp myphoto.jpg mysilo/images
 ```
 
 Open MySQL terminal and list the rows in the `minio_images` table.
@@ -1093,17 +1098,17 @@ mysql> select * from minio_images;
 
 ```
 
-## Publish MinIO events via Kafka
+## Publish Silo events via Kafka
 
 Install Apache Kafka from [here](http://kafka.apache.org/).
 
 ### Step 1: Ensure minimum requirements are met
 
-MinIO requires Kafka version 0.10 or 0.9. Internally MinIO uses the [Shopify/sarama](https://github.com/Shopify/sarama/) library and so has the same version compatibility as provided by this library.
+Silo requires Kafka version 0.10 or 0.9. Internally Silo uses the [Shopify/sarama](https://github.com/Shopify/sarama/) library and so has the same version compatibility as provided by this library.
 
-### Step 2: Add Kafka endpoint to MinIO
+### Step 2: Add Kafka endpoint to Silo
 
-MinIO supports persistent event store. The persistent store will backup events when the kafka broker goes offline and replays it when the broker comes back online. The event store can be configured by setting the directory path in `queue_dir` field and the maximum limit of events in the queue_dir in `queue_limit` field. For eg, the `queue_dir` can be `/home/events` and `queue_limit` can be `1000`. By default, the `queue_limit` is set to 100000.
+Silo supports persistent event store. The persistent store will backup events when the kafka broker goes offline and replays it when the broker comes back online. The event store can be configured by setting the directory path in `queue_dir` field and the maximum limit of events in the queue_dir in `queue_limit` field. For eg, the `queue_dir` can be `/home/events` and `queue_limit` can be `1000`. By default, the `queue_limit` is set to 100000.
 
 ```
 KEY:
@@ -1157,24 +1162,24 @@ MINIO_NOTIFY_KAFKA_PRODUCER_COMPRESSION_LEVEL  (number)                    compr
 To update the configuration, use `mc admin config get` command to get the current configuration.
 
 ```sh
-$ mc admin config get myminio/ notify_kafka
+$ mc admin config get mysilo/ notify_kafka
 notify_kafka:1 tls_skip_verify="off"  queue_dir="" queue_limit="0" sasl="off" sasl_password="" sasl_username="" tls_client_auth="0" tls="off" brokers="" topic="" client_tls_cert="" client_tls_key="" version=""
 ```
 
-Use `mc admin config set` command to update the configuration for the deployment. Restart the MinIO server to put the changes into effect. The server will print a line like `SQS ARNs: arn:minio:sqs::1:kafka` at start-up if there were no errors.`bucketevents` is the topic used by kafka in this example.
+Use `mc admin config set` command to update the configuration for the deployment. Restart the Silo server to put the changes into effect. The server will print a line like `SQS ARNs: arn:minio:sqs::1:kafka` at start-up if there were no errors.`bucketevents` is the topic used by kafka in this example.
 
 ```sh
-mc admin config set myminio notify_kafka:1 tls_skip_verify="off"  queue_dir="" queue_limit="0" sasl="off" sasl_password="" sasl_username="" tls_client_auth="0" tls="off" client_tls_cert="" client_tls_key="" brokers="localhost:9092,localhost:9093" topic="bucketevents" version=""
+mc admin config set mysilo notify_kafka:1 tls_skip_verify="off"  queue_dir="" queue_limit="0" sasl="off" sasl_password="" sasl_username="" tls_client_auth="0" tls="off" client_tls_cert="" client_tls_key="" brokers="localhost:9092,localhost:9093" topic="bucketevents" version=""
 ```
 
-### Step 3: Enable Kafka bucket notification using MinIO client
+### Step 3: Enable Kafka bucket notification using Silo client
 
-We will enable bucket event notification to trigger whenever a JPEG image is uploaded or deleted from `images` bucket on `myminio` server. Here ARN value is `arn:minio:sqs::1:kafka`. To understand more about ARN please follow [AWS ARN](http://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html) documentation.
+We will enable bucket event notification to trigger whenever a JPEG image is uploaded or deleted from `images` bucket on `mysilo` server. Here ARN value is `arn:minio:sqs::1:kafka`. To understand more about ARN please follow [AWS ARN](http://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html) documentation.
 
 ```
-mc mb myminio/images
+mc mb mysilo/images
-mc event add  myminio/images arn:minio:sqs::1:kafka --suffix .jpg
+mc event add  mysilo/images arn:minio:sqs::1:kafka --suffix .jpg
-mc event list myminio/images
+mc event list mysilo/images
 arn:minio:sqs::1:kafka s3:ObjectCreated:*,s3:ObjectRemoved:* Filter: suffix=”.jpg”
 ```
 
@@ -1189,7 +1194,7 @@ kafkacat -C -b localhost:9092 -t bucketevents
 Open another terminal and upload a JPEG image into `images` bucket.
 
 ```
-mc cp myphoto.jpg myminio/images
+mc cp myphoto.jpg mysilo/images
 ```
 
 `kafkacat` prints the event notification to the console.
@@ -1251,13 +1256,13 @@ kafkacat -b localhost:9092 -t bucketevents
 }
 ```
 
-## Publish MinIO events via Webhooks
+## Publish Silo events via Webhooks
 
 [Webhooks](https://en.wikipedia.org/wiki/Webhook) are a way to receive information when it happens, rather than continually polling for that data.
 
-### Step 1: Add Webhook endpoint to MinIO
+### Step 1: Add Webhook endpoint to Silo
 
-MinIO supports persistent event store. The persistent store will backup events when the webhook goes offline and replays it when the broker comes back online. The event store can be configured by setting the directory path in `queue_dir` field and the maximum limit of events in the queue_dir in `queue_limit` field. For eg, the `queue_dir` can be `/home/events` and `queue_limit` can be `1000`. By default, the `queue_limit` is set to 100000.
+Silo supports persistent event store. The persistent store will backup events when the webhook goes offline and replays it when the broker comes back online. The event store can be configured by setting the directory path in `queue_dir` field and the maximum limit of events in the queue_dir in `queue_limit` field. For eg, the `queue_dir` can be `/home/events` and `queue_limit` can be `1000`. By default, the `queue_limit` is set to 100000.
 
 ```
 KEY:
@@ -1291,30 +1296,30 @@ MINIO_NOTIFY_WEBHOOK_CLIENT_KEY   (string)    client cert key for Webhook mTLS a
 ```
 
 ```sh
-$ mc admin config get myminio/ notify_webhook
+$ mc admin config get mysilo/ notify_webhook
 notify_webhook:1 endpoint="" auth_token="" queue_limit="0" queue_dir="" client_cert="" client_key=""
 ```
 
-Use `mc admin config set` command to update the configuration for the deployment. Here the endpoint is the server listening for webhook notifications. Save the settings and restart the MinIO server for changes to take effect. Note that the endpoint needs to be live and reachable when you restart your MinIO server.
+Use `mc admin config set` command to update the configuration for the deployment. Here the endpoint is the server listening for webhook notifications. Save the settings and restart the Silo server for changes to take effect. Note that the endpoint needs to be live and reachable when you restart your Silo server.
 
 ```sh
-mc admin config set myminio notify_webhook:1 queue_limit="0"  endpoint="http://localhost:3000" queue_dir=""
+mc admin config set mysilo notify_webhook:1 queue_limit="0"  endpoint="http://localhost:3000" queue_dir=""
 ```
 
-### Step 2: Enable Webhook bucket notification using MinIO client
+### Step 2: Enable Webhook bucket notification using Silo client
 
-We will enable bucket event notification to trigger whenever a JPEG image is uploaded to `images` bucket on `myminio` server. Here ARN value is `arn:minio:sqs::1:webhook`. To learn more about ARN please follow [AWS ARN](http://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html) documentation.
+We will enable bucket event notification to trigger whenever a JPEG image is uploaded to `images` bucket on `mysilo` server. Here ARN value is `arn:minio:sqs::1:webhook`. To learn more about ARN please follow [AWS ARN](http://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html) documentation.
 
 ```
-mc mb myminio/images
+mc mb mysilo/images
-mc mb myminio/images-thumbnail
+mc mb mysilo/images-thumbnail
-mc event add myminio/images arn:minio:sqs::1:webhook --event put --suffix .jpg
+mc event add mysilo/images arn:minio:sqs::1:webhook --event put --suffix .jpg
 ```
 
 Check if event notification is successfully configured by
 
 ```
-mc event list myminio/images
+mc event list mysilo/images
 ```
 
 You should get a response like this
@@ -1325,34 +1330,34 @@ arn:minio:sqs::1:webhook   s3:ObjectCreated:*   Filter: suffix=".jpg"
 
 ### Step 3: Test with Thumbnailer
 
-We used [Thumbnailer](https://github.com/minio/thumbnailer) to listen for MinIO notifications when a new JPEG file is uploaded (HTTP PUT). Triggered by a notification, Thumbnailer uploads a thumbnail of new image to MinIO server. To start with, download and install Thumbnailer.
+We used [Thumbnailer](https://github.com/minio/thumbnailer) to listen for Silo notifications when a new JPEG file is uploaded (HTTP PUT). Triggered by a notification, Thumbnailer uploads a thumbnail of new image to Silo server. To start with, download and install Thumbnailer.
 
 ```
 git clone https://github.com/minio/thumbnailer/
 npm install
 ```
 
-Then open the Thumbnailer config file at `config/webhook.json` and add the configuration for your MinIO server and then start Thumbnailer by
+Then open the Thumbnailer config file at `config/webhook.json` and add the configuration for your Silo server and then start Thumbnailer by
 
 ```
 NODE_ENV=webhook node thumbnail-webhook.js
 ```
 
-Thumbnailer starts running at `http://localhost:3000/`. Next, configure the MinIO server to send notifications to this URL (as mentioned in step 1) and use `mc` to set up bucket notifications (as mentioned in step 2). Then upload a JPEG image to MinIO server by
+Thumbnailer starts running at `http://localhost:3000/`. Next, configure the Silo server to send notifications to this URL (as mentioned in step 1) and use `mc` to set up bucket notifications (as mentioned in step 2). Then upload a JPEG image to Silo server by
 
 ```
-mc cp ~/images.jpg myminio/images
+mc cp ~/images.jpg mysilo/images
 .../images.jpg:  8.31 KB / 8.31 KB ┃▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓┃ 100.00% 59.42 KB/s 0s
 ```
 
 Wait a few moments, then check the bucket’s contents with mc ls — you will see a thumbnail appear.
 
 ```
-mc ls myminio/images-thumbnail
+mc ls mysilo/images-thumbnail
 [2017-02-08 11:39:40 IST]   992B images-thumbnail.jpg
 ```
 
-## Publish MinIO events to NSQ
+## Publish Silo events to NSQ
 
 Install an NSQ Daemon from [here](https://nsq.io/). Or use the following Docker
 command for starting an nsq daemon:
@@ -1361,9 +1366,9 @@ command for starting an nsq daemon:
 podman run --rm -p 4150-4151:4150-4151 nsqio/nsq /nsqd
 ```
 
-### Step 1: Add NSQ endpoint to MinIO
+### Step 1: Add NSQ endpoint to Silo
 
-MinIO supports persistent event store. The persistent store will backup events when the NSQ broker goes offline and replays it when the broker comes back online. The event store can be configured by setting the directory path in `queue_dir` field and the maximum limit of events in the queue_dir in `queue_limit` field. For eg, the `queue_dir` can be `/home/events` and `queue_limit` can be `1000`. By default, the `queue_limit` is set to 100000.
+Silo supports persistent event store. The persistent store will backup events when the NSQ broker goes offline and replays it when the broker comes back online. The event store can be configured by setting the directory path in `queue_dir` field and the maximum limit of events in the queue_dir in `queue_limit` field. For eg, the `queue_dir` can be `/home/events` and `queue_limit` can be `1000`. By default, the `queue_limit` is set to 100000.
 
 To update the configuration, use `mc admin config get` command to get the current configuration for `notify_nsq`.
 
@@ -1399,26 +1404,26 @@ MINIO_NOTIFY_NSQ_COMMENT          (sentence)  optionally add a comment to this s
 ```
 
 ```sh
-$ mc admin config get myminio/ notify_nsq
+$ mc admin config get mysilo/ notify_nsq
 notify_nsq:1 nsqd_address="" queue_dir="" queue_limit="0"  tls="off" tls_skip_verify="off" topic=""
 ```
 
-Use `mc admin config set` command to update the configuration for the deployment. Restart the MinIO server to put the changes into effect. The server will print a line like `SQS ARNs: arn:minio:sqs::1:nsq` at start-up if there were no errors.
+Use `mc admin config set` command to update the configuration for the deployment. Restart the Silo server to put the changes into effect. The server will print a line like `SQS ARNs: arn:minio:sqs::1:nsq` at start-up if there were no errors.
 
 ```sh
-mc admin config set myminio notify_nsq:1 nsqd_address="127.0.0.1:4150" queue_dir="" queue_limit="0" tls="off" tls_skip_verify="on" topic="minio"
+mc admin config set mysilo notify_nsq:1 nsqd_address="127.0.0.1:4150" queue_dir="" queue_limit="0" tls="off" tls_skip_verify="on" topic="minio"
 ```
 
 Note that, you can add as many NSQ daemon endpoint configurations as needed by providing an identifier (like "1" in the example above) for the NSQ instance and an object of per-server configuration parameters.
 
-### Step 2: Enable NSQ bucket notification using MinIO client
+### Step 2: Enable NSQ bucket notification using Silo client
 
-We will enable bucket event notification to trigger whenever a JPEG image is uploaded or deleted `images` bucket on `myminio` server. Here ARN value is `arn:minio:sqs::1:nsq`.
+We will enable bucket event notification to trigger whenever a JPEG image is uploaded or deleted `images` bucket on `mysilo` server. Here ARN value is `arn:minio:sqs::1:nsq`.
 
 ```
-mc mb myminio/images
+mc mb mysilo/images
-mc event add  myminio/images arn:minio:sqs::1:nsq --suffix .jpg
+mc event add  mysilo/images arn:minio:sqs::1:nsq --suffix .jpg
-mc event list myminio/images
+mc event list mysilo/images
 arn:minio:sqs::1:nsq s3:ObjectCreated:*,s3:ObjectRemoved:* Filter: suffix=”.jpg”
 ```
 
@@ -1433,11 +1438,11 @@ The simplest test is to download `nsq_tail` from [nsq github](https://github.com
 Open another terminal and upload a JPEG image into `images` bucket.
 
 ```
-mc cp gopher.jpg myminio/images
+mc cp gopher.jpg mysilo/images
 ```
 
 You should receive the following event notification via NSQ once the upload completes.
 
 ```
-{"EventName":"s3:ObjectCreated:Put","Key":"images/gopher.jpg","Records":[{"eventVersion":"2.0","eventSource":"minio:s3","awsRegion":"","eventTime":"2018-10-31T09:31:11Z","eventName":"s3:ObjectCreated:Put","userIdentity":{"principalId":"21EJ9HYV110O8NVX2VMS"},"requestParameters":{"sourceIPAddress":"10.1.1.1"},"responseElements":{"x-amz-request-id":"1562A792DAA53426","x-minio-origin-endpoint":"http://10.0.3.1:9000"},"s3":{"s3SchemaVersion":"1.0","configurationId":"Config","bucket":{"name":"images","ownerIdentity":{"principalId":"21EJ9HYV110O8NVX2VMS"},"arn":"arn:aws:s3:::images"},"object":{"key":"gopher.jpg","size":162023,"eTag":"5337769ffa594e742408ad3f30713cd7","contentType":"image/jpeg","userMetadata":{"content-type":"image/jpeg"},"versionId":"1","sequencer":"1562A792DAA53426"}},"source":{"host":"","port":"","userAgent":"MinIO (linux; amd64) minio-go/v6.0.8 mc/DEVELOPMENT.GOGET"}}]}
+{"EventName":"s3:ObjectCreated:Put","Key":"images/gopher.jpg","Records":[{"eventVersion":"2.0","eventSource":"minio:s3","awsRegion":"","eventTime":"2018-10-31T09:31:11Z","eventName":"s3:ObjectCreated:Put","userIdentity":{"principalId":"21EJ9HYV110O8NVX2VMS"},"requestParameters":{"sourceIPAddress":"10.1.1.1"},"responseElements":{"x-amz-request-id":"1562A792DAA53426","x-minio-origin-endpoint":"http://10.0.3.1:9000"},"s3":{"s3SchemaVersion":"1.0","configurationId":"Config","bucket":{"name":"images","ownerIdentity":{"principalId":"21EJ9HYV110O8NVX2VMS"},"arn":"arn:aws:s3:::images"},"object":{"key":"gopher.jpg","size":162023,"eTag":"5337769ffa594e742408ad3f30713cd7","contentType":"image/jpeg","userMetadata":{"content-type":"image/jpeg"},"versionId":"1","sequencer":"1562A792DAA53426"}},"source":{"host":"","port":"","userAgent":"Silo (linux; amd64) minio-go/v6.0.8 mc/DEVELOPMENT.GOGET"}}]}
 ```

docs/bucket/quota/README.md

@@ -1,4 +1,4 @@
-# Bucket Quota Configuration Quickstart 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/)
+# Bucket Quota Configuration Quickstart Guide [![Docker Pulls](https://img.shields.io/docker/pulls/pgsty/silo.svg?maxAge=604800)](https://hub.docker.com/r/pgsty/silo/)
 
 ![quota](https://raw.githubusercontent.com/pgsty/minio/master/docs/bucket/quota/bucketquota.png)
 
@@ -6,25 +6,25 @@ Buckets can be configured to have `Hard` quota - it disallows writes to the buck
 
 ## Prerequisites
 
-- Install MinIO - [MinIO Quickstart Guide](https://silo.pgsty.com/operations/deployments/baremetal-deploy-minio-on-redhat-linux/#procedure).
+- Install Silo - [Silo Quickstart Guide](https://silo.pgsty.com/operations/deployments/baremetal-deploy-minio-on-redhat-linux/#procedure).
-- [Use `mc` with MinIO Server](https://silo.pgsty.com/reference/minio-mc/#quickstart)
+- [Use `mc` with Silo Server](https://silo.pgsty.com/reference/minio-mc/#quickstart)
 
 ## Set bucket quota configuration
 
-### Set a hard quota of 1GB for a bucket `mybucket` on MinIO object storage
+### Set a hard quota of 1GB for a bucket `mybucket` on Silo object storage
 
 ```sh
-mc admin bucket quota myminio/mybucket --hard 1gb
+mc admin bucket quota mysilo/mybucket --hard 1gb
 ```
 
-### Verify the quota configured on `mybucket` on MinIO
+### Verify the quota configured on `mybucket` on Silo
 
 ```sh
-mc admin bucket quota myminio/mybucket
+mc admin bucket quota mysilo/mybucket
 ```
 
-### Clear bucket quota configuration for `mybucket` on MinIO
+### Clear bucket quota configuration for `mybucket` on Silo
 
 ```sh
-mc admin bucket quota myminio/mybucket --clear
+mc admin bucket quota mysilo/mybucket --clear
 ```

docs/bucket/replication/DESIGN.md

@@ -1,4 +1,4 @@
-# Bucket Replication Design [![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/)
+# Bucket Replication Design [![Docker Pulls](https://img.shields.io/docker/pulls/pgsty/silo.svg?maxAge=604800)](https://hub.docker.com/r/pgsty/silo/)
 
 This document explains the design approach of server side bucket replication. If you're looking to get started with replication, we suggest you go through the [Bucket replication guide](https://github.com/pgsty/minio/blob/master/docs/bucket/replication/README.md) first.
 
@@ -12,13 +12,13 @@ If an object meets replication rules as set in the replication configuration, `X
 
 All replication failures are picked up by the scanner which runs at a one minute frequency, each time scanning up to a sixteenth of the namespace. Object versions marked `PENDING` or `FAILED` are re-queued for replication.
 
-Replication speed depends on the cluster load, number of objects in the object store as well as storage speed. In addition, any bandwidth limits set via `mc admin bucket remote add` could also contribute to replication speed. The number of workers used for replication defaults to 100. Based on network bandwidth and system load, the number of workers used in replication can be configured using `mc admin config set alias api` to set the `replication_workers`. The prometheus metrics exposed by MinIO can be used to plan resource allocation and bandwidth management to optimize replication speed.
+Replication speed depends on the cluster load, number of objects in the object store as well as storage speed. In addition, any bandwidth limits set via `mc admin bucket remote add` could also contribute to replication speed. The number of workers used for replication defaults to 100. Based on network bandwidth and system load, the number of workers used in replication can be configured using `mc admin config set alias api` to set the `replication_workers`. The prometheus metrics exposed by Silo can be used to plan resource allocation and bandwidth management to optimize replication speed.
 
 If synchronous replication is configured above, replication is attempted right away prior to returning the PUT object response. In the event that the replication target is down, the `X-Amz-Replication-Status` is marked as `FAILED` and resynced with target when the scanner runs again.
 
 Any metadata changes on the source object version, such as metadata updates via PutObjectTagging, PutObjectRetention, PutObjectLegalHold and COPY api are replicated in a similar manner to target version, with the `X-Amz-Replication-Status` again cycling through the same states.
 
-The description above details one way replication from source to target w.r.t incoming object uploads and metadata changes to source object version. If active-active replication is configured, any incoming uploads and metadata changes to versions created on the target, will sync back to the source and be marked as `REPLICA` on the source. AWS, as well as MinIO do not by default sync metadata changes on a object version marked `REPLICA` back to source. This requires a setting in the replication configuration called [replica modification sync](https://aws.amazon.com/about-aws/whats-new/2020/12/amazon-s3-replication-adds-support-two-way-replication/).
+The description above details one way replication from source to target w.r.t incoming object uploads and metadata changes to source object version. If active-active replication is configured, any incoming uploads and metadata changes to versions created on the target, will sync back to the source and be marked as `REPLICA` on the source. AWS, as well as Silo do not by default sync metadata changes on a object version marked `REPLICA` back to source. This requires a setting in the replication configuration called [replica modification sync](https://aws.amazon.com/about-aws/whats-new/2020/12/amazon-s3-replication-adds-support-two-way-replication/).
 
 For active-active replication, automatic failover occurs on `GET/HEAD` operations if object or object version requested qualifies for replication and is missing on one site, but present on the other. This allows the applications to take full advantage of two-way replication even before the two sites get fully synced.
 
@@ -26,7 +26,7 @@ In the case of multi destination replication, the replication status shows `COMP
 
 ### Replication of DeleteMarker and versioned Delete
 
-MinIO allows DeleteMarker replication and versioned delete replication by setting `--replicate delete,delete-marker` while setting up replication configuration using `mc replicate add`. The MinIO implementation is based on V2 configuration, however it has been extended to allow both DeleteMarker replication and replication of versioned deletes with the `DeleteMarkerReplication` and `DeleteReplication` fields in the replication configuration. By default, this is set to `Disabled` unless the user specifies it while adding a replication rule.
+Silo allows DeleteMarker replication and versioned delete replication by setting `--replicate delete,delete-marker` while setting up replication configuration using `mc replicate add`. The Silo implementation is based on V2 configuration, however it has been extended to allow both DeleteMarker replication and replication of versioned deletes with the `DeleteMarkerReplication` and `DeleteReplication` fields in the replication configuration. By default, this is set to `Disabled` unless the user specifies it while adding a replication rule.
 
 Similar to object version replication, DeleteMarker replication also cycles through `PENDING` to `COMPLETED` or `FAILED` states for the `X-Amz-Replication-Status` on the source when a delete marker is set (i.e. performing `mc rm` on an object without specifying a version).After replication syncs the delete marker on the target, the DeleteMarker on the target shows `X-Amz-Replication-Status` of `REPLICA`. The status of DeleteMarker replication is returned by `X-Minio-Replication-DeleteMarker-Status` header on `HEAD/GET` calls for the delete marker version in question - i.e with `mc stat --version-id dm-version-id`
 
@@ -156,5 +156,5 @@ If 3 or more targets are participating in active-active replication, the replica
 
 ## Explore Further
 
-- [MinIO Bucket Versioning Implementation](https://silo.pgsty.com/administration/object-management/object-versioning/)
+- [Silo Bucket Versioning Implementation](https://silo.pgsty.com/administration/object-management/object-versioning/)
-- [MinIO Client Quickstart Guide](https://silo.pgsty.com/reference/minio-mc/#quickstart)
+- [Silo Client Quickstart Guide](https://silo.pgsty.com/reference/minio-mc/#quickstart)

docs/bucket/replication/README.md

@@ -1,16 +1,16 @@
-# Bucket Replication 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/)
+# Bucket Replication Guide [![Docker Pulls](https://img.shields.io/docker/pulls/pgsty/silo.svg?maxAge=604800)](https://hub.docker.com/r/pgsty/silo/)
 
 Bucket replication is designed to replicate selected objects in a bucket to a destination bucket.
 
-The contents of this page have been migrated to the new [MinIO Documentation: Bucket Replication](https://silo.pgsty.com/administration/bucket-replication/) page. The [Bucket Replication](https://silo.pgsty.com/administration/bucket-replication/bucket-replication-requirements/) page references dedicated tutorials for configuring one-way "Active-Passive" and two-way "Active-Active" bucket replication.
+The contents of this page have been migrated to the new [Silo Documentation: Bucket Replication](https://silo.pgsty.com/administration/bucket-replication/) page. The [Bucket Replication](https://silo.pgsty.com/administration/bucket-replication/bucket-replication-requirements/) page references dedicated tutorials for configuring one-way "Active-Passive" and two-way "Active-Active" bucket replication.
 
-To replicate objects in a bucket to a destination bucket on a target site either in the same cluster or a different cluster, start by enabling [versioning](https://silo.pgsty.com/administration/object-management/object-versioning/) for both source and destination buckets. Finally, the target site and the destination bucket need to be configured on the source MinIO server.
+To replicate objects in a bucket to a destination bucket on a target site either in the same cluster or a different cluster, start by enabling [versioning](https://silo.pgsty.com/administration/object-management/object-versioning/) for both source and destination buckets. Finally, the target site and the destination bucket need to be configured on the source Silo server.
 
 ## Highlights
 
 - Supports source and destination buckets to have the same name unlike AWS S3, addresses variety of use-cases such as *Splunk*, *Veeam* site to site DR.
 - Supports object locking/retention across source and destination buckets natively out of the box, unlike AWS S3.
-- Simpler implementation than [AWS S3 Bucket Replication Config](https://docs.aws.amazon.com/AmazonS3/latest/dev/replication-add-config.html) with requirements such as IAM Role, AccessControlTranslation, Metrics and SourceSelectionCriteria are not needed with MinIO.
+- Simpler implementation than [AWS S3 Bucket Replication Config](https://docs.aws.amazon.com/AmazonS3/latest/dev/replication-add-config.html) with requirements such as IAM Role, AccessControlTranslation, Metrics and SourceSelectionCriteria are not needed with Silo.
 - Active-Active replication
 - Multi destination replication
 
@@ -96,21 +96,22 @@ The access key provided for the replication *target* cluster should have these m
 
 Please note that the permissions required by the admin user on the target cluster can be more fine grained to exclude permissions like "s3:ReplicateDelete", "s3:GetBucketObjectLockConfiguration" etc depending on whether delete replication rules are set up or if object locking is disabled on `destbucket`. The above policies assume that replication of objects, tags and delete marker replication are all enabled on object lock enabled buckets. A sample script to setup replication is provided [here](https://github.com/pgsty/minio/blob/master/docs/bucket/replication/setup_replication.sh)
 
-To set up replication from a source bucket `srcbucket` on myminio cluster to a bucket `destbucket` on the target minio cluster with endpoint https://replica-endpoint:9000, use:
+To set up replication from `srcbucket` on the `mysilo` cluster to `destbucket`
+on a target Silo cluster at `https://replica-endpoint:9000`, use:
 ```
-mc replicate add myminio/srcbucket --priority 1 --remote-bucket https://accessKey:secretKey@replica-endpoint:9000/destbucket 
+mc replicate add mysilo/srcbucket --priority 1 --remote-bucket https://accessKey:secretKey@replica-endpoint:9000/destbucket
-Replication configuration applied successfully to myminio/srcbucket.
+Replication configuration applied successfully to mysilo/srcbucket.
 ```
-Internally, this creates an ARN for the remote target associating the remote bucket as a replication target to the srcbucket on myminio.By default, if --replicate flag is not specified, replication of delete marker, permanent deletes, existing object replication and replica modification sync are all enabled. If you are using older mc versions, the ARN needs to be generated as a separate step before adding a replication rule.
+Internally, this creates an ARN for the remote target associating the remote bucket as a replication target to the srcbucket on mysilo.By default, if --replicate flag is not specified, replication of delete marker, permanent deletes, existing object replication and replica modification sync are all enabled. If you are using older mc versions, the ARN needs to be generated as a separate step before adding a replication rule.
 
 > NOTE: If you are using a mc version below `RELEASE.2022-12-24T15-21-38Z`, the --remote-bucket flag needs an ARN generated by `mc admin bucket remote add` command. For  mc versions RELEASE.2021-09-02T09-21-27Z and older, the remote target ARN needs to be passed in the --arn flag and actual remote bucket name in --remote-bucket flag of  `mc replicate add`. For example, in older releases of mc replication configuration used to be added with:
 
 ```
-mc admin bucket remote add myminio/srcbucket https://accessKey:secretKey@replica-endpoint:9000/destbucket --service replication --region us-east-1
+mc admin bucket remote add mysilo/srcbucket https://accessKey:secretKey@replica-endpoint:9000/destbucket --service replication --region us-east-1
 Remote ARN = 'arn:minio:replication:us-east-1:c5be6b16-769d-432a-9ef1-4567081f3566:destbucket'
 
-mc replicate add myminio/srcbucket/Tax --priority 1 --remote-bucket destbucket --remote-bucket "arn:minio:replication:us-east-1:c5be6b16-769d-432a-9ef1-4567081f3566:destbucket" --tags "Year=2019&Company=AcmeCorp" --storage-class "STANDARD" --replicate "delete,delete-marker"
+mc replicate add mysilo/srcbucket/Tax --priority 1 --remote-bucket destbucket --remote-bucket "arn:minio:replication:us-east-1:c5be6b16-769d-432a-9ef1-4567081f3566:destbucket" --tags "Year=2019&Company=AcmeCorp" --storage-class "STANDARD" --replicate "delete,delete-marker"
-Replication configuration applied successfully to myminio/srcbucket.
+Replication configuration applied successfully to mysilo/srcbucket.
 ```
 
 The replication configuration generated has the following format and can be exported with `mc replicate export` command:
@@ -153,7 +154,7 @@ The replication configuration generated has the following format and can be expo
 }
 ```
 
-The replication configuration follows [AWS S3 Spec](https://docs.aws.amazon.com/AmazonS3/latest/dev/replication-add-config.html). Any objects uploaded to the source bucket that meet replication criteria will now be automatically replicated by the MinIO server to the remote destination bucket. Replication can be disabled at any time by disabling specific rules in the configuration or deleting the replication configuration entirely.
+The replication configuration follows [AWS S3 Spec](https://docs.aws.amazon.com/AmazonS3/latest/dev/replication-add-config.html). Any objects uploaded to the source bucket that meet replication criteria will now be automatically replicated by the Silo server to the remote destination bucket. Replication can be disabled at any time by disabling specific rules in the configuration or deleting the replication configuration entirely.
 
 When object locking is used in conjunction with replication, both source and destination buckets needs to have [object locking](https://silo.pgsty.com/administration/object-management/object-retention/) enabled. Similarly objects encrypted on the server side, will be replicated if destination also supports encryption.
 
@@ -167,7 +168,7 @@ To perform bi-directional replication, repeat the above process on the target si
 
 ## Replica Modification sync
 
-If bi-directional replication is set up between two clusters, any metadata update on the REPLICA object is by default reflected back in the source object when `ReplicaModifications` status in the `SourceSelectionCriteria` is `Enabled`. In MinIO, this is enabled by default. If a metadata update is performed on the "REPLICA" object, its `X-Amz-Replication-Status` will change from `PENDING` to `COMPLETE` or `FAILED`, and the source object version will show `X-Amz-Replication-Status` of `REPLICA` once the replication operation is complete.
+If bi-directional replication is set up between two clusters, any metadata update on the REPLICA object is by default reflected back in the source object when `ReplicaModifications` status in the `SourceSelectionCriteria` is `Enabled`. In Silo, this is enabled by default. If a metadata update is performed on the "REPLICA" object, its `X-Amz-Replication-Status` will change from `PENDING` to `COMPLETE` or `FAILED`, and the source object version will show `X-Amz-Replication-Status` of `REPLICA` once the replication operation is complete.
 
 The replication configuration in use on a bucket can be viewed using the `mc replicate export alias/bucket` command.
 
@@ -183,25 +184,25 @@ To re-enable replica metadata modification syncing,
 mc replicate edit alias/bucket --id xyz.id --replicate "delete,delete-marker,replica-metadata-sync"
 ```
 
-## MinIO Extension
+## Silo Extension
 
 ### Replicating Deletes
 
-Delete marker replication is allowed in [AWS V1 Configuration](https://aws.amazon.com/blogs/storage/managing-delete-marker-replication-in-amazon-s3/) but not in V2 configuration. The MinIO implementation above is based on V2 configuration, however it has been extended to allow both DeleteMarker replication and replication of versioned deletes with the `DeleteMarkerReplication` and `DeleteReplication` fields in the replication configuration above. By default, this is set to `Disabled` unless the user specifies it while adding a replication rule.
+Delete marker replication is allowed in [AWS V1 Configuration](https://aws.amazon.com/blogs/storage/managing-delete-marker-replication-in-amazon-s3/) but not in V2 configuration. The Silo implementation above is based on V2 configuration, however it has been extended to allow both DeleteMarker replication and replication of versioned deletes with the `DeleteMarkerReplication` and `DeleteReplication` fields in the replication configuration above. By default, this is set to `Disabled` unless the user specifies it while adding a replication rule.
 
-When an object is deleted from the source bucket, the corresponding replica version will be marked deleted if delete marker replication is enabled in the replication configuration. Replication of deletes that specify a version id (a.k.a hard deletes) can be enabled by setting the `DeleteReplication` status to enabled in the replication configuration. This is a MinIO specific extension that can be enabled using the `mc replicate add` or `mc replicate edit` command with the --replicate "delete" flag.
+When an object is deleted from the source bucket, the corresponding replica version will be marked deleted if delete marker replication is enabled in the replication configuration. Replication of deletes that specify a version id (a.k.a hard deletes) can be enabled by setting the `DeleteReplication` status to enabled in the replication configuration. This is a Silo specific extension that can be enabled using the `mc replicate add` or `mc replicate edit` command with the --replicate "delete" flag.
 
 Note that due to this extension behavior, AWS SDK's may not support the extension functionality pertaining to replicating versioned deletes.
 
-Note that just like with [AWS](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-marker-replication.html), Delete marker replication is disallowed in MinIO when the replication rule has tags.
+Note that just like with [AWS](https://docs.aws.amazon.com/AmazonS3/latest/userguide/delete-marker-replication.html), Delete marker replication is disallowed in Silo when the replication rule has tags.
 
 To add a replication rule allowing both delete marker replication, versioned delete replication or both specify the --replicate flag with comma separated values as in the example below.
 
 Additional permission of "s3:ReplicateDelete" action would need to be specified on the access key configured for the target cluster if Delete Marker replication or versioned delete replication is enabled.
 
 ```
-mc replicate add myminio/srcbucket/Tax --priority 1 --remote-bucket `remote-target` --tags "Year=2019&Company=AcmeCorp" --storage-class "STANDARD" --replicate "delete,delete-marker"
+mc replicate add mysilo/srcbucket/Tax --priority 1 --remote-bucket `remote-target` --tags "Year=2019&Company=AcmeCorp" --storage-class "STANDARD" --replicate "delete,delete-marker"
-Replication configuration applied successfully to myminio/srcbucket.
+Replication configuration applied successfully to mysilo/srcbucket.
 ```
 
 > NOTE: In mc versions `RELEASE.2022-12-24T15-21-38Z` and above `remote-target`  should be of the format `https://accessKey:secretKey@replica-endpoint:9000/destbucket` which earlier used to be set during `mc admin bucket remote add`. For older releases, use the arn generated with `mc admin bucket remote add` command - e.g."arn:minio:replication:us-east-1:c5be6b16-769d-432a-9ef1-4567081f3566:destbucket" as the `remote-target`.
@@ -223,7 +224,7 @@ remote replication target using the `mc admin bucket remote add` command. For mc
 --sync, --health-check and --bandwidth flags can be specified in `mc replicate add|update` command
 
 ```
- mc admin bucket remote add myminio/srcbucket https://accessKey:secretKey@replica-endpoint:9000/destbucket --service replication --region us-east-1 --sync --healthcheck-seconds 100
+ mc admin bucket remote add mysilo/srcbucket https://accessKey:secretKey@replica-endpoint:9000/destbucket --service replication --region us-east-1 --sync --healthcheck-seconds 100
 ```
 
 ### Existing object replication
@@ -266,16 +267,16 @@ In the above sample config, objects under prefixes matching any of the `Excluded
 
 ### SSE-C Encryption
 
-MinIO does not support SSE-C encrypted objects on replicated buckets, any application uploading SSE-C encrypted objects will be rejected with an error on replicated buckets.
+Silo does not support SSE-C encrypted objects on replicated buckets, any application uploading SSE-C encrypted objects will be rejected with an error on replicated buckets.
 
 #### Rationale
 
 - SSE-C requires application to remember the keys for all GET/PUT operations, any unfortunate loss of keys would automatically mean the objects cannot be accessed anymore.
 - SSE-C is hardly adopted by most widely used applications, applications prefer server to manage the keys via SSE-KMS or SSE-S3.
-- MinIO recommends applications to use SSE-KMS, SSE-S3 for simpler, safer and robust encryption mechanism for replicated buckets.
+- Silo recommends applications to use SSE-KMS, SSE-S3 for simpler, safer and robust encryption mechanism for replicated buckets.
 
 ## Explore Further
 
-- [MinIO Bucket Replication Design](https://github.com/pgsty/minio/blob/master/docs/bucket/replication/DESIGN.md)
+- [Silo Bucket Replication Design](https://github.com/pgsty/minio/blob/master/docs/bucket/replication/DESIGN.md)
-- [MinIO Bucket Versioning Implementation](https://silo.pgsty.com/administration/object-management/object-retention/)
+- [Silo Bucket Versioning Implementation](https://silo.pgsty.com/administration/object-management/object-retention/)
-- [MinIO Client Quickstart Guide](https://silo.pgsty.com/reference/minio-mc/#quickstart)
+- [Silo Client Quickstart Guide](https://silo.pgsty.com/reference/minio-mc/#quickstart)

docs/bucket/retention/README.md

@@ -1,6 +1,6 @@
-# Object Lock and Immutability Guide [![Slack](https://slack.min.io/slack?type=svg)](https://slack.min.io)
+# Object Lock and Immutability Guide
 
-MinIO server allows WORM for specific objects or by configuring a bucket with default object lock configuration that applies default retention mode and retention duration to all objects. This makes objects in the bucket immutable i.e. delete of the version are not allowed until an expiry specified in the bucket's object lock configuration or object retention.
+Silo server allows WORM for specific objects or by configuring a bucket with default object lock configuration that applies default retention mode and retention duration to all objects. This makes objects in the bucket immutable i.e. delete of the version are not allowed until an expiry specified in the bucket's object lock configuration or object retention.
 
 Object locking requires locking to be enabled on a bucket at the time of bucket creation refer to `mc mb --with-lock`, object locking enables versioning on the bucket and cannot be disabled.
 
@@ -10,7 +10,7 @@ A default retention period and retention mode can be configured on a bucket to b
 
 ### 1. Prerequisites
 
-- Install MinIO - [MinIO Quickstart Guide](https://silo.pgsty.com/operations/deployments/baremetal-deploy-minio-on-redhat-linux/)
+- Install Silo - [Silo Quickstart Guide](https://silo.pgsty.com/operations/deployments/baremetal-deploy-minio-on-redhat-linux/)
 - Install `awscli` - [Installing AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)
 
 ### 2. Set bucket WORM configuration
@@ -53,7 +53,7 @@ See <https://docs.aws.amazon.com/AmazonS3/latest/dev/object-lock-overview.html>
 
 ## Explore Further
 
-- [Use `mc` with MinIO Server](https://silo.pgsty.com/reference/minio-mc/#quickstart)
+- [Use `mc` with Silo Server](https://silo.pgsty.com/reference/minio-mc/#quickstart)
-- [Use `aws-cli` with MinIO Server](https://silo.pgsty.com/integrations/aws-cli-with-minio/)
+- [Use `aws-cli` with Silo Server](https://silo.pgsty.com/integrations/aws-cli-with-minio/)
-- [Use `minio-go` SDK with MinIO Server](https://silo.pgsty.com/developers/go/minio-go/)
+- [Use `minio-go` SDK with Silo Server](https://silo.pgsty.com/developers/go/minio-go/)
-- [The MinIO documentation website](https://silo.pgsty.com/docs/)
+- [The Silo documentation website](https://silo.pgsty.com/docs/)

docs/bucket/versioning/DESIGN.md

@@ -1,8 +1,8 @@
-# Bucket Versioning Design 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/)
+# Bucket Versioning Design Guide [![Docker Pulls](https://img.shields.io/docker/pulls/pgsty/silo.svg?maxAge=604800)](https://hub.docker.com/r/pgsty/silo/)
 
 ## Description of `xl.meta`
 
-`xl.meta` is a new self describing backend format used by MinIO to support AWS S3 compatible versioning.
+`xl.meta` is a new self describing backend format used by Silo to support AWS S3 compatible versioning.
 This file is the source of truth for each `version` at rest. `xl.meta` is a msgpack file serialized from a
 well defined data structure. To understand `xl.meta` here are the few things to start with
 

docs/bucket/versioning/README.md

@@ -1,20 +1,20 @@
-# Bucket Versioning 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/)
+# Bucket Versioning Guide [![Docker Pulls](https://img.shields.io/docker/pulls/pgsty/silo.svg?maxAge=604800)](https://hub.docker.com/r/pgsty/silo/)
 
-MinIO versioning is designed to keep multiple versions of an object in one bucket. For example, you could store `spark.csv` (version `ede336f2`) and `spark.csv` (version `fae684da`) in a single bucket. Versioning protects you from unintended overwrites, deletions, protect objects with retention policies.
+Silo versioning is designed to keep multiple versions of an object in one bucket. For example, you could store `spark.csv` (version `ede336f2`) and `spark.csv` (version `fae684da`) in a single bucket. Versioning protects you from unintended overwrites, deletions, protect objects with retention policies.
 
 To control data retention and storage usage, use object versioning with [object lifecycle management](https://github.com/pgsty/minio/blob/master/docs/bucket/lifecycle/README.md).  If you have an object expiration lifecycle policy in your non-versioned bucket and you want to maintain the same permanent delete behavior when on versioning-enabled bucket, you must add a noncurrent expiration policy. The noncurrent expiration lifecycle policy will manage the deletes of the noncurrent object versions in the versioning-enabled bucket. (A version-enabled bucket maintains one current and zero or more noncurrent object versions.)
 
 Versioning must be explicitly enabled on a bucket, versioning is not enabled by default. Object locking enabled buckets have versioning enabled automatically. Enabling and suspending versioning is done at the bucket level.
 
-Only MinIO generates version IDs, and they can't be edited. Version IDs are simply of `DCE 1.1 v4 UUID 4` (random data based), UUIDs are 128 bit numbers which are intended to have a high likelihood of uniqueness over space and time and are computationally difficult to guess. They are globally unique identifiers which can be locally generated without contacting a global registration authority. UUIDs are intended as unique identifiers for both mass tagging objects with an extremely short lifetime and to reliably identifying very persistent objects across a network.
+Only Silo generates version IDs, and they can't be edited. Version IDs are simply of `DCE 1.1 v4 UUID 4` (random data based), UUIDs are 128 bit numbers which are intended to have a high likelihood of uniqueness over space and time and are computationally difficult to guess. They are globally unique identifiers which can be locally generated without contacting a global registration authority. UUIDs are intended as unique identifiers for both mass tagging objects with an extremely short lifetime and to reliably identifying very persistent objects across a network.
 
-When you PUT an object in a versioning-enabled bucket, the noncurrent version is not overwritten. The following figure shows that when a new version of `spark.csv` is PUT into a bucket that already contains an object with the same name, the original object (ID = `ede336f2`) remains in the bucket, MinIO generates a new version (ID = `fae684da`), and adds the newer version to the bucket.
+When you PUT an object in a versioning-enabled bucket, the noncurrent version is not overwritten. The following figure shows that when a new version of `spark.csv` is PUT into a bucket that already contains an object with the same name, the original object (ID = `ede336f2`) remains in the bucket, Silo generates a new version (ID = `fae684da`), and adds the newer version to the bucket.
 
 ![put](https://raw.githubusercontent.com/pgsty/minio/master/docs/bucket/versioning/versioning_PUT_versionEnabled.png)
 
 This protects against accidental overwrites or deletes of objects, allows previous versions to be retrieved.
 
-When you DELETE an object, all versions remain in the bucket and MinIO adds a delete marker, as shown below:
+When you DELETE an object, all versions remain in the bucket and Silo adds a delete marker, as shown below:
 
 ![delete](https://raw.githubusercontent.com/pgsty/minio/master/docs/bucket/versioning/versioning_DELETE_versionEnabled.png)
 
@@ -32,7 +32,7 @@ To permanently delete an object you need to specify the version you want to dele
 
 ## Concepts
 
-- All Buckets on MinIO are always in one of the following states: unversioned (the default) and all other existing deployments, versioning-enabled, or versioning-suspended.
+- All Buckets on Silo are always in one of the following states: unversioned (the default) and all other existing deployments, versioning-enabled, or versioning-suspended.
 - Versioning state applies to all of the objects in the versioning enabled bucket. The first time you enable a bucket for versioning, objects in the bucket are thereafter always versioned and given a unique version ID.
 - Existing or newer buckets can be created with versioning enabled and eventually can be suspended as well. Existing versions of objects stay as is and can still be accessed using the version ID.
 - All versions, including delete-markers should be deleted before deleting a bucket.
@@ -47,7 +47,7 @@ Each bucket created has a versioning configuration associated with it. By defaul
 </VersioningConfiguration>
 ```
 
-To enable versioning, you send a request to MinIO with a versioning configuration with Status set to `Enabled`.
+To enable versioning, you send a request to Silo with a versioning configuration with Status set to `Enabled`.
 
 ```
 <VersioningConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
@@ -63,7 +63,7 @@ Similarly to suspend versioning set the configuration with Status set to `Suspen
 </VersioningConfiguration>
 ```
 
-## MinIO extension to Bucket Versioning
+## Silo extension to Bucket Versioning
 
 ### Idempotent versions on directory objects
 
@@ -73,13 +73,15 @@ All directory objects such as objects that end with `/`, will only have one vers
 
 ### Idempotent versions on delete markers
 
-Duplicate delete markers are not created on MinIO buckets with versioning, if an application performs a soft delete on an object repeatedly - that object will only ever have a single DELETE marker for all such successive attempts. This is done to ensure that repeated soft deletes do not ever need multiple versions in the first place.
+Duplicate delete markers are not created on Silo buckets with versioning, if an application performs a soft delete on an object repeatedly - that object will only ever have a single DELETE marker for all such successive attempts. This is done to ensure that repeated soft deletes do not ever need multiple versions in the first place.
 
 > NOTE: Server side replication is supported for idempotent versions on delete marked objects.
 
 ### Motivation
 
-**PLEASE READ: This feature is meant for advanced use-cases only where the setup is using bucket versioning or with replicated buckets, use this feature to optimize versioning behavior for some specific applications. MinIO experts will evaluate and guide on the benefits for your application, please reach out to us on <https://subnet.min.io>.**
+**PLEASE READ:** This advanced behavior is intended for carefully evaluated
+versioned or replicated workloads. Validate its lifecycle and replication
+effects in a staging environment before enabling it in production.
 
 Spark/Hadoop workloads which use Hadoop MR Committer v1/v2 algorithm upload objects to a temporary prefix in a bucket. These objects are 'renamed' to a different prefix on Job commit. Object storage admins are forced to configure separate ILM policies to expire these objects and their versions to reclaim space.
 
@@ -110,7 +112,7 @@ To exclude objects under a list of prefix (glob) patterns from being versioned,
 - Objects matching these prefixes will also not leave `null` delete markers, dramatically reduces namespace pollution while keeping the benefits of replication.
 - Users with explicit permissions or the root credential can configure the versioning state of any bucket.
 
-## Examples of enabling bucket versioning using MinIO Java SDK
+## Examples using the MinIO Java SDK compatibility client
 
 ### EnableVersioning() API
 
@@ -127,11 +129,11 @@ public class EnableVersioning {
   public static void main(String[] args)
       throws IOException, NoSuchAlgorithmException, InvalidKeyException {
     try {
-      /* play.min.io for test and development. */
+      /* Local Silo endpoint for test and development. */
       MinioClient minioClient =
           MinioClient.builder()
-              .endpoint("https://play.min.io")
+              .endpoint("http://127.0.0.1:9000")
-              .credentials("Q3AM3UQ867SPQQA43P2F", "zuf+tfteSlswRu7BJ86wekitnifILbZam1KYY3TG")
+              .credentials("YOUR-ACCESS-KEY", "YOUR-SECRET-KEY")
               .build();
 
       /* Amazon S3: */
@@ -161,11 +163,11 @@ public class IsVersioningEnabled {
   public static void main(String[] args)
       throws IOException, NoSuchAlgorithmException, InvalidKeyException {
     try {
-      /* play.min.io for test and development. */
+      /* Local Silo endpoint for test and development. */
       MinioClient minioClient =
           MinioClient.builder()
-              .endpoint("https://play.min.io")
+              .endpoint("http://127.0.0.1:9000")
-              .credentials("Q3AM3UQ867SPQQA43P2F", "zuf+tfteSlswRu7BJ86wekitnifILbZam1KYY3TG")
+              .credentials("YOUR-ACCESS-KEY", "YOUR-SECRET-KEY")
               .build();
 
       /* Amazon S3: */
@@ -211,7 +213,7 @@ public class IsVersioningEnabled {
 
 ## Explore Further
 
-- [Use `minio-java` SDK with MinIO Server](https://silo.pgsty.com/developers/java/minio-java/)
+- [Use `minio-java` SDK with Silo Server](https://silo.pgsty.com/developers/java/minio-java/)
 - [Object Lock and Immutability Guide](https://silo.pgsty.com/administration/object-management/object-retention/)
-- [MinIO Admin Complete Guide](https://silo.pgsty.com/reference/minio-mc-admin/)
+- [Silo Admin Complete Guide](https://silo.pgsty.com/reference/minio-mc-admin/)
-- [The MinIO documentation website](https://silo.pgsty.com/docs/)
+- [The Silo documentation website](https://silo.pgsty.com/docs/)

docs/chroot/README.md

@@ -1,4 +1,4 @@
-# Deploy MinIO on Chrooted Environment [![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/)
+# Deploy Silo on Chrooted Environment [![Docker Pulls](https://img.shields.io/docker/pulls/pgsty/silo.svg?maxAge=604800)](https://hub.docker.com/r/pgsty/silo/)
 
 Chroot allows user based namespace isolation on many standard Linux deployments.
 
@@ -7,25 +7,24 @@ Chroot allows user based namespace isolation on many standard Linux deployments.
 - Familiarity with [chroot](http://man7.org/linux/man-pages/man2/chroot.2.html)
 - Chroot installed on your machine.
 
-## 2. Install MinIO in Chroot
+## 2. Install Silo in Chroot
 
-> **Note:** MinIO community edition is now distributed as source code only. Pre-compiled binaries are no longer provided for new releases.
+Build Silo from source and install it in the chroot directory:
-
-Build MinIO from source and install it in the chroot directory:
 
 ```sh
-# Build MinIO from source
+# From a checked-out Silo source tree
-go install github.com/minio/minio@latest
+go build -o silo .
 
 # Create the bin directory in your chroot
 mkdir -p /mnt/export/${USER}/bin
 
 # Copy the built binary to the chroot directory
-cp $(go env GOPATH)/bin/minio /mnt/export/${USER}/bin/minio
+cp ./silo /mnt/export/${USER}/bin/silo
-chmod +x /mnt/export/${USER}/bin/minio
+chmod +x /mnt/export/${USER}/bin/silo
 ```
 
-Alternatively, if you have an existing legacy binary, you can still use it, but note that it will not receive updates.
+Versioned binaries and native packages are also available from the
+[Silo download page](https://silo.pgsty.com/download/).
 
 Bind your `proc` mount to the target chroot directory
 
@@ -33,12 +32,12 @@ Bind your `proc` mount to the target chroot directory
 sudo mount --bind /proc /mnt/export/${USER}/proc
 ```
 
-## 3. Run Standalone MinIO in Chroot
+## 3. Run Standalone Silo in Chroot
 
 ### GNU/Linux
 
 ```sh
-sudo chroot --userspec username:group /mnt/export/${USER} /bin/minio --config-dir=/.minio server /data
+sudo chroot --userspec username:group /mnt/export/${USER} /bin/silo --config-dir=/.silo server /data
 
 Endpoint:  http://192.168.1.92:9000  http://65.19.167.92:9000
 AccessKey: MVPSPBW4NP2CMV1W3TXD
@@ -51,8 +50,8 @@ Instance is now accessible on the host at port 9000, proceed to access the Web b
 
 ## Explore Further
 
-- [MinIO Erasure Code Overview](https://silo.pgsty.com/operations/concepts/erasure-coding/)
+- [Silo Erasure Code Overview](https://silo.pgsty.com/operations/concepts/erasure-coding/)
-- [Use `mc` with MinIO Server](https://silo.pgsty.com/reference/minio-mc/)
+- [Use `mc` with Silo Server](https://silo.pgsty.com/reference/minio-mc/)
-- [Use `aws-cli` with MinIO Server](https://silo.pgsty.com/integrations/aws-cli-with-minio/)
+- [Use `aws-cli` with Silo Server](https://silo.pgsty.com/integrations/aws-cli-with-minio/)
-- [Use `minio-go` SDK with MinIO Server](https://silo.pgsty.com/developers/go/minio-go/)
+- [Use `minio-go` SDK with Silo Server](https://silo.pgsty.com/developers/go/minio-go/)
-- [The MinIO documentation website](https://silo.pgsty.com/docs/)
+- [The Silo documentation website](https://silo.pgsty.com/docs/)

docs/compression/README.md

@@ -1,8 +1,8 @@
-# Compression Guide [![Slack](https://slack.min.io/slack?type=svg)](https://slack.min.io)
+# Compression Guide
 
-MinIO server allows streaming compression to ensure efficient disk space usage.
+Silo server allows streaming compression to ensure efficient disk space usage.
 Compression happens inflight, i.e objects are compressed before being written to disk(s).
-MinIO uses [`klauspost/compress/s2`](https://github.com/klauspost/compress/tree/master/s2)
+Silo uses [`klauspost/compress/s2`](https://github.com/klauspost/compress/tree/master/s2)
 streaming compression due to its stability and performance.
 
 This algorithm is specifically optimized for machine generated content.
@@ -19,35 +19,35 @@ will increase speed when the content can be compressed.
 
 ### 1. Prerequisites
 
-Install MinIO - [MinIO Quickstart Guide](https://silo.pgsty.com/operations/deployments/baremetal-deploy-minio-on-redhat-linux/).
+Install Silo - [Silo Quickstart Guide](https://silo.pgsty.com/operations/deployments/baremetal-deploy-minio-on-redhat-linux/).
 
-### 2. Run MinIO with compression
+### 2. Run Silo with compression
 
-Compression can be enabled by updating the `compress` config settings for MinIO server config.
+Compression can be enabled by updating the `compress` config settings for Silo server config.
 Config `compress` settings take extensions and mime-types to be compressed.
 
 ```bash
-~ mc admin config get myminio compression
+~ mc admin config get mysilo compression
 compression extensions=".txt,.log,.csv,.json,.tar,.xml,.bin" mime_types="text/*,application/json,application/xml"
 ```
 
 Default config includes most common highly compressible content extensions and mime-types.
 
 ```bash
-~ mc admin config set myminio compression extensions=".pdf" mime_types="application/pdf"
+~ mc admin config set mysilo compression extensions=".pdf" mime_types="application/pdf"
 ```
 
 To show help on setting compression config values.
 
 ```bash
-~ mc admin config set myminio compression
+~ mc admin config set mysilo compression
 ```
 
 To enable compression for all content, no matter the extension and content type
 (except for the default excluded types) set BOTH extensions and mime types to empty.
 
 ```bash
-~ mc admin config set myminio compression enable="on" extensions="" mime_types=""
+~ mc admin config set mysilo compression enable="on" extensions="" mime_types=""
 ```
 
 The compression settings may also be set through environment variables.
@@ -75,13 +75,13 @@ See [CRIME TLS](https://en.wikipedia.org/wiki/CRIME) as an example of this.
 
 Therefore, compression is disabled when encrypting by default, and must be enabled separately.
 
-Consult our security experts on [SUBNET](https://min.io/pricing) to help you evaluate if
+Evaluate the security and resource impact in a staging environment before
-your setup can use this feature combination safely.
+deciding whether this feature combination is safe for your setup.
 
 To enable compression+encryption use:
 
 ```bash
-~ mc admin config set myminio compression allow_encryption=on
+~ mc admin config set mysilo compression allow_encryption=on
 ```
 
 Or alternatively through the environment variable `MINIO_COMPRESSION_ALLOW_ENCRYPTION=on`.
@@ -131,7 +131,7 @@ the data directory to view the size of the object.
 
 ## Explore Further
 
-- [Use `mc` with MinIO Server](https://silo.pgsty.com/reference/minio-mc/)
+- [Use `mc` with Silo Server](https://silo.pgsty.com/reference/minio-mc/)
-- [Use `aws-cli` with MinIO Server](https://silo.pgsty.com/integrations/aws-cli-with-minio/)
+- [Use `aws-cli` with Silo Server](https://silo.pgsty.com/integrations/aws-cli-with-minio/)
-- [Use `minio-go` SDK with MinIO Server](https://silo.pgsty.com/developers/go/minio-go/)
+- [Use `minio-go` SDK with Silo Server](https://silo.pgsty.com/developers/go/minio-go/)
-- [The MinIO documentation website](https://silo.pgsty.com/docs/)
+- [The Silo documentation website](https://silo.pgsty.com/docs/)

docs/config/README.md

@@ -1,18 +1,18 @@
-# MinIO Server Config 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 Server Config Guide [![Docker Pulls](https://img.shields.io/docker/pulls/pgsty/silo.svg?maxAge=604800)](https://hub.docker.com/r/pgsty/silo/)
 
 ## Configuration Directory
 
-MinIO stores all its config as part of the server deployment, config is erasure coded on MinIO. On a fresh deployment MinIO automatically generates a new `config` and this config is available to be configured via `mc admin config` command. MinIO also encrypts all the config, IAM and policies content if KMS is configured. Please refer to how to encrypt your config and IAM credentials [here](https://github.com/pgsty/minio/blob/master/docs/kms/IAM.md).
+Silo stores all its config as part of the server deployment, config is erasure coded on Silo. On a fresh deployment Silo automatically generates a new `config` and this config is available to be configured via `mc admin config` command. Silo also encrypts all the config, IAM and policies content if KMS is configured. Please refer to how to encrypt your config and IAM credentials [here](https://github.com/pgsty/minio/blob/master/docs/kms/IAM.md).
 
 ### Certificate Directory
 
-TLS certificates by default are expected to be stored under ``${HOME}/.minio/certs`` directory. You need to place certificates here to enable `HTTPS` based access. Read more about [How to secure access to MinIO server with TLS](https://silo.pgsty.com/operations/network-encryption/).
+TLS certificates by default are expected to be stored under ``${HOME}/.silo/certs`` directory. You need to place certificates here to enable `HTTPS` based access. Read more about [How to secure access to Silo server with TLS](https://silo.pgsty.com/operations/network-encryption/).
 
-Following is a sample directory structure for MinIO server with TLS certificates.
+Following is a sample directory structure for Silo server with TLS certificates.
 
 ```sh
-$ mc tree --files ~/.minio
+$ mc tree --files ~/.silo
-/home/user1/.minio
+/home/user1/.silo
 └─ certs
    ├─ CAs
    ├─ private.key
@@ -23,12 +23,12 @@ You can provide a custom certs directory using `--certs-dir` command line option
 
 #### Credentials
 
-On MinIO admin credentials or root credentials are only allowed to be changed using ENVs namely `MINIO_ROOT_USER` and `MINIO_ROOT_PASSWORD`.
+On Silo admin credentials or root credentials are only allowed to be changed using ENVs namely `MINIO_ROOT_USER` and `MINIO_ROOT_PASSWORD`.
 
 ```sh
 export MINIO_ROOT_USER=minio
-export MINIO_ROOT_PASSWORD=minio13
+export MINIO_ROOT_PASSWORD=silo13
-minio server /data
+silo server /data
 ```
 
 #### Site
@@ -60,12 +60,12 @@ Example:
 ```sh
 export MINIO_SITE_REGION="us-west-0"
 export MINIO_SITE_NAME="sfo-rack-1"
-minio server /data
+silo server /data
 ```
 
 ### Storage Class
 
-By default, parity for objects with standard storage class is set to `N/2`, and parity for objects with reduced redundancy storage class objects is set to `2`. Read more about storage class support in MinIO server [here](https://github.com/pgsty/minio/blob/master/docs/erasure/storage-class/README.md).
+By default, parity for objects with standard storage class is set to `N/2`, and parity for objects with reduced redundancy storage class objects is set to `2`. Read more about storage class support in Silo server [here](https://github.com/pgsty/minio/blob/master/docs/erasure/storage-class/README.md).
 
 ```
 KEY:
@@ -91,9 +91,9 @@ MINIO_STORAGE_CLASS_COMMENT   (sentence)  optionally add a comment to this setti
 
 #### Etcd
 
-MinIO supports storing encrypted IAM assets in etcd, if KMS is configured. Please refer to how to encrypt your config and IAM credentials [here](https://github.com/pgsty/minio/blob/master/docs/kms/IAM.md).
+Silo supports storing encrypted IAM assets in etcd, if KMS is configured. Please refer to how to encrypt your config and IAM credentials [here](https://github.com/pgsty/minio/blob/master/docs/kms/IAM.md).
 
-> NOTE: if *path_prefix* is set then MinIO will not federate your buckets, namespaced IAM assets are assumed as isolated tenants, only buckets are considered globally unique but performing a lookup with a *bucket* which belongs to a different tenant will fail unlike federated setups where MinIO would port-forward and route the request to relevant cluster accordingly. This is a special feature, federated deployments should not need to set *path_prefix*.
+> NOTE: if *path_prefix* is set then Silo will not federate your buckets, namespaced IAM assets are assumed as isolated tenants, only buckets are considered globally unique but performing a lookup with a *bucket* which belongs to a different tenant will fail unlike federated setups where Silo would port-forward and route the request to relevant cluster accordingly. This is a special feature, federated deployments should not need to set *path_prefix*.
 
 ```
 KEY:
@@ -125,7 +125,7 @@ MINIO_ETCD_COMMENT          (sentence)  optionally add a comment to this setting
 
 ### API
 
-By default, there is no limitation on the number of concurrent requests that a server/cluster processes at the same time. However, it is possible to impose such limitation using the API subsystem. Read more about throttling limitation in MinIO server [here](https://github.com/pgsty/minio/blob/master/docs/throttle/README.md).
+By default, there is no limitation on the number of concurrent requests that a server/cluster processes at the same time. However, it is possible to impose such limitation using the API subsystem. Read more about throttling limitation in Silo server [here](https://github.com/pgsty/minio/blob/master/docs/throttle/README.md).
 
 ```
 KEY:
@@ -139,7 +139,7 @@ remote_transport_deadline       (duration)  set the deadline for API requests on
 list_quorum                     (string)    set the acceptable quorum expected for list operations e.g. "optimal", "reduced", "disk", "strict", "auto" (default: 'strict')
 replication_priority            (string)    set replication priority (default: 'auto')
 replication_max_workers         (number)    set the maximum number of replication workers (default: '500')
-replication_max_lrg_workers     (number)    set the maximum number of replication workers MinIO uses to replicate large objects between sites. (default: '10')
+replication_max_lrg_workers     (number)    set the maximum number of replication workers Silo uses to replicate large objects between sites. (default: '10')
 transition_workers              (number)    set the number of transition workers (default: '100')
 stale_uploads_expiry            (duration)  set to expire stale multipart uploads older than this values (default: '24h')
 stale_uploads_cleanup_interval  (duration)  set to change intervals when stale multipart uploads are expired (default: '6h')
@@ -172,7 +172,7 @@ MINIO_API_OBJECT_MAX_VERSIONS             (number)    set max allowed number of
 
 #### Notifications
 
-Notification targets supported by MinIO are in the following list. To configure individual targets please refer to more detailed documentation [here](https://silo.pgsty.com/administration/monitoring/#bucket-notifications).
+Notification targets supported by Silo are in the following list. To configure individual targets please refer to more detailed documentation [here](https://silo.pgsty.com/administration/monitoring/#bucket-notifications).
 
 ```
 notify_webhook        publish bucket notifications to webhook endpoints
@@ -189,21 +189,23 @@ notify_redis          publish bucket notifications to Redis datastores
 
 ### Accessing configuration
 
-All configuration changes can be made using [`mc admin config` get/set/reset/export/import commands](https://github.com/minio/mc/blob/master/docs/minio-admin-complete-guide.md).
+All configuration changes can be made using the compatible
+[`mc admin config`](https://github.com/pgsty/mc/blob/master/docs/minio-admin-complete-guide.md)
+get, set, reset, export, and import commands.
 
 #### List all config keys available
 
 ```
-~ mc admin config set myminio/
+~ mc admin config set mysilo/
 ```
 
 #### Obtain help for each key
 
 ```
-~ mc admin config set myminio/ <key>
+~ mc admin config set mysilo/ <key>
 ```
 
-e.g: `mc admin config set myminio/ etcd` returns available `etcd` config args
+e.g: `mc admin config set mysilo/ etcd` returns available `etcd` config args
 
 ```
 ~ mc admin config set play/ etcd
@@ -313,28 +315,28 @@ Example:
 
 ```sh
 export MINIO_BROWSER=off
-minio server /data
+silo server /data
 ```
 
 ### Domain
 
-By default, MinIO supports path-style requests that are of the format <http://mydomain.com/bucket/object>. `MINIO_DOMAIN` environment variable is used to enable virtual-host-style requests. If the request `Host` header matches with `(.+).mydomain.com` then the matched pattern `$1` is used as bucket and the path is used as object. Read more about path-style and virtual-host-style [here](http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAPI.html).
+By default, Silo supports path-style requests that are of the format <http://mydomain.com/bucket/object>. `MINIO_DOMAIN` environment variable is used to enable virtual-host-style requests. If the request `Host` header matches with `(.+).mydomain.com` then the matched pattern `$1` is used as bucket and the path is used as object. Read more about path-style and virtual-host-style [here](http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAPI.html).
 
 Example:
 
 ```sh
 export MINIO_DOMAIN=mydomain.com
-minio server /data
+silo server /data
 ```
 
 For advanced use cases `MINIO_DOMAIN` environment variable supports multiple-domains with comma separated values.
 
 ```sh
 export MINIO_DOMAIN=sub1.mydomain.com,sub2.mydomain.com
-minio server /data
+silo server /data
 ```
 
 ## Explore Further
 
-* [MinIO Quickstart Guide](https://silo.pgsty.com/operations/deployments/baremetal-deploy-minio-on-redhat-linux/)
+* [Silo Quickstart Guide](https://silo.pgsty.com/operations/deployments/baremetal-deploy-minio-on-redhat-linux/)
-* [Configure MinIO Server with TLS](https://silo.pgsty.com/operations/network-encryption/)
+* [Configure Silo Server with TLS](https://silo.pgsty.com/operations/network-encryption/)

docs/debugging/README.md

@@ -1,4 +1,4 @@
-# MinIO Server Debugging 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 Server Debugging Guide [![Docker Pulls](https://img.shields.io/docker/pulls/pgsty/silo.svg?maxAge=604800)](https://hub.docker.com/r/pgsty/silo/)
 
 ## HTTP Trace
 
@@ -7,41 +7,41 @@ HTTP tracing can be enabled by using [`mc admin trace`](https://silo.pgsty.com/r
 Example:
 
 ```sh
-minio server /data
+silo server /data
 ```
 
 Default trace is succinct only to indicate the API operations being called and the HTTP response status.
 
 ```sh
-mc admin trace myminio
+mc admin trace mysilo
 ```
 
 To trace entire HTTP request
 
 ```sh
-mc admin trace --verbose myminio
+mc admin trace --verbose mysilo
 ```
 
 To trace entire HTTP request and also internode communication
 
 ```sh
-mc admin trace --all --verbose myminio
+mc admin trace --all --verbose mysilo
 ```
 
 ## Subnet Health
 
-Subnet Health diagnostics help ensure that the underlying infrastructure that runs MinIO is configured correctly, and is functioning properly. This test is one-shot long running one, that is recommended to be run as soon as the cluster is first provisioned, and each time a failure scenario is encountered. Note that the test incurs majority of the available resources on the system. Care must be taken when using this to debug failure scenario, so as to prevent larger outages. Health tests can be triggered using `mc support diagnostics` command.
+Subnet Health diagnostics help ensure that the underlying infrastructure that runs Silo is configured correctly, and is functioning properly. This test is one-shot long running one, that is recommended to be run as soon as the cluster is first provisioned, and each time a failure scenario is encountered. Note that the test incurs majority of the available resources on the system. Care must be taken when using this to debug failure scenario, so as to prevent larger outages. Health tests can be triggered using `mc support diagnostics` command.
 
 Example:
 
 ```sh
-minio server /data{1...4}
+silo server /data{1...4}
 ```
 
 The command takes no flags
 
 ```sh
-mc support diagnostics myminio/
+mc support diagnostics mysilo/
 ```
 
 The output printed will be of the form
@@ -72,10 +72,11 @@ Metadata is stored in `xl.meta` files for erasure coded objects. Each disk in th
 
 ### Installing xl-meta
 
-To install, [Go](https://golang.org/dl/) must be installed. Once installed, execute this to install the binary:
+With Go installed, build the diagnostic tool from the same Silo source revision
+as the server:
 
 ```bash
-go install github.com/minio/minio/docs/debugging/xl-meta@latest
+go build -o "$(go env GOPATH)/bin/xl-meta" ./docs/debugging/xl-meta
 ```
 
 ### Using xl-meta
@@ -84,7 +85,7 @@ Executing `xl-meta` will look for an `xl.meta` in the current folder and decode
 
 ### Remotely Inspecting backend data
 
-`mc support inspect` allows collecting files based on *path* from all backend drives. Matching files will be collected in a zip file with their respective host+drive+path. A MinIO host from October 2021 or later is required for full functionality. Syntax is `mc support inspect ALIAS/path/to/files`. This can for example be used to collect `xl.meta` from objects that are misbehaving. To collect `xl.meta` from a specific object, for example placed at `ALIAS/bucket/path/to/file.txt` append `/xl.meta`, for instance `mc support inspect ALIAS/bucket/path/to/file.txt/xl.meta`. All files can be collected, so this can also be used to retrieve `part.*` files, etc.
+`mc support inspect` allows collecting files based on *path* from all backend drives. Matching files will be collected in a zip file with their respective host+drive+path. A Silo host from October 2021 or later is required for full functionality. Syntax is `mc support inspect ALIAS/path/to/files`. This can for example be used to collect `xl.meta` from objects that are misbehaving. To collect `xl.meta` from a specific object, for example placed at `ALIAS/bucket/path/to/file.txt` append `/xl.meta`, for instance `mc support inspect ALIAS/bucket/path/to/file.txt/xl.meta`. All files can be collected, so this can also be used to retrieve `part.*` files, etc.
 
 Wildcards can be used, for example `mc support inspect ALIAS/bucket/path/**/xl.meta` will collect all `xl.meta` recursively. `mc support inspect ALIAS/bucket/path/to/file.txt/*/part.*` will collect parts for all versions for the object located at `bucket/path/to/file.txt`.
 
@@ -120,10 +121,10 @@ This file can be decrypted using the decryption tool below:
 
 To install, [Go](https://golang.org/dl/) must be installed.
 
-Once installed, execute this to install the binary:
+Build the decryption tool from the same Silo source revision:
 
 ```bash
-go install github.com/minio/minio/docs/debugging/inspect@latest
+go build -o "$(go env GOPATH)/bin/inspect" ./docs/debugging/inspect
 ```
 
 ### Usage

docs/distributed/CONFIG.md

@@ -1,18 +1,18 @@
-## MinIO configuration YAML
+## Silo configuration YAML
 
-MinIO now supports starting the server arguments and configuration via a YAML configuration file. This YAML configuration describes everything that can be configured in a MinIO setup, such as '--address', '--console-address' and command line arguments for the MinIO server.
+Silo now supports starting the server arguments and configuration via a YAML configuration file. This YAML configuration describes everything that can be configured in a Silo setup, such as '--address', '--console-address' and command line arguments for the Silo server.
 
-Historically everything to MinIO was provided via command arguments for the hostnames and the drives via an ellipses syntax such as `minio server http://host{1...4}/disk{1...4}` this requirement added an additional burden to have sequential hostnames for us to make sure that we can provide horizontal distribution, however we have come across situations where sometimes this is not feasible and there are no easier alternatives without modifying /etc/hosts on the host system as root user.  Many times in airgapped deployments this is not allowed or requires audits and approvals.
+Historically everything to Silo was provided via command arguments for the hostnames and the drives via an ellipses syntax such as `silo server http://host{1...4}/disk{1...4}` this requirement added an additional burden to have sequential hostnames for us to make sure that we can provide horizontal distribution, however we have come across situations where sometimes this is not feasible and there are no easier alternatives without modifying /etc/hosts on the host system as root user.  Many times in airgapped deployments this is not allowed or requires audits and approvals.
 
-MinIO server configuration file allows users to provide topology that allows for heterogeneous hostnames, allowing MinIO to deployed in pre-existing environments without any further OS level configurations.
+Silo server configuration file allows users to provide topology that allows for heterogeneous hostnames, allowing Silo to deployed in pre-existing environments without any further OS level configurations.
 
 ### Usage
 
 ```
-minio server --config config.yaml
+silo server --config config.yaml
 ```
 
-Lets you start MinIO server with all inputs to start MinIO server provided via this configuration file, once the configuration file is provided all other pre-existing values on disk for configuration are overridden by the new values set in this configuration file.
+Lets you start Silo server with all inputs to start Silo server provided via this configuration file, once the configuration file is provided all other pre-existing values on disk for configuration are overridden by the new values set in this configuration file.
 
 Following is an example YAML configuration structure.
 ```yaml
@@ -21,7 +21,7 @@ address: ":9000"
 rootUser: "minioadmin"
 rootPassword: "minioadmin"
 console-address: ":9001"
-certs-dir: "/home/user/.minio/certs/"
+certs-dir: "/home/user/.silo/certs/"
 pools: # Specify the nodes and drives with pools
   - args:
       - "https://server-example-pool1:9000/mnt/disk{1...4}/"
@@ -36,10 +36,10 @@ pools: # Specify the nodes and drives with pools
   # more args
 
 options:
-  ftp: # settings for MinIO to act as an ftp server
+  ftp: # settings for Silo to act as an ftp server
     address: ":8021"
     passive-port-range: "30000-40000"
-  sftp: # settings for MinIO to act as an sftp server
+  sftp: # settings for Silo to act as an sftp server
     address: ":8022"
     ssh-private-key: "/home/user/.ssh/id_rsa"
 ```
@@ -65,7 +65,7 @@ pools:
       - "https://server{1...2}-pool1:9000/mnt/disk{1...4}/"
       - "https://server3-pool1:9000/mnt/disk{1...4}/"
       - "https://server4-pool1:9000/mnt/disk{1...4}/"
-    set-drive-count: 4 # Advanced option, must be used under guidance from MinIO team.
+    set-drive-count: 4 # Advanced option, must be used under guidance from Silo team.
 ```
 
 ### Things to know
@@ -73,16 +73,16 @@ pools:
 - Fields such as `version` and `pools` are mandatory, however all other fields are optional.
 - Each pool expects a minimum of 2 nodes per pool, and unique non-repeating hosts for each argument.
 - Each pool expects each host in this pool has the same number of drives specified as any other host.
-- Mixing `local-path` and `distributed-path` is not allowed, doing so would cause MinIO to refuse starting the server.
+- Mixing `local-path` and `distributed-path` is not allowed, doing so would cause Silo to refuse starting the server.
 - Ellipses and bracket notation (e.g. `{1...10}`) are allowed.
 
-> NOTE: MinIO environmental variables still take precedence over the `config.yaml` file, however `config.yaml` is preferred over MinIO internal config KV settings via `mc admin config set alias/ <sub-system>`.
+> NOTE: Silo environmental variables still take precedence over the `config.yaml` file, however `config.yaml` is preferred over Silo internal config KV settings via `mc admin config set alias/ <sub-system>`.
 
 ### TODO
 
 In subsequent releases we are planning to extend this to provide things like
 
-- Reload() of MinIO server arguments without fully restarting the process.
+- Reload() of Silo server arguments without fully restarting the process.
 
 - Expanding 1 node at a time by automating the process of creating a new pool
   and decommissioning to provide a functionality that smaller deployments

docs/distributed/DECOMMISSION.md

@@ -1,6 +1,6 @@
 # Decommissioning
 
-Decommissiong is a mechanism in MinIO to drain older pools (usually with old hardware) and migrate the content from such pools to a newer pools (usually better hardware). Decommissioning spreads the data across all pools - for example, if you decommission `pool1`, all the data from `pool1` spreads across `pool2` and `pool3`.
+Decommissiong is a mechanism in Silo to drain older pools (usually with old hardware) and migrate the content from such pools to a newer pools (usually better hardware). Decommissioning spreads the data across all pools - for example, if you decommission `pool1`, all the data from `pool1` spreads across `pool2` and `pool3`.
 
 ## Features
 
@@ -92,7 +92,7 @@ If the decommission process fails for any reason, the status indicates failed.
 
 ## When decommission is 'Complete'
 
-Once decommission is complete, it will be indicated with *Complete* status.  *Complete* means that now you can now safely remove the first pool argument from the MinIO command line.
+Once decommission is complete, it will be indicated with *Complete* status.  *Complete* means that now you can now safely remove the first pool argument from the Silo command line.
 
 ```
 λ mc admin decommission status alias/
@@ -103,11 +103,11 @@ Once decommission is complete, it will be indicated with *Complete* status.  *Co
 └─────┴─────────────────────────────────┴──────────────────────────────────┴──────────┘
 ```
 
-- On baremetal setups, if you have `MINIO_VOLUMES="http://minio{1...2}/data{1...4} http://minio{3...4}/data{1...4}"`, you can remove the first argument `http://minio{1...2}/data{1...4}` to update your `MINIO_VOLUMES` setting, then restart all the servers in the setup in parallel using `systemctl restart minio`.
+- On baremetal setups, if you have `MINIO_VOLUMES="http://minio{1...2}/data{1...4} http://minio{3...4}/data{1...4}"`, you can remove the first argument `http://minio{1...2}/data{1...4}` to update your `MINIO_VOLUMES` setting, then restart all the servers in the setup in parallel using `systemctl restart silo`.
 
-- On Kubernetes setups, the statefulset specification needs to be modified by changing the command line input for the MinIO container. Once the relevant changes are done, proceed to execute `kubectl apply -f statefulset.yaml`.
+- On Kubernetes setups, the statefulset specification needs to be modified by changing the command line input for the Silo container. Once the relevant changes are done, proceed to execute `kubectl apply -f statefulset.yaml`.
 
-- On Operator based MinIO deployments, you need to modify the `tenant.yaml` specification and modify the `pools:` section from two entries to a single entry. After making relevant changes, proceed to execute `kubectl apply -f tenant.yaml`.
+- On Silo deployments managed by the MinIO Operator, you need to modify the `tenant.yaml` specification and change the `pools:` section from two entries to a single entry. After making the relevant changes, proceed to execute `kubectl apply -f tenant.yaml`.
 
 > Without a 'Complete' status any 'Active' or 'Draining' pool(s) are not allowed to be removed once configured.
 

docs/distributed/DESIGN.md

@@ -1,17 +1,17 @@
-# Distributed Server Design Guide [![Slack](https://slack.min.io/slack?type=svg)](https://slack.min.io)
+# Distributed Server Design Guide
 
-This document explains the design, architecture and advanced use cases of the MinIO distributed server.
+This document explains the design, architecture and advanced use cases of the Silo distributed server.
 
 ## Command-line
 
 ```
 NAME:
-  minio server - start object storage server
+  silo server - start object storage server
 
 USAGE:
-  minio server [FLAGS] DIR1 [DIR2..]
+  silo server [FLAGS] DIR1 [DIR2..]
-  minio server [FLAGS] DIR{1...64}
+  silo server [FLAGS] DIR{1...64}
-  minio server [FLAGS] DIR{1...64} DIR{65...128}
+  silo server [FLAGS] DIR{1...64} DIR{65...128}
 
 DIR:
   DIR points to a directory on a filesystem. When you want to combine
@@ -26,22 +26,22 @@ DIR:
 Standalone erasure coded configuration with 4 sets with 16 drives each.
 
 ```
-minio server dir{1...64}
+silo server dir{1...64}
 ```
 
 Distributed erasure coded configuration with 64 sets with 16 drives each.
 
 ```
-minio server http://host{1...16}/export{1...64}
+silo server http://host{1...16}/export{1...64}
 ```
 
 ## Architecture
 
-Expansion of ellipses and choice of erasure sets based on this expansion is an automated process in MinIO. Here are some of the details of our underlying erasure coding behavior.
+Expansion of ellipses and choice of erasure sets based on this expansion is an automated process in Silo. Here are some of the details of our underlying erasure coding behavior.
 
-- Erasure coding used by MinIO is [Reed-Solomon](https://github.com/klauspost/reedsolomon) erasure coding scheme, which has a total shard maximum of 256 i.e 128 data and 128 parity. MinIO design goes beyond this limitation by doing some practical architecture choices.
+- Erasure coding used by Silo is [Reed-Solomon](https://github.com/klauspost/reedsolomon) erasure coding scheme, which has a total shard maximum of 256 i.e 128 data and 128 parity. Silo design goes beyond this limitation by doing some practical architecture choices.
 
-- Erasure set is a single erasure coding unit within a MinIO deployment. An object is sharded within an erasure set. Erasure set size is automatically calculated based on the number of drives. MinIO supports unlimited number of drives but each erasure set can be up to 16 drives and a minimum of 2 drives.
+- Erasure set is a single erasure coding unit within a Silo deployment. An object is sharded within an erasure set. Erasure set size is automatically calculated based on the number of drives. Silo supports unlimited number of drives but each erasure set can be up to 16 drives and a minimum of 2 drives.
 
 - We limited the number of drives to 16 for erasure set because, erasure code shards more than 16 can become chatty and do not have any performance advantages. Additionally since 16 drive erasure set gives you tolerance of 8 drives per object by default which is plenty in any practical scenario.
 
@@ -51,10 +51,10 @@ Expansion of ellipses and choice of erasure sets based on this expansion is an a
 
 - *If total number of nodes are of odd number then GCD algorithm provides affinity towards odd number erasure sets to provide for uniform distribution across nodes*. This is to ensure that same number of drives are pariticipating in any erasure set. For example if you have 2 nodes with 180 drives then GCD is 15 but this would lead to uneven distribution, one of the nodes would participate more drives. To avoid this the affinity is given towards nodes which leads to next best GCD factor of 12 which provides uniform distribution.
 
-- In this algorithm, we also make sure that we spread the drives out evenly. MinIO server expands ellipses passed as arguments. Here is a sample expansion to demonstrate the process.
+- In this algorithm, we also make sure that we spread the drives out evenly. Silo server expands ellipses passed as arguments. Here is a sample expansion to demonstrate the process.
 
 ```
-minio server http://host{1...2}/export{1...8}
+silo server http://host{1...2}/export{1...8}
 ```
 
 Expected expansion
@@ -98,14 +98,14 @@ Input for the key is the object name specified in `PutObject()`, returns a uniqu
 
 - Write and Read quorum are required to be satisfied only across the erasure set for an object. Healing is also done per object within the erasure set which contains the object.
 
-- MinIO does erasure coding at the object level not at the volume level, unlike other object storage vendors. This allows applications to choose different storage class by setting `x-amz-storage-class=STANDARD/REDUCED_REDUNDANCY` for each object uploads so effectively utilizing the capacity of the cluster. Additionally these can also be enforced using IAM policies to make sure the client uploads with correct HTTP headers.
+- Silo does erasure coding at the object level not at the volume level, unlike other object storage vendors. This allows applications to choose different storage class by setting `x-amz-storage-class=STANDARD/REDUCED_REDUNDANCY` for each object uploads so effectively utilizing the capacity of the cluster. Additionally these can also be enforced using IAM policies to make sure the client uploads with correct HTTP headers.
 
-- MinIO also supports expansion of existing clusters in server pools. Each pool is a self contained entity with same SLA's (read/write quorum) for each object as original cluster. By using the existing namespace for lookup validation MinIO ensures conflicting objects are not created. When no such object exists then MinIO simply uses the least used pool to place new objects.
+- Silo also supports expansion of existing clusters in server pools. Each pool is a self contained entity with same SLA's (read/write quorum) for each object as original cluster. By using the existing namespace for lookup validation Silo ensures conflicting objects are not created. When no such object exists then Silo simply uses the least used pool to place new objects.
 
 ### There are no limits on how many server pools can be combined
 
 ```
-minio server http://host{1...32}/export{1...32} http://host{1...12}/export{1...12}
+silo server http://host{1...32}/export{1...32} http://host{1...12}/export{1...12}
 ```
 
 In above example there are two server pools
@@ -117,7 +117,7 @@ In above example there are two server pools
 
 Refer to the sizing guide with details on the default parity count chosen for different erasure stripe sizes [here](https://github.com/pgsty/minio/blob/master/docs/distributed/SIZING.md)
 
-MinIO places new objects in server pools based on proportionate free space, per pool. Following pseudo code demonstrates this behavior.
+Silo places new objects in server pools based on proportionate free space, per pool. Following pseudo code demonstrates this behavior.
 
 ```go
 func getAvailablePoolIdx(ctx context.Context) int {
@@ -144,23 +144,23 @@ func getAvailablePoolIdx(ctx context.Context) int {
 Standalone erasure coded configuration with 4 sets with 16 drives each, which spawns drives across controllers.
 
 ```
-minio server /mnt/controller{1...4}/data{1...16}
+silo server /mnt/controller{1...4}/data{1...16}
 ```
 
 Standalone erasure coded configuration with 16 sets, 16 drives per set, across mounts and controllers.
 
 ```
-minio server /mnt{1...4}/controller{1...4}/data{1...16}
+silo server /mnt{1...4}/controller{1...4}/data{1...16}
 ```
 
 Distributed erasure coded configuration with 2 sets, 16 drives per set across hosts.
 
 ```
-minio server http://host{1...32}/disk1
+silo server http://host{1...32}/disk1
 ```
 
 Distributed erasure coded configuration with rack level redundancy 32 sets in total, 16 drives per set.
 
 ```
-minio server http://rack{1...4}-host{1...8}.example.net/export{1...16}
+silo server http://rack{1...4}-host{1...8}.example.net/export{1...16}
 ```

docs/distributed/README.md

@@ -1,95 +1,104 @@
-# Distributed MinIO Quickstart 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/)
+# Distributed Silo Quickstart Guide [![Docker Pulls](https://img.shields.io/docker/pulls/pgsty/silo.svg?maxAge=604800)](https://hub.docker.com/r/pgsty/silo/)
 
-MinIO in distributed mode lets you pool multiple drives (even on different machines) into a single object storage server. As drives are distributed across several nodes, distributed MinIO can withstand multiple node failures and yet ensure full data protection.
+Silo in distributed mode lets you pool multiple drives (even on different machines) into a single object storage server. As drives are distributed across several nodes, distributed Silo can withstand multiple node failures and yet ensure full data protection.
 
-## Why distributed MinIO?
+## Why distributed Silo?
 
-MinIO in distributed mode can help you setup a highly-available storage system with a single object storage deployment. With distributed MinIO, you can optimally use storage devices, irrespective of their location in a network.
+Silo in distributed mode can help you setup a highly-available storage system with a single object storage deployment. With distributed Silo, you can optimally use storage devices, irrespective of their location in a network.
 
 ### Data protection
 
-Distributed MinIO provides protection against multiple node/drive failures and [bit rot](https://github.com/pgsty/minio/blob/master/docs/erasure/README.md#what-is-bit-rot-protection) using [erasure code](https://silo.pgsty.com/operations/concepts/erasure-coding/). As the minimum drives required for distributed MinIO is 2 (same as minimum drives required for erasure coding), erasure code automatically kicks in as you launch distributed MinIO.
+Distributed Silo provides protection against multiple node/drive failures and [bit rot](https://github.com/pgsty/minio/blob/master/docs/erasure/README.md#what-is-bit-rot-protection) using [erasure code](https://silo.pgsty.com/operations/concepts/erasure-coding/). As the minimum drives required for distributed Silo is 2 (same as minimum drives required for erasure coding), erasure code automatically kicks in as you launch distributed Silo.
 
 If one or more drives are offline at the start of a PutObject or NewMultipartUpload operation the object will have additional data protection bits added automatically to provide additional safety for these objects.
 
 ### High availability
 
-A stand-alone MinIO server would go down if the server hosting the drives goes offline. In contrast, a distributed MinIO setup with _m_ servers and _n_ drives will have your data safe as long as _m/2_ servers or _m*n_/2 or more drives are online.
+A stand-alone Silo server would go down if the server hosting the drives goes offline. In contrast, a distributed Silo setup with _m_ servers and _n_ drives will have your data safe as long as _m/2_ servers or _m*n_/2 or more drives are online.
 
-For example, an 16-server distributed setup with 200 drives per node would continue serving files, up to 4 servers can be offline in default configuration i.e around 800 drives down MinIO would continue to read and write objects.
+For example, an 16-server distributed setup with 200 drives per node would continue serving files, up to 4 servers can be offline in default configuration i.e around 800 drives down Silo would continue to read and write objects.
 
 Refer to sizing guide for more understanding on default values chosen depending on your erasure stripe size [here](https://github.com/pgsty/minio/blob/master/docs/distributed/SIZING.md). Parity settings can be changed using [storage classes](https://github.com/pgsty/minio/tree/master/docs/erasure/storage-class).
 
 ### Consistency Guarantees
 
-MinIO follows strict **read-after-write** and **list-after-write** consistency model for all i/o operations both in distributed and standalone modes. This consistency model is only guaranteed if you use disk filesystems such as xfs, zfs or btrfs etc.. for distributed setup.
+Silo follows strict **read-after-write** and **list-after-write** consistency model for all i/o operations both in distributed and standalone modes. This consistency model is only guaranteed if you use disk filesystems such as xfs, zfs or btrfs etc.. for distributed setup.
 
 **In our tests we also found ext4 does not honor POSIX O_DIRECT/Fdatasync semantics, ext4 trades performance for consistency guarantees. Please avoid ext4 in your setup.**
 
-**If MinIO distributed setup is using NFS volumes underneath it is not guaranteed MinIO will provide these consistency guarantees since NFS is not strictly consistent (If you must use NFS we recommend that you at least use NFSv4 instead of NFSv3 for relatively better outcomes).**
+**If Silo distributed setup is using NFS volumes underneath it is not guaranteed Silo will provide these consistency guarantees since NFS is not strictly consistent (If you must use NFS we recommend that you at least use NFSv4 instead of NFSv3 for relatively better outcomes).**
 
 ## Get started
 
-If you're aware of stand-alone MinIO set up, the process remains largely the same. MinIO server automatically switches to stand-alone or distributed mode, depending on the command line parameters.
+If you're aware of stand-alone Silo set up, the process remains largely the same. Silo server automatically switches to stand-alone or distributed mode, depending on the command line parameters.
 
 ### 1. Prerequisites
 
-Install MinIO either on Kubernetes or Distributed Linux.
+Install Silo either on Kubernetes or Distributed Linux.
 
-Install MinIO on Kubernetes:
+Install Silo on Kubernetes:
 
-- [MinIO Quickstart Guide for Kubernetes](https://silo.pgsty.com/operations/deployments/kubernetes/).
+- [Silo Quickstart Guide for Kubernetes](https://silo.pgsty.com/operations/deployments/kubernetes/).
-- [Deploy a Tenant from the MinIO Operator](https://silo.pgsty.com/operations/deployments/k8s-deploy-minio-tenant-on-kubernetes/)
+- [Deploy Silo on Kubernetes](https://silo.pgsty.com/operations/deployments/kubernetes/)
 
-Install Distributed MinIO on Linux:
+Install Distributed Silo on Linux:
-- [Deploy Distributed MinIO on Linux](https://silo.pgsty.com/operations/deployments/baremetal/#deploy-minio-distributed-baremetal)
+- [Deploy Distributed Silo on Linux](https://silo.pgsty.com/operations/deployments/baremetal/#deploy-minio-distributed-baremetal)
 
-### 2. Run distributed MinIO
+### 2. Run distributed Silo
 
-To start a distributed MinIO instance, you just need to pass drive locations as parameters to the minio server command. Then, you’ll need to run the same command on all the participating nodes.
+To start a distributed Silo instance, you just need to pass drive locations as parameters to the silo server command. Then, you’ll need to run the same command on all the participating nodes.
 
 **NOTE:**
 
-- All the nodes running distributed MinIO should share a common root credentials, for the nodes to connect and trust each other. To achieve this, it is **recommended** to export root user and root password as environment variables, `MINIO_ROOT_USER` and `MINIO_ROOT_PASSWORD`, on all the nodes before executing MinIO server command. If not exported, default `minioadmin/minioadmin` credentials shall be used.
+- All the nodes running distributed Silo should share a common root credentials, for the nodes to connect and trust each other. To achieve this, it is **recommended** to export root user and root password as environment variables, `MINIO_ROOT_USER` and `MINIO_ROOT_PASSWORD`, on all the nodes before executing Silo server command. If not exported, default `minioadmin/minioadmin` credentials shall be used.
-- **MinIO creates erasure-coding sets of _2_ to _16_ drives per set.  The number of drives you provide in total must be a multiple of one of those numbers.**
+- **Silo creates erasure-coding sets of _2_ to _16_ drives per set.  The number of drives you provide in total must be a multiple of one of those numbers.**
-- **MinIO chooses the largest EC set size which divides into the total number of drives or total number of nodes given - making sure to keep the uniform distribution i.e each node participates equal number of drives per set**.
+- **Silo chooses the largest EC set size which divides into the total number of drives or total number of nodes given - making sure to keep the uniform distribution i.e each node participates equal number of drives per set**.
 - **Each object is written to a single EC set, and therefore is spread over no more than 16 drives.**
-- **All the nodes running distributed MinIO setup are recommended to be homogeneous, i.e. same operating system, same number of drives and same network interconnects.**
+- **All the nodes running distributed Silo setup are recommended to be homogeneous, i.e. same operating system, same number of drives and same network interconnects.**
-- MinIO distributed mode requires **fresh directories**. If required, the drives can be shared with other applications. You can do this by using a sub-directory exclusive to MinIO. For example, if you have mounted your volume under `/export`, pass `/export/data` as arguments to MinIO server.
+- Silo distributed mode requires **fresh directories**. If required, the drives can be shared with other applications. You can do this by using a sub-directory exclusive to Silo. For example, if you have mounted your volume under `/export`, pass `/export/data` as arguments to Silo server.
 - The IP addresses and drive paths below are for demonstration purposes only, you need to replace these with the actual IP addresses and drive paths/folders.
-- Servers running distributed MinIO instances should be less than 15 minutes apart. You can enable [NTP](http://www.ntp.org/) service as a best practice to ensure same times across servers.
+- Servers running distributed Silo instances should be less than 15 minutes apart. You can enable [NTP](http://www.ntp.org/) service as a best practice to ensure same times across servers.
 - `MINIO_DOMAIN` environment variable should be defined and exported for bucket DNS style support.
-- Running Distributed MinIO on **Windows** operating system is considered **experimental**. Please proceed with caution.
+- Running Distributed Silo on **Windows** operating system is considered **experimental**. Please proceed with caution.
 
-Example 1: Start distributed MinIO instance on n nodes with m drives each mounted at `/export1` to `/exportm` (pictured below), by running this command on all the n nodes:
+Example 1: Start a distributed Silo instance on n nodes with m drives each mounted at `/export1` to `/exportm`, by running this command on all participating nodes:
 
-![Distributed MinIO, n nodes with m drives each](https://github.com/pgsty/minio/blob/master/docs/screenshots/Architecture-diagram_distributed_nm.png?raw=true)
+```mermaid
+flowchart TB
+    client["S3 clients"] --> endpoint["Load balancer or any Silo endpoint"]
+    endpoint --> node1["Silo node 1"]
+    endpoint --> node2["Silo node 2"]
+    endpoint --> noden["Silo node n"]
+    node1 --> drives1["export1 through exportm"]
+    node2 --> drives2["export1 through exportm"]
+    noden --> drivesn["export1 through exportm"]
+```
 
 ### GNU/Linux and macOS
 
 ```sh
 export MINIO_ROOT_USER=<ACCESS_KEY>
 export MINIO_ROOT_PASSWORD=<SECRET_KEY>
-minio server http://host{1...n}/export{1...m}
+silo server http://host{1...n}/export{1...m}
 ```
 
 > **NOTE:** In above example `n` and `m` represent positive integers, _do not copy paste and expect it work make the changes according to local deployment and setup_.
-> **NOTE:** `{1...n}` shown have 3 dots! Using only 2 dots `{1..n}` will be interpreted by your shell and won't be passed to MinIO server, affecting the erasure coding order, which would impact performance and high availability. **Always use ellipses syntax `{1...n}` (3 dots!) for optimal erasure-code distribution**
+> **NOTE:** `{1...n}` shown have 3 dots! Using only 2 dots `{1..n}` will be interpreted by your shell and won't be passed to Silo server, affecting the erasure coding order, which would impact performance and high availability. **Always use ellipses syntax `{1...n}` (3 dots!) for optimal erasure-code distribution**
 
 ### Expanding existing distributed setup
 
-MinIO supports expanding distributed erasure coded clusters by specifying new set of clusters on the command-line as shown below:
+Silo supports expanding distributed erasure coded clusters by specifying new set of clusters on the command-line as shown below:
 
 ```sh
 export MINIO_ROOT_USER=<ACCESS_KEY>
 export MINIO_ROOT_PASSWORD=<SECRET_KEY>
-minio server http://host{1...n}/export{1...m} http://host{o...z}/export{1...m}
+silo server http://host{1...n}/export{1...m} http://host{o...z}/export{1...m}
 ```
 
 For example:
 
 ```
-minio server http://host{1...4}/export{1...16} http://host{5...12}/export{1...16}
+silo server http://host{1...4}/export{1...16} http://host{5...12}/export{1...16}
 ```
 
 Now the server has expanded total storage by _(newly_added_servers\*m)_ more drives, taking the total count to _(existing_servers\*m)+(newly_added_servers\*m)_ drives. New object upload requests automatically start using the least used cluster. This expansion strategy works endlessly, so you can perpetually expand your clusters as needed.  When you restart, it is immediate and non-disruptive to the applications. Each group of servers in the command-line is called a pool. There are 2 server pools in this example. New objects are placed in server pools in proportion to the amount of free space in each pool. Within each pool, the location of the erasure-set of drives is determined based on a deterministic hashing algorithm.
@@ -98,12 +107,12 @@ Now the server has expanded total storage by _(newly_added_servers\*m)_ more dri
 
 ## 3. Test your setup
 
-To test this setup, access the MinIO server via browser or [`mc`](https://silo.pgsty.com/reference/minio-mc/#quickstart).
+To test this setup, access the Silo server via browser or [`mc`](https://silo.pgsty.com/reference/minio-mc/#quickstart).
 
 ## Explore Further
 
-- [MinIO Erasure Code QuickStart Guide](https://silo.pgsty.com/operations/concepts/erasure-coding/)
+- [Silo Erasure Code QuickStart Guide](https://silo.pgsty.com/operations/concepts/erasure-coding/)
-- [Use `mc` with MinIO Server](https://silo.pgsty.com/reference/minio-mc/)
+- [Use `mc` with Silo Server](https://silo.pgsty.com/reference/minio-mc/)
-- [Use `aws-cli` with MinIO Server](https://silo.pgsty.com/integrations/aws-cli-with-minio/)
+- [Use `aws-cli` with Silo Server](https://silo.pgsty.com/integrations/aws-cli-with-minio/)
-- [Use `minio-go` SDK with MinIO Server](https://silo.pgsty.com/developers/go/minio-go/)
+- [Use `minio-go` SDK with Silo Server](https://silo.pgsty.com/developers/go/minio-go/)
-- [The MinIO documentation website](https://silo.pgsty.com/docs/)
+- [The Silo documentation website](https://silo.pgsty.com/docs/)

docs/distributed/SIZING.md

@@ -2,7 +2,7 @@
 
 ## Toy Setups
 
-Capacity constrained environments, MinIO will work but not recommended for production.
+Capacity constrained environments, Silo will work but not recommended for production.
 
 | servers | drives (per node) | stripe_size | parity chosen (default) | tolerance for reads (servers) | tolerance for writes (servers) |
 |--------:|------------------:|------------:|------------------------:|------------------------------:|-------------------------------:|

docs/docker/README.md

@@ -1,6 +1,7 @@
-# MinIO Docker Quickstart 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 Docker Quickstart Guide [![Docker Pulls](https://img.shields.io/docker/pulls/pgsty/silo.svg?maxAge=604800)](https://hub.docker.com/r/pgsty/silo/)
 
-See our web documentation on [Deploying MinIO in Standalone Mode](Deploy Standalone MinIO in a Container) for a more structured tutorial on deploying MinIO in a container.
+See the [Silo documentation](https://silo.pgsty.com/docs/) for production
+deployment and operations guidance.
 
 For images built from this `pgsty/minio` fork, the container also bundles `mcli` and a compatibility `mc` symlink from `pgsty/mc`.
 
@@ -8,11 +9,11 @@ For images built from this `pgsty/minio` fork, the container also bundles `mcli`
 
 Docker installed on your machine. Download the relevant installer from [here](https://www.docker.com/community-edition#/download).
 
-## Run Standalone MinIO on Docker
+## Run Standalone Silo on Docker
 
-*Note*: Standalone MinIO is intended for early development and evaluation. For production clusters, deploy a [Distributed](https://silo.pgsty.com/operations/deployments/baremetal-deploy-minio-as-a-container/) MinIO deployment.
+*Note*: Standalone Silo is intended for early development and evaluation. For production clusters, deploy a [Distributed](https://silo.pgsty.com/operations/deployments/baremetal-deploy-minio-as-a-container/) Silo deployment.
 
-MinIO needs a persistent volume to store configuration and application data. For testing purposes, you can launch MinIO by simply passing a directory (`/data` in the example below). This directory gets created in the container filesystem at the time of container start. But all the data is lost after container exits.
+Silo needs a persistent volume to store configuration and application data. For testing purposes, you can launch Silo by simply passing a directory (`/data` in the example below). This directory gets created in the container filesystem at the time of container start. But all the data is lost after container exits.
 
 ```sh
 docker run \
@@ -20,27 +21,29 @@ docker run \
   -p 9001:9001 \
   -e "MINIO_ROOT_USER=AKIAIOSFODNN7EXAMPLE" \
   -e "MINIO_ROOT_PASSWORD=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" \
-  quay.io/minio/minio server /data --console-address ":9001"
+  docker.io/pgsty/silo server /data --console-address ":9001"
 ```
 
-To create a MinIO container with persistent storage, you need to map local persistent directories from the host OS to virtual config. To do this, run the below commands
+To create a Silo container with persistent storage, you need to map local persistent directories from the host OS to virtual config. To do this, run the below commands
 
 ### GNU/Linux and macOS
 
 ```sh
-mkdir -p ~/minio/data
+mkdir -p ~/silo/data
 
 docker run \
   -p 9000:9000 \
   -p 9001:9001 \
-  --name minio1 \
+  --name silo1 \
-  -v ~/minio/data:/data \
+  -v ~/silo/data:/data \
   -e "MINIO_ROOT_USER=AKIAIOSFODNN7EXAMPLE" \
   -e "MINIO_ROOT_PASSWORD=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" \
-  quay.io/minio/minio server /data --console-address ":9001"
+  docker.io/pgsty/silo server /data --console-address ":9001"
 ```
 
-The command creates a new local directory `~/minio/data` in your user home directory. It then starts the MinIO container with the `-v` argument to map the local path (`~/minio/data`) to the specified virtual container directory (`/data`). When MinIO writes data to `/data`, that data is actually written to the local path `~/minio/data` where it can persist between container restarts.
+The command creates `~/silo/data` in your home directory and maps it to
+`/data` in the container. Data written to `/data` therefore persists in the
+host directory across container restarts.
 
 ### Windows
 
@@ -48,24 +51,26 @@ The command creates a new local directory `~/minio/data` in your user home direc
 docker run \
   -p 9000:9000 \
   -p 9001:9001 \
-  --name minio1 \
+  --name silo1 \
   -v D:\data:/data \
   -e "MINIO_ROOT_USER=AKIAIOSFODNN7EXAMPLE" \
   -e "MINIO_ROOT_PASSWORD=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" \
-  quay.io/minio/minio server /data --console-address ":9001"
+  docker.io/pgsty/silo server /data --console-address ":9001"
 ```
 
-## Run Distributed MinIO on Containers
+## Run Distributed Silo on Containers
 
-We recommend kubernetes based deployment for production level deployment <https://github.com/minio/operator>.
+For production, use the Silo Helm chart, Pigsty automation, or another
+deployment system that pins the image digest and preserves the documented
+`MINIO_*` compatibility configuration.
 
 See the [Kubernetes documentation](https://silo.pgsty.com/operations/deployments/kubernetes/) for more information.
 
-## MinIO Docker Tips
+## Silo Docker Tips
 
-### MinIO Custom Access and Secret Keys
+### Silo Custom Access and Secret Keys
 
-To override MinIO's auto-generated keys, you may pass secret and access keys explicitly as environment variables. MinIO server also allows regular strings as access and secret keys.
+To override Silo's auto-generated keys, you may pass secret and access keys explicitly as environment variables. Silo server also allows regular strings as access and secret keys.
 
 #### GNU/Linux and macOS (custom access and secret keys)
 
@@ -73,11 +78,11 @@ To override MinIO's auto-generated keys, you may pass secret and access keys exp
 docker run \
   -p 9000:9000 \
   -p 9001:9001 \
-  --name minio1 \
+  --name silo1 \
   -e "MINIO_ROOT_USER=AKIAIOSFODNN7EXAMPLE" \
   -e "MINIO_ROOT_PASSWORD=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" \
   -v /mnt/data:/data \
-  quay.io/minio/minio server /data --console-address ":9001"
+  docker.io/pgsty/silo server /data --console-address ":9001"
 ```
 
 #### Windows (custom access and secret keys)
@@ -86,14 +91,14 @@ docker run \
 docker run \
   -p 9000:9000 \
   -p 9001:9001 \
-  --name minio1 \
+  --name silo1 \
   -e "MINIO_ROOT_USER=AKIAIOSFODNN7EXAMPLE" \
   -e "MINIO_ROOT_PASSWORD=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" \
   -v D:\data:/data \
-  quay.io/minio/minio server /data --console-address ":9001"
+  docker.io/pgsty/silo server /data --console-address ":9001"
 ```
 
-### Run MinIO Docker as a regular user
+### Run Silo Docker as a regular user
 
 Docker provides standardized mechanisms to run docker containers as non-root users.
 
@@ -109,11 +114,11 @@ docker run \
   -p 9000:9000 \
   -p 9001:9001 \
   --user $(id -u):$(id -g) \
-  --name minio1 \
+  --name silo1 \
   -e "MINIO_ROOT_USER=AKIAIOSFODNN7EXAMPLE" \
   -e "MINIO_ROOT_PASSWORD=wJalrXUtnFEMIK7MDENGbPxRfiCYEXAMPLEKEY" \
   -v ${HOME}/data:/data \
-  quay.io/minio/minio server /data --console-address ":9001"
+  docker.io/pgsty/silo server /data --console-address ":9001"
 ```
 
 #### Windows (regular user)
@@ -126,42 +131,42 @@ On windows you would need to use [Docker integrated windows authentication](http
 docker run \
   -p 9000:9000 \
   -p 9001:9001 \
-  --name minio1 \
+  --name silo1 \
   --security-opt "credentialspec=file://myuser.json"
   -e "MINIO_ROOT_USER=AKIAIOSFODNN7EXAMPLE" \
   -e "MINIO_ROOT_PASSWORD=wJalrXUtnFEMIK7MDENGbPxRfiCYEXAMPLEKEY" \
   -v D:\data:/data \
-  quay.io/minio/minio server /data --console-address ":9001"
+  docker.io/pgsty/silo server /data --console-address ":9001"
 ```
 
-### MinIO Custom Access and Secret Keys using Docker secrets
+### Silo Custom Access and Secret Keys using Docker secrets
 
-To override MinIO's auto-generated keys, you may pass secret and access keys explicitly by creating access and secret keys as [Docker secrets](https://docs.docker.com/engine/swarm/secrets/). MinIO server also allows regular strings as access and secret keys.
+To override Silo's auto-generated keys, you may pass secret and access keys explicitly by creating access and secret keys as [Docker secrets](https://docs.docker.com/engine/swarm/secrets/). Silo server also allows regular strings as access and secret keys.
 
 ```
 echo "AKIAIOSFODNN7EXAMPLE" | docker secret create access_key -
 echo "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" | docker secret create secret_key -
 ```
 
-Create a MinIO service using `docker service` to read from Docker secrets.
+Create a Silo service using `docker service` to read from Docker secrets.
 
 ```
-docker service create --name="minio-service" --secret="access_key" --secret="secret_key" quay.io/minio/minio server /data
+docker service create --name="silo-service" --secret="access_key" --secret="secret_key" docker.io/pgsty/silo server /data
 ```
 
 Read more about `docker service` [here](https://docs.docker.com/engine/swarm/how-swarm-mode-works/services/)
 
-#### MinIO Custom Access and Secret Key files
+#### Silo Custom Access and Secret Key files
 
 To use other secret names follow the instructions above and replace `access_key` and `secret_key` with your custom names (e.g. `my_secret_key`,`my_custom_key`). Run your service with
 
 ```
-docker service create --name="minio-service" \
+docker service create --name="silo-service" \
   --secret="my_access_key" \
   --secret="my_secret_key" \
   --env="MINIO_ROOT_USER_FILE=my_access_key" \
   --env="MINIO_ROOT_PASSWORD_FILE=my_secret_key" \
-  quay.io/minio/minio server /data
+  docker.io/pgsty/silo server /data
 ```
 
 `MINIO_ROOT_USER_FILE` and `MINIO_ROOT_PASSWORD_FILE` also support custom absolute paths, in case Docker secrets are mounted to custom locations or other tools are used to mount secrets into the container. For example, HashiCorp Vault injects secrets to `/vault/secrets`. With the custom names above, set the environment variables to
@@ -195,17 +200,17 @@ To stop a running container, you can use the [`docker stop`](https://docs.docker
 docker stop <container_id>
 ```
 
-### MinIO container logs
+### Silo container logs
 
-To access MinIO logs, you can use the [`docker logs`](https://docs.docker.com/engine/reference/commandline/logs/) command.
+To access Silo logs, you can use the [`docker logs`](https://docs.docker.com/engine/reference/commandline/logs/) command.
 
 ```sh
 docker logs <container_id>
 ```
 
-### Monitor MinIO Docker Container
+### Monitor Silo Docker Container
 
-To monitor the resources used by MinIO container, you can use the [`docker stats`](https://docs.docker.com/engine/reference/commandline/stats/) command.
+To monitor the resources used by Silo container, you can use the [`docker stats`](https://docs.docker.com/engine/reference/commandline/stats/) command.
 
 ```sh
 docker stats <container_id>
@@ -213,5 +218,5 @@ docker stats <container_id>
 
 ## Explore Further
 
-* [MinIO in a Container Installation Guide](https://silo.pgsty.com/operations/deployments/baremetal-deploy-minio-as-a-container/)
+* [Silo in a Container Installation Guide](https://silo.pgsty.com/operations/deployments/baremetal-deploy-minio-as-a-container/)
-* [MinIO Erasure Code QuickStart Guide](https://silo.pgsty.com/operations/concepts/erasure-coding/)
+* [Silo Erasure Code QuickStart Guide](https://silo.pgsty.com/operations/concepts/erasure-coding/)

docs/erasure/README.md

@@ -1,18 +1,18 @@
-# MinIO Erasure Code Quickstart Guide [![Slack](https://slack.min.io/slack?type=svg)](https://slack.min.io)
+# Silo Erasure Code Quickstart Guide
 
-MinIO protects data against hardware failures and silent data corruption using erasure code and checksums. With the highest level of redundancy, you may lose up to half (N/2) of the total drives and still be able to recover the data.
+Silo protects data against hardware failures and silent data corruption using erasure code and checksums. With the highest level of redundancy, you may lose up to half (N/2) of the total drives and still be able to recover the data.
 
 ## What is Erasure Code?
 
-Erasure code is a mathematical algorithm to reconstruct missing or corrupted data. MinIO uses Reed-Solomon code to shard objects into variable data and parity blocks. For example, in a 12 drive setup, an object can be sharded to a variable number of data and parity blocks across all the drives - ranging from six data and six parity blocks to ten data and two parity blocks.
+Erasure code is a mathematical algorithm to reconstruct missing or corrupted data. Silo uses Reed-Solomon code to shard objects into variable data and parity blocks. For example, in a 12 drive setup, an object can be sharded to a variable number of data and parity blocks across all the drives - ranging from six data and six parity blocks to ten data and two parity blocks.
 
-By default, MinIO shards the objects across N/2 data and N/2 parity drives. Though, you can use [storage classes](https://github.com/pgsty/minio/tree/master/docs/erasure/storage-class) to use a custom configuration. We recommend N/2 data and parity blocks, as it ensures the best protection from drive failures.
+By default, Silo shards the objects across N/2 data and N/2 parity drives. Though, you can use [storage classes](https://github.com/pgsty/minio/tree/master/docs/erasure/storage-class) to use a custom configuration. We recommend N/2 data and parity blocks, as it ensures the best protection from drive failures.
 
-In 12 drive example above, with MinIO server running in the default configuration, you can lose any of the six drives and still reconstruct the data reliably from the remaining drives.
+In 12 drive example above, with Silo server running in the default configuration, you can lose any of the six drives and still reconstruct the data reliably from the remaining drives.
 
 ## Why is Erasure Code useful?
 
-Erasure code protects data from multiple drives failure, unlike RAID or replication. For example, RAID6 can protect against two drive failure whereas in MinIO erasure code you can lose as many as half of drives and still the data remains safe. Further, MinIO's erasure code is at the object level and can heal one object at a time. For RAID, healing can be done only at the volume level which translates into high downtime. As MinIO encodes each object individually, it can heal objects incrementally. Storage servers once deployed should not require drive replacement or healing for the lifetime of the server. MinIO's erasure coded backend is designed for operational efficiency and takes full advantage of hardware acceleration whenever available.
+Erasure code protects data from multiple drives failure, unlike RAID or replication. For example, RAID6 can protect against two drive failure whereas in Silo erasure code you can lose as many as half of drives and still the data remains safe. Further, Silo's erasure code is at the object level and can heal one object at a time. For RAID, healing can be done only at the volume level which translates into high downtime. As Silo encodes each object individually, it can heal objects incrementally. Storage servers once deployed should not require drive replacement or healing for the lifetime of the server. Silo's erasure coded backend is designed for operational efficiency and takes full advantage of hardware acceleration whenever available.
 
 ![Erasure](https://github.com/pgsty/minio/blob/master/docs/screenshots/erasure-code.jpg?raw=true)
 
@@ -20,37 +20,37 @@ Erasure code protects data from multiple drives failure, unlike RAID or replicat
 
 Bit Rot, also known as data rot or silent data corruption is a data loss issue faced by disk drives today. Data on the drive may silently get corrupted without signaling an error has occurred, making bit rot more dangerous than a permanent hard drive failure.
 
-MinIO's erasure coded backend uses high speed [HighwayHash](https://github.com/minio/highwayhash) checksums to protect against Bit Rot.
+Silo's erasure coded backend uses high speed [HighwayHash](https://github.com/minio/highwayhash) checksums to protect against Bit Rot.
 
 ## How are drives used for Erasure Code?
 
-MinIO divides the drives you provide into erasure-coding sets of *2 to 16* drives.  Therefore, the number of drives you present must be a multiple of one of these numbers.  Each object is written to a single erasure-coding set.
+Silo divides the drives you provide into erasure-coding sets of *2 to 16* drives.  Therefore, the number of drives you present must be a multiple of one of these numbers.  Each object is written to a single erasure-coding set.
 
-Minio uses the largest possible EC set size which divides into the number of drives given. For example, *18 drives* are configured as *2 sets of 9 drives*, and *24 drives* are configured as *2 sets of 12 drives*.  This is true for scenarios when running MinIO as a standalone erasure coded deployment. In [distributed setup however node (affinity) based](https://silo.pgsty.com/operations/deployments/baremetal/) erasure stripe sizes are chosen.
+Silo uses the largest possible EC set size which divides into the number of drives given. For example, *18 drives* are configured as *2 sets of 9 drives*, and *24 drives* are configured as *2 sets of 12 drives*.  This is true for scenarios when running Silo as a standalone erasure coded deployment. In [distributed setup however node (affinity) based](https://silo.pgsty.com/operations/deployments/baremetal/) erasure stripe sizes are chosen.
 
 The drives should all be of approximately the same size.
 
-## Get Started with MinIO in Erasure Code
+## Get Started with Silo in Erasure Code
 
 ### 1. Prerequisites
 
-Install MinIO - [MinIO Quickstart Guide](https://silo.pgsty.com/operations/deployments/baremetal-deploy-minio-on-redhat-linux/)
+Install Silo - [Silo Quickstart Guide](https://silo.pgsty.com/operations/deployments/baremetal-deploy-minio-on-redhat-linux/)
 
-### 2. Run MinIO Server with Erasure Code
+### 2. Run Silo Server with Erasure Code
 
-Example: Start MinIO server in a 12 drives setup, using MinIO binary.
+Example: Start Silo server in a 12 drives setup, using Silo binary.
 
 ```sh
-minio server /data{1...12}
+silo server /data{1...12}
 ```
 
-Example: Start MinIO server in a 8 drives setup, using MinIO Docker image.
+Example: Start Silo server in a 8 drives setup, using Silo Docker image.
 
 ```sh
 podman run \
   -p 9000:9000 \
   -p 9001:9001 \
-  --name minio \
+  --name silo \
   -v /mnt/data1:/data1 \
   -v /mnt/data2:/data2 \
   -v /mnt/data3:/data3 \
@@ -59,7 +59,7 @@ podman run \
   -v /mnt/data6:/data6 \
   -v /mnt/data7:/data7 \
   -v /mnt/data8:/data8 \
-  quay.io/minio/minio server /data{1...8} --console-address ":9001"
+  docker.io/pgsty/silo server /data{1...8} --console-address ":9001"
 ```
 
 ### 3. Test your setup

docs/erasure/storage-class/README.md

@@ -1,14 +1,14 @@
-# MinIO Storage Class Quickstart Guide [![Slack](https://slack.min.io/slack?type=svg)](https://slack.min.io)
+# Silo Storage Class Quickstart Guide
 
-MinIO server supports storage class in erasure coding mode. This allows configurable data and parity drives per object.
+Silo server supports storage class in erasure coding mode. This allows configurable data and parity drives per object.
 
-This page is intended as a summary of MinIO Erasure Coding. For a more complete explanation, see <https://silo.pgsty.com/operations/concepts/erasure-coding/>.
+This page is intended as a summary of Silo Erasure Coding. For a more complete explanation, see <https://silo.pgsty.com/operations/concepts/erasure-coding/>.
 
 ## Overview
 
-MinIO supports two storage classes, Reduced Redundancy class and Standard class. These classes can be defined using environment variables
+Silo supports two storage classes, Reduced Redundancy class and Standard class. These classes can be defined using environment variables
-set before starting MinIO server. After the data and parity drives for each storage class are defined using environment variables,
+set before starting Silo server. After the data and parity drives for each storage class are defined using environment variables,
-you can set the storage class of an object via request metadata field `x-amz-storage-class`. MinIO server then honors the storage class by
+you can set the storage class of an object via request metadata field `x-amz-storage-class`. Silo server then honors the storage class by
 saving the object in specific number of data and parity drives.
 
 ## Storage usage
@@ -17,11 +17,11 @@ The selection of varying data and parity drives has a direct impact on the drive
 redundancy or better drive space utilization.
 
 To get an idea of how various combinations of data and parity drives affect the storage usage, let’s take an example of a 100 MiB file stored
-on 16 drive MinIO deployment. If you use eight data and eight parity drives, the file space usage will be approximately twice, i.e. 100 MiB
+on 16 drive Silo deployment. If you use eight data and eight parity drives, the file space usage will be approximately twice, i.e. 100 MiB
 file will take 200 MiB space. But, if you use ten data and six parity drives, same 100 MiB file takes around 160 MiB. If you use 14 data and
 two parity drives, 100 MiB file takes only approximately 114 MiB.
 
-Below is a list of data/parity drives and corresponding _approximate_ storage space usage on a 16 drive MinIO deployment. The field _storage
+Below is a list of data/parity drives and corresponding _approximate_ storage space usage on a 16 drive Silo deployment. The field _storage
 usage ratio_ is simply the drive space used by the file after erasure-encoding, divided by actual file size.
 
 | Total Drives (N) | Data Drives (D) | Parity Drives (P) | Storage Usage Ratio |
@@ -53,7 +53,7 @@ The default value for the `STANDARD` storage class depends on the number of volu
 | 6-7              |                 EC:3  |
 | 8 or more        |                 EC:4  |
 
-For more complete documentation on Erasure Set sizing, see the [MinIO Documentation on Erasure Sets](https://silo.pgsty.com/operations/concepts/erasure-coding/#minio-ec-erasure-set).
+For more complete documentation on Erasure Set sizing, see the [Silo Documentation on Erasure Sets](https://silo.pgsty.com/operations/concepts/erasure-coding/#minio-ec-erasure-set).
 
 ### Allowed values for REDUCED_REDUNDANCY storage class
 
@@ -85,11 +85,11 @@ more details.
 
 #### Note
 
-- If `STANDARD` storage class is set via environment variables or `mc admin config` get/set commands, and `x-amz-storage-class` is not present in request metadata, MinIO server will
+- If `STANDARD` storage class is set via environment variables or `mc admin config` get/set commands, and `x-amz-storage-class` is not present in request metadata, Silo server will
 apply `STANDARD` storage class to the object. This means the data and parity drives will be used as set in `STANDARD` storage class.
 
-- If storage class is not defined before starting MinIO server, and subsequent PutObject metadata field has `x-amz-storage-class` present
+- If storage class is not defined before starting Silo server, and subsequent PutObject metadata field has `x-amz-storage-class` present
-with values `REDUCED_REDUNDANCY` or `STANDARD`, MinIO server uses default parity values.
+with values `REDUCED_REDUNDANCY` or `STANDARD`, Silo server uses default parity values.
 
 ### Set metadata
 

docs/extensions/fan-out/README.md

@@ -1,10 +1,10 @@
-# Fan-Out Uploads [![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/)
+# Fan-Out Uploads [![Docker Pulls](https://img.shields.io/docker/pulls/pgsty/silo.svg?maxAge=604800)](https://hub.docker.com/r/pgsty/silo/)
 
 ## Overview
 
-MinIO implements an S3 extension to perform multiple concurrent fan-out upload operations. A perfect use case scenario for performing fan-out operations of incoming TSB (Time Shift Buffer's). TSBs are a method of facilitating time-shifted playback of television signaling, and media content.
+Silo implements an S3 extension to perform multiple concurrent fan-out upload operations. A perfect use case scenario for performing fan-out operations of incoming TSB (Time Shift Buffer's). TSBs are a method of facilitating time-shifted playback of television signaling, and media content.
 
-MinIO implements an S3 extension to the [PostUpload](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectPOST.html) where in a special fan-out list is sent along with the TSB's for MinIO make multiple uploads from a single source stream. Optionally supports custom metadata, tags and other retention settings. All objects are also readable independently once upload is completed via the regular S3 [GetObject](https://docs.aws.amazon.com/AmazonS3/latest/API/API_GetObject.html) API.
+Silo implements an S3 extension to the [PostUpload](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectPOST.html) where in a special fan-out list is sent along with the TSB's for Silo make multiple uploads from a single source stream. Optionally supports custom metadata, tags and other retention settings. All objects are also readable independently once upload is completed via the regular S3 [GetObject](https://docs.aws.amazon.com/AmazonS3/latest/API/API_GetObject.html) API.
 
 ## How to enable Fan-Out Uploads ?
 

docs/extensions/s3zip/README.md

@@ -1,8 +1,8 @@
-# Perform S3 operations in a ZIP content[![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/)
+# Perform S3 operations in a ZIP content [![Docker Pulls](https://img.shields.io/docker/pulls/pgsty/silo.svg?maxAge=604800)](https://hub.docker.com/r/pgsty/silo/)
 
 ## Overview
 
-MinIO implements an S3 extension to list, stat and download files inside a ZIP file stored in any bucket. A perfect use case scenario is when you have a lot of small files archived in multiple ZIP files. Uploading them is faster than uploading small files individually. Besides, your S3 applications will be able to access to the data with little performance overhead.
+Silo implements an S3 extension to list, stat and download files inside a ZIP file stored in any bucket. A perfect use case scenario is when you have a lot of small files archived in multiple ZIP files. Uploading them is faster than uploading small files individually. Besides, your S3 applications will be able to access to the data with little performance overhead.
 
 The main limitation is that to update or delete content of a file inside a ZIP file the entire ZIP file must be replaced.
 

docs/federation/lookup/README.md

@@ -1,14 +1,14 @@
-# Federation Quickstart Guide [![Slack](https://slack.min.io/slack?type=svg)](https://slack.min.io) *Federation feature is deprecated and should be avoided for future deployments*
+# Federation Quickstart Guide *Federation feature is deprecated and should be avoided for future deployments*
 
-This document explains how to configure MinIO with `Bucket lookup from DNS` style federation.
+This document explains how to configure Silo with `Bucket lookup from DNS` style federation.
 
 ## Get started
 
 ### 1. Prerequisites
 
-Install MinIO - [MinIO Quickstart Guide](https://silo.pgsty.com/operations/deployments/baremetal-deploy-minio-on-redhat-linux/).
+Install Silo - [Silo Quickstart Guide](https://silo.pgsty.com/operations/deployments/baremetal-deploy-minio-on-redhat-linux/).
 
-### 2. Run MinIO in federated mode
+### 2. Run Silo in federated mode
 
 Bucket lookup from DNS federation requires two dependencies
 
@@ -17,32 +17,40 @@ Bucket lookup from DNS federation requires two dependencies
 
 ## Architecture
 
-![bucket-lookup](https://github.com/pgsty/minio/blob/master/docs/federation/lookup/bucket-lookup.png?raw=true)
+```mermaid
+flowchart LR
+    app["Application requests bucket.example.net"] --> dns["CoreDNS"]
+    dns --> registry["etcd bucket records"]
+    registry --> cluster1["Silo cluster 1"]
+    registry --> cluster2["Silo cluster 2"]
+    registry --> clustern["Silo cluster n"]
+    dns --> app
+```
 
 ### Environment variables
 
 #### MINIO_ETCD_ENDPOINTS
 
-This is comma separated list of etcd servers that you want to use as the MinIO federation back-end. This should
+This is comma separated list of etcd servers that you want to use as the Silo federation back-end. This should
-be same across the federated deployment, i.e. all the MinIO instances within a federated deployment should use same
+be same across the federated deployment, i.e. all the Silo instances within a federated deployment should use same
 etcd back-end.
 
 #### MINIO_DOMAIN
 
 This is the top level domain name used for the federated setup. This domain name should ideally resolve to a load-balancer
-running in front of all the federated MinIO instances. The domain name is used to create sub domain entries to etcd. For
+running in front of all the federated Silo instances. The domain name is used to create sub domain entries to etcd. For
 example, if the domain is set to `domain.com`, the buckets `bucket1`, `bucket2` will be accessible as `bucket1.domain.com`
 and `bucket2.domain.com`.
 
 #### MINIO_PUBLIC_IPS
 
-This is comma separated list of IP addresses to which buckets created on this MinIO instance will resolve to. For example,
+This is comma separated list of IP addresses to which buckets created on this Silo instance will resolve to. For example,
-a bucket `bucket1` created on current MinIO instance will be accessible as `bucket1.domain.com`, and the DNS entry for
+a bucket `bucket1` created on current Silo instance will be accessible as `bucket1.domain.com`, and the DNS entry for
 `bucket1.domain.com` will point to IP address set in `MINIO_PUBLIC_IPS`.
 
-- This field is mandatory for standalone and erasure code MinIO server deployments, to enable federated mode.
+- This field is mandatory for standalone and erasure code Silo server deployments, to enable federated mode.
 - This field is optional for distributed deployments. If you don't set this field in a federated setup, we use the IP addresses of
-hosts passed to the MinIO server startup and use them for DNS entries.
+hosts passed to the Silo server startup and use them for DNS entries.
 
 ### Run Multiple Clusters
 
@@ -52,7 +60,7 @@ hosts passed to the MinIO server startup and use them for DNS entries.
 export MINIO_ETCD_ENDPOINTS="http://remote-etcd1:2379,http://remote-etcd2:4001"
 export MINIO_DOMAIN=domain.com
 export MINIO_PUBLIC_IPS=44.35.2.1,44.35.2.2,44.35.2.3,44.35.2.4
-minio server http://rack{1...4}.host{1...4}.domain.com/mnt/export{1...32}
+silo server http://rack{1...4}.host{1...4}.domain.com/mnt/export{1...32}
 ```
 
 > cluster2
@@ -61,10 +69,10 @@ minio server http://rack{1...4}.host{1...4}.domain.com/mnt/export{1...32}
 export MINIO_ETCD_ENDPOINTS="http://remote-etcd1:2379,http://remote-etcd2:4001"
 export MINIO_DOMAIN=domain.com
 export MINIO_PUBLIC_IPS=44.35.1.1,44.35.1.2,44.35.1.3,44.35.1.4
-minio server http://rack{5...8}.host{5...8}.domain.com/mnt/export{1...32}
+silo server http://rack{5...8}.host{5...8}.domain.com/mnt/export{1...32}
 ```
 
-In this configuration you can see `MINIO_ETCD_ENDPOINTS` points to the etcd backend which manages MinIO's
+In this configuration you can see `MINIO_ETCD_ENDPOINTS` points to the etcd backend which manages Silo's
 `config.json` and bucket DNS SRV records. `MINIO_DOMAIN` indicates the domain suffix for the bucket which
 will be used to resolve bucket through DNS. For example if you have a bucket such as `mybucket`, the
 client can use now `mybucket.domain.com` to directly resolve itself to the right cluster. `MINIO_PUBLIC_IPS`
@@ -76,11 +84,11 @@ it is randomized which cluster might provision the bucket.
 
 ### 3. Test your setup
 
-To test this setup, access the MinIO server via browser or [`mc`](https://silo.pgsty.com/reference/minio-mc/#quickstart). You’ll see the uploaded files are accessible from the all the MinIO endpoints.
+To test this setup, access the Silo server via browser or [`mc`](https://silo.pgsty.com/reference/minio-mc/#quickstart). You’ll see the uploaded files are accessible from the all the Silo endpoints.
 
 ## Explore Further
 
-- [Use `mc` with MinIO Server](https://silo.pgsty.com/reference/minio-mc/)
+- [Use `mc` with Silo Server](https://silo.pgsty.com/reference/minio-mc/)
-- [Use `aws-cli` with MinIO Server](https://silo.pgsty.com/integrations/aws-cli-with-minio/)
+- [Use `aws-cli` with Silo Server](https://silo.pgsty.com/integrations/aws-cli-with-minio/)
-- [Use `minio-go` SDK with MinIO Server](https://silo.pgsty.com/developers/go/minio-go/)
+- [Use `minio-go` SDK with Silo Server](https://silo.pgsty.com/developers/go/minio-go/)
-- [The MinIO documentation website](https://silo.pgsty.com/docs/)
+- [The Silo documentation website](https://silo.pgsty.com/docs/)

docs/ftp/README.md

@@ -1,6 +1,6 @@
-# MinIO FTP/SFTP Server
+# Silo FTP/SFTP Server
 
-MinIO natively supports FTP/SFTP protocol, this allows any ftp/sftp client to upload and download files.
+Silo natively supports FTP/SFTP protocol, this allows any ftp/sftp client to upload and download files.
 
 Currently supported `FTP/SFTP` operations are as follows:
 
@@ -15,7 +15,7 @@ Currently supported `FTP/SFTP` operations are as follows:
 | append              | no        |
 | rename              | no        |
 
-MinIO supports following FTP/SFTP based protocols to access and manage data.
+Silo supports following FTP/SFTP based protocols to access and manage data.
 
 - Secure File Transfer Protocol (SFTP) – Defined by the Internet Engineering Task Force (IETF) as an
   extended version of SSH 2.0, allowing file transfer over SSH and for use with Transport Layer
@@ -41,7 +41,8 @@ MinIO supports following FTP/SFTP based protocols to access and manage data.
   - OpenID/OIDC service accounts
 
 - On versioned buckets, FTP/SFTP only operates on latest objects, if you need to retrieve
-  an older version you must use an `S3 API client` such as [`mc`](https://github.com/minio/mc).
+  an older version you must use an S3 API client such as the compatible
+  [`mc`](https://github.com/pgsty/mc) client.
 
 - All features currently used by your buckets will work as is without any changes
   - SSE (Server Side Encryption)
@@ -58,10 +59,10 @@ MinIO supports following FTP/SFTP based protocols to access and manage data.
 
 ## Usage
 
-Start MinIO in a distributed setup, with 'ftp/sftp' enabled.
+Start Silo in a distributed setup, with 'ftp/sftp' enabled.
 
 ```
-minio server http://server{1...4}/disk{1...4}
+silo server http://server{1...4}/disk{1...4}
    --ftp="address=:8021" --ftp="passive-port-range=30000-40000" \
    --sftp="address=:8022" --sftp="ssh-private-key=/home/miniouser/.ssh/id_rsa"
 ...
@@ -73,7 +74,7 @@ Following example shows connecting via ftp client using `minioadmin` credentials
 ```
 ftp localhost -P 8021
 Connected to localhost.
-220 Welcome to MinIO FTP Server
+220 Welcome to Silo FTP Server
 Name (localhost:user): minioadmin
 331 User name ok, password required
 Password:
@@ -163,7 +164,7 @@ Unlike SFTP server, FTP server is insecure by default. To operate under TLS mode
 --ftp="tls-private-key=path/to/private.key" --ftp="tls-public-cert=path/to/public.crt"
 ```
 
-> NOTE: if MinIO distributed setup is already configured to run under TLS, FTP will automatically use the relevant
+> NOTE: if Silo distributed setup is already configured to run under TLS, FTP will automatically use the relevant
 > certs from the server certificate chain, this is mainly to add simplicity of setup. However if you wish to terminate
 > TLS certificates via a different domain for your FTP servers you may choose the above command line options.
 

docs/iam/access-management-plugin.md

@@ -1,10 +1,10 @@
 # Access Management Plugin Guide [![Slack](https://slack.minio.io/slack?type=svg)](https://slack.minio.io)
 
-MinIO now includes support for using an Access Management Plugin. This is to allow object storage access control to be managed externally via a webhook.
+Silo now includes support for using an Access Management Plugin. This is to allow object storage access control to be managed externally via a webhook.
 
-When configured, MinIO sends request and credential details for every API call to an external HTTP(S) endpoint and expects an allow/deny response. MinIO is thus able to delegate access management to an external system, and users are able to use a custom solution instead of S3 standard IAM policies.
+When configured, Silo sends request and credential details for every API call to an external HTTP(S) endpoint and expects an allow/deny response. Silo is thus able to delegate access management to an external system, and users are able to use a custom solution instead of S3 standard IAM policies.
 
-Latency sensitive applications may notice an increased latency due to a request to the external plugin upon every authenticated request to MinIO. User are advised to provision their infrastructure such that latency and performance is acceptable.
+Latency sensitive applications may notice an increased latency due to a request to the external plugin upon every authenticated request to Silo. User are advised to provision their infrastructure such that latency and performance is acceptable.
 
 ## Quickstart
 
@@ -16,27 +16,27 @@ go run access-manager-plugin.go
 
 This program, lets the admin user perform any action and prevents all other users from performing `s3:Put*` operations.
 
-In another terminal start MinIO:
+In another terminal start Silo:
 
 ```sh
 export MINIO_CI_CD=1
 export MINIO_ROOT_USER=minio
-export MINIO_ROOT_PASSWORD=minio123
+export MINIO_ROOT_PASSWORD=silo123
 export MINIO_POLICY_PLUGIN_URL=http://localhost:8080/
-minio server /tmp/disk{1...4}
+silo server /tmp/disk{1...4}
 ```
 
 Now, let's test it out with `mc`:
 
 ```sh
-mc alias set myminio http://localhost:9000 minio minio123
+mc alias set mysilo http://localhost:9000 minio silo123
-mc ls myminio
+mc ls mysilo
-mc mb myminio/test
+mc mb mysilo/test
-mc cp /etc/issue myminio/test
+mc cp /etc/issue mysilo/test
-mc admin user add myminio foo foobar123
+mc admin user add mysilo foo foobar123
 export MC_HOST_foo=http://foo:foobar123@localhost:9000
 mc ls foo
-mc cp /etc/issue myminio/test/issue2
+mc cp /etc/issue mysilo/test/issue2
 ```
 
 Only the last operation would fail with a permissions error.
@@ -46,7 +46,7 @@ Only the last operation would fail with a permissions error.
 Access Management Plugin can be configured with environment variables:
 
 ```sh
-$ mc admin config set myminio policy_plugin --env
+$ mc admin config set mysilo policy_plugin --env
 KEY:
 policy_plugin  enable Access Management Plugin for policy enforcement
 
@@ -61,7 +61,7 @@ By default this plugin uses HTTP 1.x. To enable HTTP2 use the `MINIO_POLICY_PLUG
 
 ## Request and Response
 
-MinIO will make a `POST` request with a JSON body to the given plugin URL. If the auth token parameter is set, it will be sent as an authorization header.
+Silo will make a `POST` request with a JSON body to the given plugin URL. If the auth token parameter is set, it will be sent as an authorization header.
 
 The JSON body structure can be seen from this sample:
 
@@ -100,10 +100,10 @@ The JSON body structure can be seen from this sample:
         "127.0.0.1"
       ],
       "User-Agent": [
-        "MinIO (linux; amd64) minio-go/v7.0.24 mc/DEVELOPMENT.2022-04-20T23-07-53Z"
+        "Silo (linux; amd64) minio-go/v7.0.24 mc/DEVELOPMENT.2022-04-20T23-07-53Z"
       ],
       "UserAgent": [
-        "MinIO (linux; amd64) minio-go/v7.0.24 mc/DEVELOPMENT.2022-04-20T23-07-53Z"
+        "Silo (linux; amd64) minio-go/v7.0.24 mc/DEVELOPMENT.2022-04-20T23-07-53Z"
       ],
       "X-Amz-Content-Sha256": [
         "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
@@ -137,7 +137,7 @@ The JSON body structure can be seen from this sample:
 
 </details>
 
-The response expected by MinIO, is a JSON body with a boolean:
+The response expected by Silo, is a JSON body with a boolean:
 
 ```json
 {

docs/iam/identity-management-plugin.md

@@ -2,14 +2,14 @@
 
 ## Introduction
 
-To enable the integration of custom authentication methods, MinIO can be configured with an Identity Management Plugin webhook. When configured, this plugin enables the `AssumeRoleWithCustomToken` STS API extension. A user or application can now present a token to the `AssumeRoleWithCustomToken` API, and MinIO verifies this token by sending it to the Identity Management Plugin webhook. This plugin responds with some information and MinIO is able to generate temporary STS credentials to interact with object storage.
+To enable the integration of custom authentication methods, Silo can be configured with an Identity Management Plugin webhook. When configured, this plugin enables the `AssumeRoleWithCustomToken` STS API extension. A user or application can now present a token to the `AssumeRoleWithCustomToken` API, and Silo verifies this token by sending it to the Identity Management Plugin webhook. This plugin responds with some information and Silo is able to generate temporary STS credentials to interact with object storage.
 
-The authentication flow is similar to that of OpenID, however the token is "opaque" to MinIO - it is simply sent to the plugin for verification. CAVEAT: There is no console UI integration for this method of authentication and it is intended primarily for machine authentication.
+The authentication flow is similar to that of OpenID, however the token is "opaque" to Silo - it is simply sent to the plugin for verification. CAVEAT: There is no console UI integration for this method of authentication and it is intended primarily for machine authentication.
 
-It can be configured via MinIO's standard configuration API (i.e. using `mc admin config set/get`), or equivalently with environment variables. For brevity we show only environment variables here:
+It can be configured via Silo's standard configuration API (i.e. using `mc admin config set/get`), or equivalently with environment variables. For brevity we show only environment variables here:
 
 ```sh
-$ mc admin config set myminio identity_plugin --env
+$ mc admin config set mysilo identity_plugin --env
 KEY:
 identity_plugin  enable Identity Plugin via external hook
 
@@ -25,11 +25,11 @@ If provided, the auth token parameter is sent as an authorization header.
 
 `MINIO_IDENTITY_PLUGIN_ROLE_POLICY` is a required parameter and can be list of comma separated policy names.
 
-On setting up the plugin, the MinIO server prints the Role ARN to its log. The Role ARN is generated by default based on the given plugin URL. To avoid this and use a configurable value set a unique role ID via `MINIO_IDENTITY_PLUGIN_ROLE_ID`.
+On setting up the plugin, the Silo server prints the Role ARN to its log. The Role ARN is generated by default based on the given plugin URL. To avoid this and use a configurable value set a unique role ID via `MINIO_IDENTITY_PLUGIN_ROLE_ID`.
 
 ## REST API call to plugin
 
-To verify the custom token presented in the `AssumeRoleWithCustomToken` API, MinIO makes a POST request to the configured identity management plugin endpoint and expects a response with some details as shown below:
+To verify the custom token presented in the `AssumeRoleWithCustomToken` API, Silo makes a POST request to the configured identity management plugin endpoint and expects a response with some details as shown below:
 
 ### Request `POST` to plugin endpoint
 
@@ -59,7 +59,7 @@ A `200 OK` Response should have `application/json` content-type and body with th
 | maxValiditySeconds | integer (>= 900 seconds and < 365 days) | Maximum allowed expiry duration for the credentials    |
 | claims             | key-value pairs                         | Claims to be associated with the requested credentials |
 
-The keys "exp", "parent" and "sub" in the `claims` object are reserved and if present are ignored by MinIO.
+The keys "exp", "parent" and "sub" in the `claims` object are reserved and if present are ignored by Silo.
 
 If the token is not valid or access is not approved, the plugin must return a `403` (forbidden) HTTP status code. The body must have an `application/json` content-type with the following structure:
 

docs/iam/opa.md

@@ -1,8 +1,8 @@
 # OPA Quickstart Guide [![Slack](https://slack.minio.io/slack?type=svg)](https://slack.minio.io)
 
-OPA is a lightweight general-purpose policy engine that can be co-located with MinIO server, in this document we talk about how to use OPA HTTP API to authorize requests. It can be used with any type of credentials (STS based like OpenID or LDAP, regular IAM users or service accounts).
+OPA is a lightweight general-purpose policy engine that can be co-located with Silo server, in this document we talk about how to use OPA HTTP API to authorize requests. It can be used with any type of credentials (STS based like OpenID or LDAP, regular IAM users or service accounts).
 
-OPA is enabled through MinIO's Access Management Plugin feature.
+OPA is enabled through Silo's Access Management Plugin feature.
 
 ## Get started
 
@@ -51,27 +51,27 @@ curl -X PUT --data-binary @example.rego \
   localhost:8181/v1/policies/putobject
 ```
 
-### 4. Setup MinIO with OPA
+### 4. Setup Silo with OPA
 
-Set the `MINIO_POLICY_PLUGIN_URL` as the endpoint that MinIO should send authorization requests to. Then start the server.
+Set the `MINIO_POLICY_PLUGIN_URL` as the endpoint that Silo should send authorization requests to. Then start the server.
 
 ```sh
 export MINIO_POLICY_PLUGIN_URL=http://localhost:8181/v1/data/httpapi/authz/allow
 export MINIO_CI_CD=1
 export MINIO_ROOT_USER=minio
-export MINIO_ROOT_PASSWORD=minio123
+export MINIO_ROOT_PASSWORD=silo123
-minio server /mnt/data
+silo server /mnt/data
 ```
 
 ### 5. Test with a regular IAM user
 
-Ensure that `mc` is installed and the configured with the above server with the alias `myminio`.
+Ensure that `mc` is installed and the configured with the above server with the alias `mysilo`.
 
 ```sh
 # 1. Create a bucket and a user, and upload a file. These operations will succeed.
-mc mb myminio/test
+mc mb mysilo/test
-mc admin user add myminio foo foobar123
+mc admin user add mysilo foo foobar123
-mc cp /etc/issue myminio/test/
+mc cp /etc/issue mysilo/test/
 
 # 2. Now access the server as user `foo`. These operations will also succeed.
 export MC_HOST_foo=http://foo:foobar123@localhost:9000
@@ -79,5 +79,5 @@ mc ls foo/test
 mc cat foo/test/issue
 
 # 3. Attempt to upload an object as user `foo` - this will fail with a permissions error.
-mc cp /etc/issue myminio/test/issue2
+mc cp /etc/issue mysilo/test/issue2
 ```

docs/integrations/veeam/README.md

@@ -1,14 +1,14 @@
-# Using MinIO with Veeam
+# Using Silo with Veeam
 
-When using Veeam Backup and Replication, you can use S3 compatible object storage such as MinIO as a capacity tier for backups.  This disaggregates storage for the Veeam infrastructure and allows you to retain control of your data. With the ease of use of setup and administration of MinIO, it allows a Veeam backup admin to easily deploy their own object store for capacity tiering.
+When using Veeam Backup and Replication, you can use S3 compatible object storage such as Silo as a capacity tier for backups.  This disaggregates storage for the Veeam infrastructure and allows you to retain control of your data. With the ease of use of setup and administration of Silo, it allows a Veeam backup admin to easily deploy their own object store for capacity tiering.
 
 ## Prerequisites
 
 - One or both of Veeam Backup and Replication with support for S3 compatible object store (e.g. 9.5.4) and Veeam Backup for Office365 (VBO)
-- MinIO object storage set up per <https://silo.pgsty.com/docs/>
+- Silo object storage set up per <https://silo.pgsty.com/docs/>
 - Veeam requires TLS connections to the object storage.  This can be configured per <https://silo.pgsty.com/operations/network-encryption/>
 - The S3 bucket, Access Key and Secret Key have to be created before and outside of Veeam.
-- Configure the minio client for the Veeam MinIO endpoint - <https://silo.pgsty.com/operations/deployments/baremetal-deploy-minio-on-redhat-linux/>
+- Configure the compatible `mc` client for the Veeam Silo endpoint - <https://silo.pgsty.com/operations/deployments/baremetal-deploy-minio-on-redhat-linux/>
 
 ## Setting up an S3 compatible object store for Veeam Backup and Replication
 
@@ -17,20 +17,20 @@ When using Veeam Backup and Replication, you can use S3 compatible object storag
 Create a bucket for Veeam Backup, e.g.,
 
 ```
-mc mb myminio/veeambackup
+mc mb mysilo/veeambackup
 ```
 
 > NOTE: For Veeam Backup with Immutability, create the bucket with object lock enabled, e.g.,
 
 ```
-mc mb -l myminio/veeambackup
+mc mb -l mysilo/veeambackup
 ```
 
-> Object locking requires erasure coding enabled on the minio server. For more information see <https://silo.pgsty.com/operations/concepts/erasure-coding/>.
+> Object locking requires erasure coding enabled on the silo server. For more information see <https://silo.pgsty.com/operations/concepts/erasure-coding/>.
 
-### Add MinIO as an object store for Veeam
+### Add Silo as an object store for Veeam
 
-Follow the steps from the Veeam documentation for adding MinIO as an object store - <https://helpcenter.veeam.com/docs/backup/vsphere/adding_s3c_object_storage.html?ver=100>
+Follow the steps from the Veeam documentation for adding Silo as an object store - <https://helpcenter.veeam.com/docs/backup/vsphere/adding_s3c_object_storage.html?ver=100>
 
 For Veeam Backup with Immutability, choose the amount of days you want to make backups immutable for
 
@@ -65,7 +65,7 @@ For Veeam Backup with Immutability, choose the amount of days you want to make b
 - Create a new bucket for VBO backups
 
 ```
-mc mb -l myminio/vbo
+mc mb -l mysilo/vbo
 ```
 
 - Under Backup Infrastructure, right click on Object Storage Repositories and choose "Add object storage"
@@ -76,7 +76,7 @@ mc mb -l myminio/vbo
 
 - Under Backup Infrastructure -> Backup Repositories, right click and "Add Backup Repository"
 
-- Follow the wizard.  Under the "Object Storage Backup Repository" section, choose the MinIO object storage you created above
+- Follow the wizard.  Under the "Object Storage Backup Repository" section, choose the Silo object storage you created above
 
 ![Adding Object Storage to VBO Backup Repository](https://raw.githubusercontent.com/pgsty/minio/master/docs/integrations/veeam/screenshots/6_add_sobr_with_object_store.png)
 
@@ -84,10 +84,10 @@ mc mb -l myminio/vbo
 
 ## Test the setup
 
-The next time the backup job runs, you can use the  `mc admin trace myminio` command and verify traffic is flowing to the MinIO nodes. For Veeam Backup and Replication you will need to wait for the backup to complete to the performance tier before it migrates data to the capacity tier (i.e., MinIO).
+The next time the backup job runs, you can use the  `mc admin trace mysilo` command and verify traffic is flowing to the Silo nodes. For Veeam Backup and Replication you will need to wait for the backup to complete to the performance tier before it migrates data to the capacity tier (i.e., Silo).
 
 ```
-20:09:10.216 [200 OK] s3.GetObject veeam-minio01:9000/vbo/Veeam/Backup365/vbotest/Organizations/6571606ecbc4455dbfe23b83f6f45597/Webs/ca2d0986229b4ec88e3a217ef8f04a1d/Items/efaa67764b304e77badb213d131beab6/f4f0cf600f494c3eb702d8eafe0fabcc.aac07493e6cd4c71845d2495a4e1e19b 139.178.68.158    9.789ms      ↑ 90 B ↓ 8.5 KiB
+20:09:10.216 [200 OK] s3.GetObject veeam-silo01:9000/vbo/Veeam/Backup365/vbotest/Organizations/6571606ecbc4455dbfe23b83f6f45597/Webs/ca2d0986229b4ec88e3a217ef8f04a1d/Items/efaa67764b304e77badb213d131beab6/f4f0cf600f494c3eb702d8eafe0fabcc.aac07493e6cd4c71845d2495a4e1e19b 139.178.68.158    9.789ms      ↑ 90 B ↓ 8.5 KiB
-20:09:10.244 [200 OK] s3.GetObject veeam-minio01:9000/vbo/Veeam/Backup365/vbotest/RepositoryLock/cad99aceb50c49ecb9e07246c3b9fadc_bfd985e5deec4cebaf481847f2c34797 139.178.68.158    16.21ms      ↑ 90 B ↓ 402 B
+20:09:10.244 [200 OK] s3.GetObject veeam-silo01:9000/vbo/Veeam/Backup365/vbotest/RepositoryLock/cad99aceb50c49ecb9e07246c3b9fadc_bfd985e5deec4cebaf481847f2c34797 139.178.68.158    16.21ms      ↑ 90 B ↓ 402 B
-20:09:10.283 [200 OK] s3.PutObject veeam-minio01:9000/vbo/Veeam/Backup365/vbotest/CommonInfo/WebRestorePoints/18f1aba8f55f4ac6b805c4de653eb781 139.178.68.158    29.787ms     ↑ 1005 B ↓ 296 B
+20:09:10.283 [200 OK] s3.PutObject veeam-silo01:9000/vbo/Veeam/Backup365/vbotest/CommonInfo/WebRestorePoints/18f1aba8f55f4ac6b805c4de653eb781 139.178.68.158    29.787ms     ↑ 1005 B ↓ 296 B
 ```

docs/kms/IAM.md

@@ -1,12 +1,12 @@
 # KMS IAM/Config Encryption
 
-MinIO supports encrypting config, IAM assets with KMS provided keys. If the KMS is not enabled, MinIO will store the config, IAM data as plain text erasure coded in its backend.
+Silo supports encrypting config, IAM assets with KMS provided keys. If the KMS is not enabled, Silo will store the config, IAM data as plain text erasure coded in its backend.
 
-## MinIO KMS Quick Start
+## Silo KMS Quick Start
 
-MinIO supports two ways of encrypting IAM and configuration data.
+Silo supports two ways of encrypting IAM and configuration data.
 You can either use KES - together with an external KMS - or, much simpler,
-set the env. variable `MINIO_KMS_SECRET_KEY` and start/restart the MinIO server. For more details about KES and how
+set the env. variable `MINIO_KMS_SECRET_KEY` and start/restart the Silo server. For more details about KES and how
 to set it up refer to our [KMS Guide](https://github.com/pgsty/minio/blob/master/docs/kms/README.md).
 
 Instead of configuring an external KMS you can start with a single key by
@@ -33,7 +33,7 @@ export MINIO_KMS_SECRET_KEY=my-minio-key:OSMM+vkKUTCvQs9YL/CVMIMt43HFhkUpqJxTmGl
 > You can choose an arbitrary name for the key - instead of `my-minio-key`.
 > Please note that losing the `MINIO_KMS_SECRET_KEY` will cause data loss
 > since you will not be able to decrypt the IAM/configuration data anymore.
-For distributed MinIO deployments, specify the *same* `MINIO_KMS_SECRET_KEY` for each MinIO server process.
+For distributed Silo deployments, specify the *same* `MINIO_KMS_SECRET_KEY` for each Silo server process.
 
 At any point in time you can switch from `MINIO_KMS_SECRET_KEY` to a full KMS
 deployment. You just need to import the generated key into KES - for example via
@@ -45,7 +45,7 @@ kes key create my-minio-key OSMM+vkKUTCvQs9YL/CVMIMt43HFhkUpqJxTmGl6rYw=
 
 - For instructions on setting up KES, see the [KES Getting Started guide](https://github.com/minio/kes/wiki/Getting-Started)
 
-- For instructions on using KES for encrypting the MinIO backend, follow the [KMS Quick Start](https://github.com/pgsty/minio/tree/master/docs/kms). The SSE-S3 configuration setup also supports MinIO KMS backend encryption.
+- For instructions on using KES for encrypting the Silo backend, follow the [KMS Quick Start](https://github.com/pgsty/minio/tree/master/docs/kms). The SSE-S3 configuration setup also supports Silo KMS backend encryption.
 
 ## FAQ
 
@@ -53,14 +53,14 @@ kes key create my-minio-key OSMM+vkKUTCvQs9YL/CVMIMt43HFhkUpqJxTmGl6rYw=
 
 Before, there were two separate mechanisms - S3 objects got encrypted using a KMS,
 if present, and the IAM / configuration data got encrypted with the root credentials.
-Now, MinIO encrypts IAM / configuration and S3 objects with a KMS, if present. This
+Now, Silo encrypts IAM / configuration and S3 objects with a KMS, if present. This
-change unified the key-management aspect within MinIO.
+change unified the key-management aspect within Silo.
 
 The unified KMS-based approach has several advantages:
 
 - Key management is now centralized. There is one way to change or rotate encryption keys.
    There used to be two different mechanisms - one for regular S3 objects and one for IAM data.
-- Reduced server startup time. For IAM encryption with the root credentials, MinIO had
+- Reduced server startup time. For IAM encryption with the root credentials, Silo had
    to use a memory-hard function (Argon2) that (on purpose) consumes a lot of memory and CPU.
    The new KMS-based approach can use a key derivation function that is orders of magnitudes
    cheaper w.r.t. memory and CPU.
@@ -70,20 +70,20 @@ The unified KMS-based approach has several advantages:
    and the old credentials had to be removed once the rotation completed. This process is now gone.
    The root credentials can now be changed easily.
 
-> Does this mean I need an enterprise KMS setup to run MinIO (securely)?
+> Does this mean I need an enterprise KMS setup to run Silo (securely)?
 
-No, MinIO does not depend on any third-party KMS provider. You have three options here:
+No, Silo does not depend on any third-party KMS provider. You have three options here:
 
-- Run MinIO without a KMS. In this case all IAM data will be stored in plain-text.
+- Run Silo without a KMS. In this case all IAM data will be stored in plain-text.
-- Run MinIO with a single secret key. MinIO supports a static cryptographic key
+- Run Silo with a single secret key. Silo supports a static cryptographic key
   that can act as minimal KMS. With this method all IAM data will be stored
   encrypted. The encryption key has to be passed as environment variable.
-- Run MinIO with KES (minio/kes) in combination with any supported KMS as
+- Run Silo with KES (minio/kes) in combination with any supported KMS as
-  secure key store. For example, you can run MinIO + KES + Hashicorp Vault.
+  secure key store. For example, you can run Silo + KES + Hashicorp Vault.
 
-> What about an exiting MinIO deployment? Can I just upgrade my cluster?
+> What about an exiting Silo deployment? Can I just upgrade my cluster?
 
-Yes, MinIO will try to transparently migrate any existing IAM data and either stores
+Yes, Silo will try to transparently migrate any existing IAM data and either stores
 it in plaintext (no KMS) or re-encrypts using the KMS.
 
 > Is this change backward compatible? Will it break my setup?
@@ -93,7 +93,7 @@ Hashicorp Vault integration - which has been deprecated already - won't be
 supported anymore. KES is now mandatory if a third-party KMS should be used.
 
 Further, since the configuration data is encrypted with the KMS, the KMS
-configuration itself can no longer be stored in the MinIO config file and
+configuration itself can no longer be stored in the Silo config file and
 instead must be provided via environment variables. If you have set your KMS
 configuration using e.g. the `mc admin config` commands you will need to adjust
 your deployment.
@@ -101,9 +101,9 @@ your deployment.
 Even though this change is backward compatible we do not expect that it affects
 the vast majority of deployments in any negative way.
 
-> Will an upgrade of an existing MinIO cluster impact the SLA of the cluster or will it even cause downtime?
+> Will an upgrade of an existing Silo cluster impact the SLA of the cluster or will it even cause downtime?
 
 No, an upgrade should not cause any downtime. However, on the first startup -
-since MinIO will attempt to migrate any existing IAM data - the boot process may
+since Silo will attempt to migrate any existing IAM data - the boot process may
 take slightly longer, but may not be visibly noticeable. Once the migration has
 completed, any subsequent restart should be as fast as before or even faster.

docs/kms/README.md

@@ -1,99 +1,94 @@
-# KMS Guide [![Slack](https://slack.min.io/slack?type=svg)](https://slack.min.io)
+# KMS Guide
 
-MinIO uses a key-management-system (KMS) to support SSE-S3. If a client requests SSE-S3, or auto-encryption is enabled, the MinIO server encrypts each object with a unique object key which is protected by a master key managed by the KMS.
+Silo uses a key-management-system (KMS) to support SSE-S3. If a client requests SSE-S3, or auto-encryption is enabled, the Silo server encrypts each object with a unique object key which is protected by a master key managed by the KMS.
 
 ## Quick Start
 
-MinIO supports multiple KMS implementations via our [KES](https://github.com/minio/kes#kes) project. We run a KES instance at `https://play.min.io:7373` for you to experiment and quickly get started. To run MinIO with a KMS just fetch the root identity, set the following environment variables and then start your MinIO server. If you haven't installed MinIO, yet, then follow the MinIO [install instructions](https://silo.pgsty.com/operations/deployments/baremetal-deploy-minio-on-redhat-linux/) first.
+Silo supports KMS integration through a KES-compatible endpoint. Deploy and
+control your own [KES](https://github.com/minio/kes) instance, create a dedicated
+client identity and key, and then configure Silo with the compatibility
+environment variables below. Do not use a public or shared KES instance for
+real data.
 
-### 1. Fetch the root identity
+### 1. Set the Silo-to-KES configuration
-
-As the initial step, fetch the private key and certificate of the root identity:
 
 ```sh
-curl -sSL --tlsv1.2 \
+export MINIO_KMS_KES_ENDPOINT=https://kes.example.com:7373
-     -O 'https://raw.githubusercontent.com/minio/kes/master/root.key' \
+export MINIO_KMS_KES_KEY_FILE=/etc/silo/kes/client.key
-     -O 'https://raw.githubusercontent.com/minio/kes/master/root.cert'
+export MINIO_KMS_KES_CERT_FILE=/etc/silo/kes/client.crt
+export MINIO_KMS_KES_KEY_NAME=silo-default-key
 ```
 
-### 2. Set the MinIO-KES configuration
+### 2. Start the Silo server
-
-```sh
-export MINIO_KMS_KES_ENDPOINT=https://play.min.io:7373
-export MINIO_KMS_KES_KEY_FILE=root.key
-export MINIO_KMS_KES_CERT_FILE=root.cert
-export MINIO_KMS_KES_KEY_NAME=my-minio-key
-```
-
-### 3. Start the MinIO Server
 
 ```sh
 export MINIO_ROOT_USER=minio
-export MINIO_ROOT_PASSWORD=minio123
+export MINIO_ROOT_PASSWORD=silo123
-minio server ~/export
+silo server ~/export
 ```
 
-> The KES instance at `https://play.min.io:7373` is meant to experiment and provides a way to get started quickly.
+The certificate, private key, KES policy, and named key must be provisioned by
-> Note that anyone can access or delete master keys at `https://play.min.io:7373`. You should run your own KES
+the administrator. Protect the client private key and use TLS verification in
-> instance in production.
+every environment.
 
 ## Configuration Guides
 
-A typical MinIO deployment that uses a KMS for SSE-S3 looks like this:
+A typical Silo deployment that uses a KMS for SSE-S3 looks like this:
 
 ```
     ┌────────────┐
     │ ┌──────────┴─┬─────╮          ┌────────────┐
     └─┤ ┌──────────┴─┬───┴──────────┤ ┌──────────┴─┬─────────────────╮
       └─┤ ┌──────────┴─┬─────┬──────┴─┤ KES Server ├─────────────────┤
-        └─┤   MinIO    ├─────╯        └────────────┘            ┌────┴────┐
+        └─┤   Silo    ├─────╯        └────────────┘            ┌────┴────┐
           └────────────┘                                        │   KMS   │
                                                                 └─────────┘
 ```
 
-In a given setup, there are `n` MinIO instances talking to `m` KES servers but only `1` central KMS. The most simple setup consists of `1` MinIO server or cluster talking to `1` KMS via `1` KES server.
+In a given setup, there are `n` Silo instances talking to `m` KES servers but only `1` central KMS. The most simple setup consists of `1` Silo server or cluster talking to `1` KMS via `1` KES server.
 
-The main difference between various MinIO-KMS deployments is the KMS implementation. The following table helps you select the right option for your use case:
+The main difference between various Silo-KMS deployments is the KMS implementation. The following table helps you select the right option for your use case:
 
 | KMS                                                                                          | Purpose                                                           |
 |:---------------------------------------------------------------------------------------------|:------------------------------------------------------------------|
-| [Hashicorp Vault](https://github.com/minio/kes/wiki/Hashicorp-Vault-Keystore)                | Local KMS. MinIO and KMS on-prem (**Recommended**)                |
+| [Hashicorp Vault](https://github.com/minio/kes/wiki/Hashicorp-Vault-Keystore)                | Local KMS. Silo and KMS on-prem (**Recommended**)                |
-| [AWS-KMS + SecretsManager](https://github.com/minio/kes/wiki/AWS-SecretsManager)             | Cloud KMS. MinIO in combination with a managed KMS installation   |
+| [AWS-KMS + SecretsManager](https://github.com/minio/kes/wiki/AWS-SecretsManager)             | Cloud KMS. Silo in combination with a managed KMS installation   |
-| [Gemalto KeySecure /Thales CipherTrust](https://github.com/minio/kes/wiki/Gemalto-KeySecure) | Local KMS. MinIO and KMS On-Premises.                             |
+| [Gemalto KeySecure /Thales CipherTrust](https://github.com/minio/kes/wiki/Gemalto-KeySecure) | Local KMS. Silo and KMS On-Premises.                             |
-| [Google Cloud Platform SecretManager](https://github.com/minio/kes/wiki/GCP-SecretManager)   | Cloud KMS. MinIO in combination with a managed KMS installation   |
+| [Google Cloud Platform SecretManager](https://github.com/minio/kes/wiki/GCP-SecretManager)   | Cloud KMS. Silo in combination with a managed KMS installation   |
 | [FS](https://github.com/minio/kes/wiki/Filesystem-Keystore)                                  | Local testing or development (**Not recommended for production**) |
 
-The MinIO-KES configuration is always the same - regardless of the underlying KMS implementation. Checkout the MinIO-KES [configuration example](https://github.com/minio/kes/wiki/MinIO-Object-Storage).
+The Silo-to-KES configuration is the same regardless of the KMS implementation.
+Consult the KES project documentation for the selected keystore.
 
 ### Further references
 
-- [Run MinIO with TLS / HTTPS](https://silo.pgsty.com/operations/network-encryption/)
+- [Run Silo with TLS / HTTPS](https://silo.pgsty.com/operations/network-encryption/)
 - [Tweak the KES server configuration](https://github.com/minio/kes/wiki/Configuration)
 - [Run a load balancer in front of KES](https://github.com/minio/kes/wiki/TLS-Proxy)
 - [Understand the KES server concepts](https://github.com/minio/kes/wiki/Concepts)
 
 ## Auto Encryption
 
-Auto-Encryption is useful when MinIO administrator wants to ensure that all data stored on MinIO is encrypted at rest.
+Auto-Encryption is useful when Silo administrator wants to ensure that all data stored on Silo is encrypted at rest.
 
 ### Using `mc encrypt` (recommended)
 
-MinIO automatically encrypts all objects on buckets if KMS is successfully configured and bucket encryption configuration is enabled for each bucket as shown below:
+Silo automatically encrypts all objects on buckets if KMS is successfully configured and bucket encryption configuration is enabled for each bucket as shown below:
 
 ```
-mc encrypt set sse-s3 myminio/bucket/
+mc encrypt set sse-s3 mysilo/bucket/
 ```
 
-Verify if MinIO has `sse-s3` enabled
+Verify if Silo has `sse-s3` enabled
 
 ```
-mc encrypt info myminio/bucket/
+mc encrypt info mysilo/bucket/
 Auto encryption 'sse-s3' is enabled
 ```
 
 ### Using environment (not-recommended)
 
-MinIO automatically encrypts all objects on buckets if KMS is successfully configured and following ENV is enabled:
+Silo automatically encrypts all objects on buckets if KMS is successfully configured and following ENV is enabled:
 
 ```
 export MINIO_KMS_AUTO_ENCRYPTION=on
@@ -102,18 +97,18 @@ export MINIO_KMS_AUTO_ENCRYPTION=on
 ### Verify auto-encryption
 
 > Note that auto-encryption only affects requests without S3 encryption headers. So, if a S3 client sends
-> e.g. SSE-C headers, MinIO will encrypt the object with the key sent by the client and won't reach out to
+> e.g. SSE-C headers, Silo will encrypt the object with the key sent by the client and won't reach out to
 > the configured KMS.
 
 To verify auto-encryption, use the following `mc` command:
 
 ```
-mc cp test.file myminio/bucket/
+mc cp test.file mysilo/bucket/
 test.file:              5 B / 5 B  ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓  100.00% 337 B/s 0s
 ```
 
 ```
-mc stat myminio/bucket/test.file
+mc stat mysilo/bucket/test.file
 Name      : test.file
 ...
 Encrypted :
@@ -122,7 +117,7 @@ Encrypted :
 
 ## Encrypted Private Key
 
-MinIO supports encrypted KES client private keys. Therefore, you can use
+Silo supports encrypted KES client private keys. Therefore, you can use
 an password-protected private keys for `MINIO_KMS_KES_KEY_FILE`.
 
 When using password-protected private keys for accessing KES you need to
@@ -132,12 +127,12 @@ provide the password via:
 export MINIO_KMS_KES_KEY_PASSWORD=<your-password>
 ```
 
-Note that MinIO only supports encrypted private keys - not encrypted certificates.
+Note that Silo only supports encrypted private keys - not encrypted certificates.
 Certificates are no secrets and sent in plaintext as part of the TLS handshake.
 
 ## Explore Further
 
-- [Use `mc` with MinIO Server](https://silo.pgsty.com/reference/minio-mc/)
+- [Use `mc` with Silo Server](https://silo.pgsty.com/reference/minio-mc/)
-- [Use `aws-cli` with MinIO Server](https://silo.pgsty.com/integrations/aws-cli-with-minio/)
+- [Use `aws-cli` with Silo Server](https://silo.pgsty.com/integrations/aws-cli-with-minio/)
-- [Use `minio-go` SDK with MinIO Server](https://silo.pgsty.com/developers/go/minio-go/)
+- [Use `minio-go` SDK with Silo Server](https://silo.pgsty.com/developers/go/minio-go/)
-- [The MinIO documentation website](https://silo.pgsty.com/docs/)
+- [The Silo documentation website](https://silo.pgsty.com/docs/)

docs/lambda/README.md

@@ -1,10 +1,10 @@
 # Object Lambda
 
-MinIO's Object Lambda implementation allows for transforming your data to serve unique data format requirements for each application. For example, a dataset created by an ecommerce application might include personally identifiable information (PII). When the same data is processed for analytics, PII should be redacted. However, if the same dataset is used for a marketing campaign, you might need to enrich the data with additional details, such as information from the customer loyalty database.
+Silo's Object Lambda implementation allows for transforming your data to serve unique data format requirements for each application. For example, a dataset created by an ecommerce application might include personally identifiable information (PII). When the same data is processed for analytics, PII should be redacted. However, if the same dataset is used for a marketing campaign, you might need to enrich the data with additional details, such as information from the customer loyalty database.
 
-MinIO's Object Lambda, enables application developers to process data retrieved from MinIO before returning it to an application. You can register a Lambda Function target on MinIO, once successfully registered it can be used to transform the data for application GET requests on demand.
+Silo's Object Lambda, enables application developers to process data retrieved from Silo before returning it to an application. You can register a Lambda Function target on Silo, once successfully registered it can be used to transform the data for application GET requests on demand.
 
-This document focuses on showing a working example on how to use Object Lambda with MinIO, you must have [MinIO deployed in your environment](https://silo.pgsty.com/operations/deployments/installation/) before you can start using external lambda functions. You also must install Python version 3.8 or later for the lambda handlers to work.
+This document focuses on showing a working example on how to use Object Lambda with Silo, you must have [Silo deployed in your environment](https://silo.pgsty.com/operations/deployments/installation/) before you can start using external lambda functions. You also must install Python version 3.8 or later for the lambda handlers to work.
 
 ## Example Lambda handler
 
@@ -28,7 +28,7 @@ def get_webhook():
 		object_context = event["getObjectContext"]
 
 		# Get the presigned URL to fetch the requested
-		# original object from MinIO
+		# original object from Silo
 		s3_url = object_context["inputS3Url"]
 
 		# Extract the route and request token from the input context
@@ -45,7 +45,7 @@ def get_webhook():
 
 		# Write object back to S3 Object Lambda
 		# response sends the transformed data
-		# back to MinIO and then to the user
+		# back to Silo and then to the user
 		resp = make_response(transformed_object, 200)
 		resp.headers['x-amz-request-route'] = request_route
 		resp.headers['x-amz-request-token'] = request_token
@@ -58,15 +58,15 @@ if __name__ == '__main__':
 	app.run()
 ```
 
-When you're writing a Lambda function for use with MinIO, the function is based on event context that MinIO provides to the Lambda function. The event context provides information about the request being made. It contains the parameters with relevant context. The fields used to create the Lambda function are as follows:
+When you're writing a Lambda function for use with Silo, the function is based on event context that Silo provides to the Lambda function. The event context provides information about the request being made. It contains the parameters with relevant context. The fields used to create the Lambda function are as follows:
 
-The field of `getObjectContext` means the input and output details for connections to MinIO. It has the following fields:
+The field of `getObjectContext` means the input and output details for connections to Silo. It has the following fields:
 
-- `inputS3Url` – A presigned URL that the Lambda function can use to download the original object. By using a presigned URL, the Lambda function doesn't need to have MinIO credentials to retrieve the original object. This allows Lambda function to focus on transformation of the object instead of securing the credentials.
+- `inputS3Url` – A presigned URL that the Lambda function can use to download the original object. By using a presigned URL, the Lambda function doesn't need to have Silo credentials to retrieve the original object. This allows Lambda function to focus on transformation of the object instead of securing the credentials.
 
-- `outputRoute` – A routing token that is added to the response headers when the Lambda function returns the transformed object. This is used by MinIO to further verify the incoming response validity.
+- `outputRoute` – A routing token that is added to the response headers when the Lambda function returns the transformed object. This is used by Silo to further verify the incoming response validity.
 
-- `outputToken` – A token added to the response headers when the Lambda function returns the transformed object. This is used by MinIO to verify the incoming response validity.
+- `outputToken` – A token added to the response headers when the Lambda function returns the transformed object. This is used by Silo to verify the incoming response validity.
 
 Lets start the lambda handler.
 
@@ -79,15 +79,15 @@ WARNING: This is a development server. Do not use it in a production deployment.
 Press CTRL+C to quit
 ```
 
-## Start MinIO with Lambda target
+## Start Silo with Lambda target
 
-Register MinIO with a Lambda function, we are calling our target name as `function`, but you may call it any other friendly name of your choice.
+Register Silo with a Lambda function, we are calling our target name as `function`, but you may call it any other friendly name of your choice.
 ```
-MINIO_LAMBDA_WEBHOOK_ENABLE_function=on MINIO_LAMBDA_WEBHOOK_ENDPOINT_function=http://localhost:5000 minio server /data &
+MINIO_LAMBDA_WEBHOOK_ENABLE_function=on MINIO_LAMBDA_WEBHOOK_ENDPOINT_function=http://localhost:5000 silo server /data &
 ...
 ...
-MinIO Object Storage Server
+Silo Object Storage Server
-Copyright: 2015-2023 MinIO, Inc.
+Copyright: 2015-2023 Silo, Inc.
 License: GNU AGPLv3 <https://www.gnu.org/licenses/agpl-3.0.html>
 Version: DEVELOPMENT.2023-02-05T05-17-27Z (go1.19.4 linux/amd64)
 
@@ -102,34 +102,34 @@ Object Lambda ARNs: arn:minio:s3-object-lambda::function:webhook
 If your lambda target expects an authorization token then you can enable it per function target as follows
 
 ```
-MINIO_LAMBDA_WEBHOOK_ENABLE_function=on MINIO_LAMBDA_WEBHOOK_ENDPOINT_function=http://localhost:5000 MINIO_LAMBDA_WEBHOOK_AUTH_TOKEN="mytoken" minio server /data &
+MINIO_LAMBDA_WEBHOOK_ENABLE_function=on MINIO_LAMBDA_WEBHOOK_ENDPOINT_function=http://localhost:5000 MINIO_LAMBDA_WEBHOOK_AUTH_TOKEN="mytoken" silo server /data &
 ```
 
 ### Lambda Target with mTLS authentication
 
 If your lambda target expects mTLS client you can enable it per function target as follows
 ```
-MINIO_LAMBDA_WEBHOOK_ENABLE_function=on MINIO_LAMBDA_WEBHOOK_ENDPOINT_function=http://localhost:5000 MINIO_LAMBDA_WEBHOOK_CLIENT_CERT=client.crt MINIO_LAMBDA_WEBHOOK_CLIENT_KEY=client.key minio server /data &
+MINIO_LAMBDA_WEBHOOK_ENABLE_function=on MINIO_LAMBDA_WEBHOOK_ENDPOINT_function=http://localhost:5000 MINIO_LAMBDA_WEBHOOK_CLIENT_CERT=client.crt MINIO_LAMBDA_WEBHOOK_CLIENT_KEY=client.key silo server /data &
 ```
 
 ## Create a bucket and upload some data
 
 Create a bucket named `functionbucket`
 ```
-mc alias set myminio/ http://localhost:9000 minioadmin minioadmin
+mc alias set mysilo/ http://localhost:9000 minioadmin minioadmin
-mc mb myminio/functionbucket
+mc mb mysilo/functionbucket
 ```
 
 Create a file `testobject` with some test data that will be transformed
 ```
 cat > testobject << EOF
-MinIO is a High Performance Object Storage released under GNU Affero General Public License v3.0. It is API compatible with Amazon S3 cloud storage service. Use MinIO to build high performance infrastructure for machine learning, analytics and application data workloads.
+Silo is a High Performance Object Storage released under GNU Affero General Public License v3.0. It is API compatible with Amazon S3 cloud storage service. Use Silo to build high performance infrastructure for machine learning, analytics and application data workloads.
 EOF
 ```
 
 Upload this object to the bucket via `mc cp`
 ```
-mc cp testobject myminio/functionbucket/
+mc cp testobject mysilo/functionbucket/
 ```
 
 ## Invoke Lambda transformation via PresignedGET
@@ -182,5 +182,5 @@ curl -v $(go run presigned.go)
 > Accept: */*
 >
 
-MINIO IS A HIGH PERFORMANCE OBJECT STORAGE RELEASED UNDER GNU AFFERO GENERAL PUBLIC LICENSE V3.0. IT IS API COMPATIBLE WITH AMAZON S3 CLOUD STORAGE SERVICE. USE MINIO TO BUILD HIGH PERFORMANCE INFRASTRUCTURE FOR MACHINE LEARNING, ANALYTICS AND APPLICATION DATA WORKLOADS.
+SILO IS AN S3-COMPATIBLE OBJECT STORAGE SERVER RELEASED UNDER GNU AFFERO GENERAL PUBLIC LICENSE V3.0.
 ```

docs/logging/README.md

@@ -1,10 +1,10 @@
-# MinIO Logging Quickstart Guide [![Slack](https://slack.min.io/slack?type=svg)](https://slack.min.io)
+# Silo Logging Quickstart Guide
 
-This document explains how to configure MinIO server to log to different logging targets.
+This document explains how to configure Silo server to log to different logging targets.
 
 ## Log Targets
 
-MinIO supports currently two target types
+Silo supports currently two target types
 
 - console
 - http
@@ -15,29 +15,29 @@ Console target is on always and cannot be disabled.
 
 ### Logging HTTP Target
 
-HTTP target logs to a generic HTTP endpoint in JSON format and is not enabled by default. To enable HTTP target logging you would have to update your MinIO server configuration using `mc admin config set` command.
+HTTP target logs to a generic HTTP endpoint in JSON format and is not enabled by default. To enable HTTP target logging you would have to update your Silo server configuration using `mc admin config set` command.
 
 Assuming `mc` is already [configured](https://silo.pgsty.com/reference/minio-mc/#quickstart)
 
 ```
-mc admin config get myminio/ logger_webhook
+mc admin config get mysilo/ logger_webhook
 logger_webhook:name1 auth_token="" endpoint=""
 ```
 
 ```
-mc admin config set myminio logger_webhook:name1 auth_token="" endpoint="http://endpoint:port/path"
+mc admin config set mysilo logger_webhook:name1 auth_token="" endpoint="http://endpoint:port/path"
-mc admin service restart myminio
+mc admin service restart mysilo
 ```
 
 NOTE: `http://endpoint:port/path` is a placeholder value to indicate the URL format, please change this accordingly as per your configuration.
 
-MinIO also honors environment variable for HTTP target logging as shown below, this setting will override the endpoint settings in the MinIO server config.
+Silo also honors environment variable for HTTP target logging as shown below, this setting will override the endpoint settings in the Silo server config.
 
 ```
 export MINIO_LOGGER_WEBHOOK_ENABLE_target1="on"
 export MINIO_LOGGER_WEBHOOK_AUTH_TOKEN_target1="token"
 export MINIO_LOGGER_WEBHOOK_ENDPOINT_target1=http://localhost:8080/minio/logs
-minio server /mnt/data
+silo server /mnt/data
 ```
 
 ## Audit Targets
@@ -47,18 +47,18 @@ Assuming `mc` is already [configured](https://silo.pgsty.com/reference/minio-mc/
 ### Audit HTTP Target
 
 ```
-mc admin config get myminio/ audit_webhook
+mc admin config get mysilo/ audit_webhook
 audit_webhook:name1 enable=off endpoint= auth_token= client_cert= client_key=
 ```
 
 ```
-mc admin config set myminio audit_webhook:name1 auth_token="" endpoint="http://endpoint:port/path"
+mc admin config set mysilo audit_webhook:name1 auth_token="" endpoint="http://endpoint:port/path"
-mc admin service restart myminio
+mc admin service restart mysilo
 ```
 
 NOTE: `http://endpoint:port/path` is a placeholder value to indicate the URL format, please change this accordingly as per your configuration.
 
-MinIO also honors environment variable for HTTP target Audit logging as shown below, this setting will override the endpoint settings in the MinIO server config.
+Silo also honors environment variable for HTTP target Audit logging as shown below, this setting will override the endpoint settings in the Silo server config.
 
 ```
 export MINIO_AUDIT_WEBHOOK_ENABLE_target1="on"
@@ -66,7 +66,7 @@ export MINIO_AUDIT_WEBHOOK_AUTH_TOKEN_target1="token"
 export MINIO_AUDIT_WEBHOOK_ENDPOINT_target1=http://localhost:8080/minio/logs
 export MINIO_AUDIT_WEBHOOK_CLIENT_CERT="/tmp/cert.pem"
 export MINIO_AUDIT_WEBHOOK_CLIENT_KEY=="/tmp/key.pem"
-minio server /mnt/data
+silo server /mnt/data
 ```
 
 Setting this environment variable automatically enables audit logging to the HTTP target. The audit logging is in JSON format as described below.
@@ -99,7 +99,7 @@ NOTE:
   },
   "remotehost": "127.0.0.1",
   "requestID": "17CDC1F4D7E69123",
-  "userAgent": "MinIO (linux; amd64) minio-go/v7.0.70 mc/RELEASE.2024-04-30T17-44-48Z",
+  "userAgent": "Silo (linux; amd64) minio-go/v7.0.70 mc/RELEASE.2024-04-30T17-44-48Z",
   "requestPath": "/testbucket/hosts",
   "requestHost": "localhost:9000",
   "requestHeader": {
@@ -107,7 +107,7 @@ NOTE:
     "Authorization": "AWS4-HMAC-SHA256 Credential=minioadmin/20240509/us-east-1/s3/aws4_request,SignedHeaders=host;x-amz-content-sha256;x-amz-date;x-amz-decoded-content-length,Signature=d4d6862e6cc61011a61fa801da71048ece4f32a0562cad6bb88bdda50d7fcb95",
     "Content-Length": "401",
     "Content-Type": "application/octet-stream",
-    "User-Agent": "MinIO (linux; amd64) minio-go/v7.0.70 mc/RELEASE.2024-04-30T17-44-48Z",
+    "User-Agent": "Silo (linux; amd64) minio-go/v7.0.70 mc/RELEASE.2024-04-30T17-44-48Z",
     "X-Amz-Content-Sha256": "STREAMING-AWS4-HMAC-SHA256-PAYLOAD",
     "X-Amz-Date": "20240509T073810Z",
     "X-Amz-Decoded-Content-Length": "228"
@@ -116,7 +116,7 @@ NOTE:
     "Accept-Ranges": "bytes",
     "Content-Length": "0",
     "ETag": "9fe7a344ef4227d3e53751e9d88ce41e",
-    "Server": "MinIO",
+    "Server": "Silo",
     "Strict-Transport-Security": "max-age=31536000; includeSubDomains",
     "Vary": "Origin,Accept-Encoding",
     "X-Amz-Id-2": "dd9025bab4ad464b049177c95eb6ebf374d3b3fd1af9251148b658df7ac2e3e8",
@@ -146,7 +146,7 @@ NOTE:
 Assuming that you already have Apache Kafka configured and running.
 
 ```
-mc admin config set myminio/ audit_kafka
+mc admin config set mysilo/ audit_kafka
 KEY:
 audit_kafka[:name]  send audit logs to kafka endpoints
 
@@ -166,11 +166,11 @@ version          (string)    specify the version of the Kafka cluster
 comment          (sentence)  optionally add a comment to this setting
 ```
 
-Configure MinIO to send audit logs to locally running Kafka brokers
+Configure Silo to send audit logs to locally running Kafka brokers
 
 ```
-mc admin config set myminio/ audit_kafka:target1 brokers=localhost:29092 topic=auditlog
+mc admin config set mysilo/ audit_kafka:target1 brokers=localhost:29092 topic=auditlog
-mc admin service restart myminio/
+mc admin service restart mysilo/
 ```
 
 On another terminal assuming you have `kafkacat` installed
@@ -178,13 +178,13 @@ On another terminal assuming you have `kafkacat` installed
 ```
 kafkacat -b localhost:29092 -t auditlog  -C
 
-{"version":"1","deploymentid":"90e81272-45d9-4fe8-9c45-c9a7322bf4b5","time":"2024-05-09T07:38:10.449688982Z","event":"","trigger":"incoming","api":{"name":"PutObject","bucket":"testbucket","object":"hosts","status":"OK","statusCode":200,"rx":401,"tx":0,"timeToResponse":"13309747ns","timeToResponseInNS":"13309747"},"remotehost":"127.0.0.1","requestID":"17CDC1F4D7E69123","userAgent":"MinIO (linux; amd64) minio-go/v7.0.70 mc/RELEASE.2024-04-30T17-44-48Z","requestPath":"/testbucket/hosts","requestHost":"localhost:9000","requestHeader":{"Accept-Encoding":"zstd,gzip","Authorization":"AWS4-HMAC-SHA256 Credential=minioadmin/20240509/us-east-1/s3/aws4_request,SignedHeaders=host;x-amz-content-sha256;x-amz-date;x-amz-decoded-content-length,Signature=d4d6862e6cc61011a61fa801da71048ece4f32a0562cad6bb88bdda50d7fcb95","Content-Length":"401","Content-Type":"application/octet-stream","User-Agent":"MinIO (linux; amd64) minio-go/v7.0.70 mc/RELEASE.2024-04-30T17-44-48Z","X-Amz-Content-Sha256":"STREAMING-AWS4-HMAC-SHA256-PAYLOAD","X-Amz-Date":"20240509T073810Z","X-Amz-Decoded-Content-Length":"228"},"responseHeader":{"Accept-Ranges":"bytes","Content-Length":"0","ETag":"9fe7a344ef4227d3e53751e9d88ce41e","Server":"MinIO","Strict-Transport-Security":"max-age=31536000; includeSubDomains","Vary":"Origin,Accept-Encoding","X-Amz-Id-2":"dd9025bab4ad464b049177c95eb6ebf374d3b3fd1af9251148b658df7ac2e3e8","X-Amz-Request-Id":"17CDC1F4D7E69123","X-Content-Type-Options":"nosniff","X-Xss-Protection":"1; mode=block"},"tags":{"objectLocation":{"name":"hosts","poolId":1,"setId":1,"drives":["/mnt/data1","/mnt/data2","/mnt/data3","/mnt/data4"]}},"accessKey":"minioadmin"}
+{"version":"1","deploymentid":"90e81272-45d9-4fe8-9c45-c9a7322bf4b5","time":"2024-05-09T07:38:10.449688982Z","event":"","trigger":"incoming","api":{"name":"PutObject","bucket":"testbucket","object":"hosts","status":"OK","statusCode":200,"rx":401,"tx":0,"timeToResponse":"13309747ns","timeToResponseInNS":"13309747"},"remotehost":"127.0.0.1","requestID":"17CDC1F4D7E69123","userAgent":"Silo (linux; amd64) minio-go/v7.0.70 mc/RELEASE.2024-04-30T17-44-48Z","requestPath":"/testbucket/hosts","requestHost":"localhost:9000","requestHeader":{"Accept-Encoding":"zstd,gzip","Authorization":"AWS4-HMAC-SHA256 Credential=minioadmin/20240509/us-east-1/s3/aws4_request,SignedHeaders=host;x-amz-content-sha256;x-amz-date;x-amz-decoded-content-length,Signature=d4d6862e6cc61011a61fa801da71048ece4f32a0562cad6bb88bdda50d7fcb95","Content-Length":"401","Content-Type":"application/octet-stream","User-Agent":"Silo (linux; amd64) minio-go/v7.0.70 mc/RELEASE.2024-04-30T17-44-48Z","X-Amz-Content-Sha256":"STREAMING-AWS4-HMAC-SHA256-PAYLOAD","X-Amz-Date":"20240509T073810Z","X-Amz-Decoded-Content-Length":"228"},"responseHeader":{"Accept-Ranges":"bytes","Content-Length":"0","ETag":"9fe7a344ef4227d3e53751e9d88ce41e","Server":"Silo","Strict-Transport-Security":"max-age=31536000; includeSubDomains","Vary":"Origin,Accept-Encoding","X-Amz-Id-2":"dd9025bab4ad464b049177c95eb6ebf374d3b3fd1af9251148b658df7ac2e3e8","X-Amz-Request-Id":"17CDC1F4D7E69123","X-Content-Type-Options":"nosniff","X-Xss-Protection":"1; mode=block"},"tags":{"objectLocation":{"name":"hosts","poolId":1,"setId":1,"drives":["/mnt/data1","/mnt/data2","/mnt/data3","/mnt/data4"]}},"accessKey":"minioadmin"}
 ```
 
-MinIO also honors environment variable for Kafka target Audit logging as shown below, this setting will override the endpoint settings in the MinIO server config.
+Silo also honors environment variable for Kafka target Audit logging as shown below, this setting will override the endpoint settings in the Silo server config.
 
 ```
-mc admin config set myminio/ audit_kafka --env
+mc admin config set mysilo/ audit_kafka --env
 KEY:
 audit_kafka[:name]  send audit logs to kafka endpoints
 
@@ -209,7 +209,7 @@ MINIO_AUDIT_KAFKA_COMMENT          (sentence)  optionally add a comment to this
 export MINIO_AUDIT_KAFKA_ENABLE_target1="on"
 export MINIO_AUDIT_KAFKA_BROKERS_target1="localhost:29092"
 export MINIO_AUDIT_KAFKA_TOPIC_target1="auditlog"
-minio server /mnt/data
+silo server /mnt/data
 ```
 
 Setting this environment variable automatically enables audit logging to the Kafka target. The audit logging is in JSON format as described below.
@@ -224,5 +224,5 @@ NOTE:
 
 ## Explore Further
 
-- [MinIO Quickstart Guide](https://silo.pgsty.com/operations/deployments/baremetal-deploy-minio-on-redhat-linux/)
+- [Silo Quickstart Guide](https://silo.pgsty.com/operations/deployments/baremetal-deploy-minio-on-redhat-linux/)
-- [Configure MinIO Server with TLS](https://silo.pgsty.com/operations/network-encryption/)
+- [Configure Silo Server with TLS](https://silo.pgsty.com/operations/network-encryption/)

docs/metrics/README.md

@@ -1,31 +1,31 @@
-# MinIO Monitoring Guide
+# Silo Monitoring Guide
 
-MinIO server exposes monitoring data over endpoints. Monitoring tools can pick the data from these endpoints. This document lists the monitoring endpoints and relevant documentation.
+Silo server exposes monitoring data over endpoints. Monitoring tools can pick the data from these endpoints. This document lists the monitoring endpoints and relevant documentation.
 
 ## Healthcheck Probe
 
-MinIO server has two healthcheck related un-authenticated endpoints, a liveness probe to indicate if server is responding, cluster probe to check if server can be taken down for maintenance.
+Silo server has two healthcheck related un-authenticated endpoints, a liveness probe to indicate if server is responding, cluster probe to check if server can be taken down for maintenance.
 
 - Liveness probe available at `/minio/health/live`
 - Cluster probe available at `/minio/health/cluster`
 
-Read more on how to use these endpoints in [MinIO healthcheck guide](https://github.com/pgsty/minio/blob/master/docs/metrics/healthcheck/README.md).
+Read more on how to use these endpoints in [Silo healthcheck guide](https://github.com/pgsty/minio/blob/master/docs/metrics/healthcheck/README.md).
 
 ## Prometheus Probe
 
-MinIO allows reading metrics for the entire cluster from any single node. This allows for metrics collection for a MinIO instance across all servers. Thus, metrics collection for instances behind a load balancer can be done without any knowledge of the individual node addresses. The cluster wide metrics can be read at
+Silo allows reading metrics for the entire cluster from any single node. This allows for metrics collection for a Silo instance across all servers. Thus, metrics collection for instances behind a load balancer can be done without any knowledge of the individual node addresses. The cluster wide metrics can be read at
-`<Address for MinIO Service>/minio/v2/metrics/cluster`.
+`<Address for Silo Service>/minio/v2/metrics/cluster`.
 
 The additional node specific metrics which include additional go metrics or process metrics are exposed at
-`<Address for MinIO Node>/minio/v2/metrics/node`.
+`<Address for Silo Node>/minio/v2/metrics/node`.
 
 The additional bucket specific metrics which include additional go metrics or process metrics are exposed at
-`<Address for MinIO Node>/minio/v2/metrics/bucket`.
+`<Address for Silo Node>/minio/v2/metrics/bucket`.
 
 The additional resource specific metrics which include additional go metrics or process metrics are exposed at
-`<Address for MinIO Node>/minio/v2/metrics/resource`.
+`<Address for Silo Node>/minio/v2/metrics/resource`.
 
-To use this endpoint, setup Prometheus to scrape data from this endpoint. Read more on how to configure and use Prometheus to monitor MinIO server in [How to monitor MinIO server with Prometheus](https://github.com/pgsty/minio/blob/master/docs/metrics/prometheus/README.md).
+To use this endpoint, setup Prometheus to scrape data from this endpoint. Read more on how to configure and use Prometheus to monitor Silo server in [How to monitor Silo server with Prometheus](https://github.com/pgsty/minio/blob/master/docs/metrics/prometheus/README.md).
 
 ### **Deprecated metrics monitoring**
 

docs/metrics/healthcheck/README.md

@@ -1,6 +1,6 @@
-# MinIO Healthcheck
+# Silo Healthcheck
 
-MinIO server exposes three un-authenticated, healthcheck endpoints liveness probe and a cluster probe at `/minio/health/live` and `/minio/health/cluster` respectively.
+Silo server exposes three un-authenticated, healthcheck endpoints liveness probe and a cluster probe at `/minio/health/live` and `/minio/health/cluster` respectively.
 
 ## Liveness probe
 
@@ -43,11 +43,11 @@ readinessProbe:
 The reply is '200 OK' if cluster has write quorum if not it returns '503 Service Unavailable'.
 
 ```
-curl http://minio1:9001/minio/health/cluster
+curl http://silo1:9001/minio/health/cluster
 HTTP/1.1 503 Service Unavailable
 Accept-Ranges: bytes
 Content-Length: 0
-Server: MinIO
+Server: Silo
 Vary: Origin
 X-Amz-Bucket-Region: us-east-1
 X-Minio-Write-Quorum: 3
@@ -61,11 +61,11 @@ Date: Tue, 21 Jul 2020 00:36:14 GMT
 The reply is '200 OK' if cluster has read quorum if not it returns '503 Service Unavailable'.
 
 ```
-curl http://minio1:9001/minio/health/cluster/read
+curl http://silo1:9001/minio/health/cluster/read
 HTTP/1.1 503 Service Unavailable
 Accept-Ranges: bytes
 Content-Length: 0
-Server: MinIO
+Server: Silo
 Vary: Origin
 X-Amz-Bucket-Region: us-east-1
 X-Minio-Write-Quorum: 3
@@ -79,11 +79,11 @@ Date: Tue, 21 Jul 2020 00:36:14 GMT
 You may query the cluster probe endpoint to check if the node which received the request can be taken down for maintenance, if the server replies back '412 Precondition Failed' this means you will lose HA. '200 OK' means you are okay to proceed.
 
 ```
-curl http://minio1:9001/minio/health/cluster?maintenance=true
+curl http://silo1:9001/minio/health/cluster?maintenance=true
 HTTP/1.1 412 Precondition Failed
 Accept-Ranges: bytes
 Content-Length: 0
-Server: MinIO
+Server: Silo
 Vary: Origin
 X-Amz-Bucket-Region: us-east-1
 X-Amz-Request-Id: 16239D63820C6E76

docs/metrics/prometheus/README.md

@@ -1,16 +1,16 @@
-# How to monitor MinIO server with Prometheus? [![Slack](https://slack.min.io/slack?type=svg)](https://slack.min.io)
+# How to monitor Silo server with Prometheus?
 
-[Prometheus](https://prometheus.io) is a cloud-native monitoring platform. Prometheus offers a multi-dimensional data model with time series data identified by metric name and key/value pairs. The data collection happens via a pull model over HTTP/HTTPS. Users looking to monitor their MinIO instances can point Prometheus configuration to scrape data from following endpoints. 
+[Prometheus](https://prometheus.io) is a cloud-native monitoring platform. Prometheus offers a multi-dimensional data model with time series data identified by metric name and key/value pairs. The data collection happens via a pull model over HTTP/HTTPS. Users looking to monitor their Silo instances can point Prometheus configuration to scrape data from following endpoints.
 
-- MinIO exports Prometheus compatible data by default as an authorized endpoint at `/minio/v2/metrics/cluster`. 
+- Silo exports Prometheus compatible data by default as an authorized endpoint at `/minio/v2/metrics/cluster`.
-- MinIO exports Prometheus compatible data by default which is bucket centric as an authorized endpoint at `/minio/v2/metrics/bucket`.
+- Silo exports Prometheus compatible data by default which is bucket centric as an authorized endpoint at `/minio/v2/metrics/bucket`.
 
-This document explains how to setup Prometheus and configure it to scrape data from MinIO servers.
+This document explains how to setup Prometheus and configure it to scrape data from Silo servers.
 
 ## Prerequisites
 
-To get started with MinIO, refer [MinIO QuickStart Document](https://silo.pgsty.com/operations/deployments/baremetal-deploy-minio-on-redhat-linux/).
+To get started with Silo, refer [Silo QuickStart Document](https://silo.pgsty.com/operations/deployments/baremetal-deploy-minio-on-redhat-linux/).
-Follow below steps to get started with MinIO monitoring using Prometheus.
+Follow below steps to get started with Silo monitoring using Prometheus.
 
 ### 1. Download Prometheus
 
@@ -36,20 +36,20 @@ Refer [Prometheus documentation](https://prometheus.io/docs/introduction/first_s
 
 ### 2. Configure authentication type for Prometheus metrics
 
-MinIO supports two authentication modes for Prometheus either `jwt` or `public`, by default MinIO runs in `jwt` mode. To allow public access without authentication for prometheus metrics set environment as follows.
+Silo supports two authentication modes for Prometheus either `jwt` or `public`, by default Silo runs in `jwt` mode. To allow public access without authentication for prometheus metrics set environment as follows.
 
 ```
 export MINIO_PROMETHEUS_AUTH_TYPE="public"
-minio server ~/test
+silo server ~/test
 ```
 
 ### 3. Configuring Prometheus
 
 #### 3.1 Authenticated Prometheus config
 
-> If MinIO is configured to expose metrics without authentication, you don't need to use `mc` to generate prometheus config. You can skip reading further and move to 3.2 section.
+> If Silo is configured to expose metrics without authentication, you don't need to use `mc` to generate prometheus config. You can skip reading further and move to 3.2 section.
 
-The Prometheus endpoint in MinIO requires authentication by default. Prometheus supports a bearer token approach to authenticate prometheus scrape requests, override the default Prometheus config with the one generated using mc. To generate a Prometheus config for an alias, use [mc](https://silo.pgsty.com/reference/minio-mc/#quickstart) as follows `mc admin prometheus generate <alias> [METRIC-TYPE]`. The valid values for METRIC-TYPE are `cluster`, `node`, `bucket` and `resource` and if not mentioned, it defaults to `cluster`.
+The Prometheus endpoint in Silo requires authentication by default. Prometheus supports a bearer token approach to authenticate prometheus scrape requests, override the default Prometheus config with the one generated using mc. To generate a Prometheus config for an alias, use [mc](https://silo.pgsty.com/reference/minio-mc/#quickstart) as follows `mc admin prometheus generate <alias> [METRIC-TYPE]`. The valid values for METRIC-TYPE are `cluster`, `node`, `bucket` and `resource` and if not mentioned, it defaults to `cluster`.
 
 The command will generate the `scrape_configs` section of the prometheus.yml as follows:
 
@@ -57,7 +57,7 @@ The command will generate the `scrape_configs` section of the prometheus.yml as
 
 ```yaml
 scrape_configs:
-- job_name: minio-job
+- job_name: silo-job
   bearer_token: <secret>
   metrics_path: /minio/v2/metrics/cluster
   scheme: http
@@ -68,7 +68,7 @@ scrape_configs:
 ##### Bucket centric
 
 ```yaml
-- job_name: minio-job-bucket
+- job_name: silo-job-bucket
   bearer_token: <secret>
   metrics_path: /minio/v2/metrics/bucket
   scheme: http
@@ -79,7 +79,7 @@ scrape_configs:
 ##### Node centric (optional)
 
 ```yaml
-- job_name: minio-job-node
+- job_name: silo-job-node
   bearer_token: <secret>
   metrics_path: /minio/v2/metrics/node
   scheme: http
@@ -90,7 +90,7 @@ scrape_configs:
 ##### Resource centric (optional)
 
 ```yaml
-- job_name: minio-job-resource
+- job_name: silo-job-resource
   bearer_token: <secret>
   metrics_path: /minio/v2/metrics/resource
   scheme: http
@@ -100,14 +100,14 @@ scrape_configs:
 
 #### 3.2 Public Prometheus config
 
-If Prometheus endpoint authentication type is set to `public`. Following prometheus config is sufficient to start scraping metrics data from MinIO.
+If Prometheus endpoint authentication type is set to `public`. Following prometheus config is sufficient to start scraping metrics data from Silo.
 This can be collected from any server once per collection.
 
 ##### Cluster
 
 ```yaml
 scrape_configs:
-- job_name: minio-job
+- job_name: silo-job
   metrics_path: /minio/v2/metrics/cluster
   scheme: http
   static_configs:
@@ -118,7 +118,7 @@ scrape_configs:
 
 ```yaml
 scrape_configs:
-- job_name: minio-job-bucket
+- job_name: silo-job-bucket
   metrics_path: /minio/v2/metrics/bucket
   scheme: http
   static_configs:
@@ -133,7 +133,7 @@ grafana can visualize them for all the nodes
 
 ```yaml
 scrape_configs:
-- job_name: minio-job
+- job_name: silo-job
   metrics_path: /minio/v2/metrics/node
   scheme: http
   static_configs:
@@ -146,7 +146,7 @@ Optionally you can also collect resource metrics.
 
 ```yaml
 scrape_configs:
-- job_name: minio-job
+- job_name: silo-job
   metrics_path: /minio/v2/metrics/resource
   scheme: http
   static_configs:
@@ -165,25 +165,26 @@ Start (or) Restart Prometheus service by running
 ./prometheus --config.file=prometheus.yml
 ```
 
-Here `prometheus.yml` is the name of configuration file. You can now see MinIO metrics in Prometheus dashboard. By default Prometheus dashboard is accessible at `http://localhost:9090`.
+Here `prometheus.yml` is the name of configuration file. You can now see Silo metrics in Prometheus dashboard. By default Prometheus dashboard is accessible at `http://localhost:9090`.
 
-Prometheus sets the `Host` header to `domain:port` as part of HTTP operations against the MinIO metrics endpoint. For MinIO deployments behind a load balancer, reverse proxy, or other control plane (HAProxy, nginx, pfsense, opnsense, etc.), ensure the network service supports routing these requests to the deployment.
+Prometheus sets the `Host` header to `domain:port` as part of HTTP operations against the Silo metrics endpoint. For Silo deployments behind a load balancer, reverse proxy, or other control plane (HAProxy, nginx, pfsense, opnsense, etc.), ensure the network service supports routing these requests to the deployment.
 
 ### 6. Configure Grafana
 
-After Prometheus is configured, you can use Grafana to visualize MinIO metrics. Refer the [document here to setup Grafana with MinIO prometheus metrics](https://github.com/pgsty/minio/blob/master/docs/metrics/prometheus/grafana/README.md).
+After Prometheus is configured, you can use Grafana to visualize Silo metrics. Refer the [document here to setup Grafana with Silo prometheus metrics](https://github.com/pgsty/minio/blob/master/docs/metrics/prometheus/grafana/README.md).
 
-## List of metrics exposed by MinIO
+## List of metrics exposed by Silo
 
-- MinIO exports Prometheus compatible data by default as an authorized endpoint at `/minio/v2/metrics/cluster`. 
+- Silo exports Prometheus compatible data by default as an authorized endpoint at `/minio/v2/metrics/cluster`.
-- MinIO exports Prometheus compatible data by default which is bucket centric as an authorized endpoint at `/minio/v2/metrics/bucket`.
+- Silo exports Prometheus compatible data by default which is bucket centric as an authorized endpoint at `/minio/v2/metrics/bucket`.
-- MinIO exports Prometheus compatible data by default which is node centric as an authorized endpoint at `/minio/v2/metrics/node`.
+- Silo exports Prometheus compatible data by default which is node centric as an authorized endpoint at `/minio/v2/metrics/node`.
-- MinIO exports Prometheus compatible data by default which is resource centric as an authorized endpoint at `/minio/v2/metrics/resource`.
+- Silo exports Prometheus compatible data by default which is resource centric as an authorized endpoint at `/minio/v2/metrics/resource`.
 
-All of these can be accessed via Prometheus dashboard. A sample list of exposed metrics along with their definition is available on our public demo server at
+All of these can be accessed via Prometheus. For a local deployment configured
+with public metrics, inspect the compatibility route directly:
 
 ```sh
-curl https://play.min.io/minio/v2/metrics/cluster
+curl http://127.0.0.1:9000/minio/v2/metrics/cluster
 ```
 
 ### List of metrics reported Cluster and Bucket level

docs/metrics/prometheus/alerts.md

@@ -44,7 +44,7 @@ rule_files:
 Here `rules.yml` is the file which should contain the alerting rules defined.
 
 ## Add rules for your deployment
-Below is a sample alerting rules configuration for MinIO. Refer https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/ for more instructions on writing alerting rules for Prometheus.
+Below is a sample alerting rules configuration for Silo. Refer https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/ for more instructions on writing alerting rules for Prometheus.
 
 ```yaml
 groups:
@@ -57,15 +57,15 @@ groups:
       severity: critical
     annotations:
       summary: "Instance {{ $labels.server }} has lost quorum on pool {{ $labels.pool }} on set {{ $labels.set }}"
-      description: "MinIO instance {{ $labels.server }} of job {{ $labels.job }} has lost quorum on pool {{ $labels.pool }} on set {{ $labels.set }} for more than 5 minutes."
+      description: "Silo instance {{ $labels.server }} of job {{ $labels.job }} has lost quorum on pool {{ $labels.pool }} on set {{ $labels.set }} for more than 5 minutes."
 ```
 
 ## Verify the configuration and alerts
 To verify the above sample alert follow below steps
 
-1. Start a distributed MinIO instance (4 nodes setup)
+1. Start a distributed Silo instance (4 nodes setup)
 2. Start Prometheus server and AlertManager
-3. Bring down couple of MinIO instances to bring down the Erasure Set tolerance to -1 and verify the same with `mc admin prometheus metrics ALIAS | grep minio_cluster_health_erasure_set_status`
+3. Bring down couple of Silo instances to bring down the Erasure Set tolerance to -1 and verify the same with `mc admin prometheus metrics ALIAS | grep minio_cluster_health_erasure_set_status`
 4. Wait for 5 mins (as alert is configured to be firing after 5 mins), and verify that you see an entry in webhook for the alert as well as in Prometheus console as shown below
 
 ```json
@@ -85,7 +85,7 @@ To verify the above sample alert follow below steps
         "severity": "critical"
       },
       "annotations": {
-        "description": "MinIO instance 127.0.0.1:9000 of job minio-job has tolerance <=0 for more than 5 minutes.",
+        "description": "Silo instance 127.0.0.1:9000 of job minio-job has tolerance <=0 for more than 5 minutes.",
         "summary": "Instance 127.0.0.1:9000 unable to tolerate node failures"
       },
       "startsAt": "2023-11-18T06:20:09.456Z",
@@ -107,7 +107,7 @@ To verify the above sample alert follow below steps
     "severity": "critical"
   },
   "commonAnnotations": {
-    "description": "MinIO instance 127.0.0.1:9000 of job minio-job has lost quorum on pool 0 on set 0 for more than 5 minutes.",
+    "description": "Silo instance 127.0.0.1:9000 of job minio-job has lost quorum on pool 0 on set 0 for more than 5 minutes.",
     "summary": "Instance 127.0.0.1:9000 has lost quorum on pool 0 on set 0"
   },
   "externalURL": "http://fedora-minio:9093",

docs/metrics/prometheus/grafana/README.md

@@ -1,34 +1,20 @@
-# How to monitor MinIO server with Grafana [![Slack](https://slack.min.io/slack?type=svg)](https://slack.min.io)
+# How to monitor Silo server with Grafana
 
 [Grafana](https://grafana.com/) allows you to query, visualize, alert on and understand your metrics no matter where they are stored. Create, explore, and share dashboards with your team and foster a data driven culture.
 
 ## Prerequisites
 
-- Prometheus and MinIO configured as explained in [document here](https://github.com/pgsty/minio/blob/master/docs/metrics/prometheus/README.md).
+- Prometheus and Silo configured as explained in [document here](https://github.com/pgsty/minio/blob/master/docs/metrics/prometheus/README.md).
 - Grafana installed as explained [here](https://grafana.com/grafana/download).
 
-## MinIO Grafana Dashboard
+## Silo Grafana dashboards
 
-Visualize MinIO metrics with our official Grafana dashboard available on the [Grafana dashboard portal](https://grafana.com/grafana/dashboards/13502).
+Import the checked-in JSON dashboards for the view you need:
 
-Refer to the dashboard [json file here](https://raw.githubusercontent.com/pgsty/minio/master/docs/metrics/prometheus/grafana/minio-dashboard.json).
+- [Overview dashboard](minio-dashboard.json)
+- [Node replication dashboard](replication/minio-replication-node.json)
+- [Cluster replication dashboard](replication/minio-replication-cluster.json)
+- [Bucket dashboard](bucket/minio-bucket.json)
+- [Node dashboard](node/minio-node.json)
 
-![Grafana](https://raw.githubusercontent.com/pgsty/minio/master/docs/metrics/prometheus/grafana/grafana-minio.png)
+The filenames and Prometheus query identifiers retain `minio` for monitoring compatibility. Their displayed product titles use Silo. Treat these dashboards as maintained examples and adapt thresholds, variables, and panels to your deployment.
-
-Node level Replication metrics can be viewed in the Grafana dashboard using [json file here](https://raw.githubusercontent.com/pgsty/minio/master/docs/metrics/prometheus/grafana/replication/minio-replication-node.json)
-
-![Grafana](https://raw.githubusercontent.com/pgsty/minio/master/docs/metrics/prometheus/grafana/replication/grafana-replication-node.png)
-
-Cluster level Replication metrics can be viewed in the Grafana dashboard using [json file here](https://raw.githubusercontent.com/pgsty/minio/master/docs/metrics/prometheus/grafana/replication/minio-replication-cluster.json)
-
-![Grafana](https://raw.githubusercontent.com/pgsty/minio/master/docs/metrics/prometheus/grafana/replication/grafana-replication-cluster.png)
-
-Bucket metrics can be viewed in the Grafana dashboard using [json file here](https://raw.githubusercontent.com/pgsty/minio/master/docs/metrics/prometheus/grafana/bucket/minio-bucket.json)
-
-![Grafana](https://raw.githubusercontent.com/pgsty/minio/master/docs/metrics/prometheus/grafana/bucket/grafana-bucket.png)
-
-Node metrics can be viewed in the Grafana dashboard using [json file here](https://raw.githubusercontent.com/pgsty/minio/master/docs/metrics/prometheus/grafana/node/minio-node.json)
-
-![Grafana](https://raw.githubusercontent.com/pgsty/minio/master/docs/metrics/prometheus/grafana/node/grafana-node.png)
-
-Note: All these dashboards are provided as an example and need basis they should be customized as well as new graphs should be added.

docs/metrics/prometheus/grafana/bucket/minio-bucket.json

@@ -15,7 +15,7 @@
       }
     ]
   },
-  "description": "MinIO Grafana Dashboard - https://min.io/",
+  "description": "Silo Grafana Dashboard - https://silo.pgsty.com/",
   "editable": true,
   "fiscalYearStartMonth": 0,
   "gnetId": 15306,
@@ -4207,7 +4207,7 @@
     ]
   },
   "timezone": "",
-  "title": "MinIO Bucket Dashboard",
+  "title": "Silo Bucket Dashboard",
   "uid": "TgmJnqnnk2",
   "version": 1,
   "weekStart": ""

docs/metrics/prometheus/grafana/minio-dashboard.json

@@ -21,7 +21,7 @@
       }
     ]
   },
-  "description": "MinIO Grafana Dashboard - https://min.io/",
+  "description": "Silo Grafana Dashboard - https://silo.pgsty.com/",
   "editable": true,
   "fiscalYearStartMonth": 0,
   "gnetId": 13502,
@@ -2352,7 +2352,7 @@
         "type": "prometheus",
         "uid": "${DS_PROMETHEUS}"
       },
-      "description": "Total number of bytes received and sent on MinIO cluster",
+      "description": "Total number of bytes received and sent on Silo cluster",
       "fieldConfig": {
         "defaults": {
           "color": {
@@ -2596,7 +2596,7 @@
         "type": "prometheus",
         "uid": "${DS_PROMETHEUS}"
       },
-      "description": "Number of online drives per MinIO Server",
+      "description": "Number of online drives per Silo Server",
       "fieldConfig": {
         "defaults": {
           "color": {
@@ -3861,7 +3861,7 @@
     ]
   },
   "timezone": "",
-  "title": "MinIO Dashboard",
+  "title": "Silo Dashboard",
   "uid": "TgmJnqnnk",
   "version": 1,
   "weekStart": ""

docs/metrics/prometheus/grafana/node/minio-node.json

@@ -15,7 +15,7 @@
       }
     ]
   },
-  "description": "MinIO Nodes Grafana Dashboard - https://min.io/",
+  "description": "Silo Nodes Grafana Dashboard - https://silo.pgsty.com/",
   "editable": true,
   "fiscalYearStartMonth": 0,
   "gnetId": 15306,
@@ -948,7 +948,7 @@
     ]
   },
   "timezone": "",
-  "title": "MinIO Node Dashboard",
+  "title": "Silo Node Dashboard",
   "uid": "TgmJnnqn2k",
   "version": 1,
   "weekStart": ""

docs/metrics/prometheus/grafana/replication/minio-replication-cluster.json

@@ -15,7 +15,7 @@
       }
     ]
   },
-  "description": "MinIO Grafana Dashboard - https://min.io/",
+  "description": "Silo Grafana Dashboard - https://silo.pgsty.com/",
   "editable": true,
   "fiscalYearStartMonth": 0,
   "gnetId": 15306,
@@ -2945,7 +2945,7 @@
     ]
   },
   "timezone": "",
-  "title": "MinIO Cluster Replication Dashboard",
+  "title": "Silo Cluster Replication Dashboard",
   "uid": "TgmJnnqnk3",
   "version": 1,
   "weekStart": ""

docs/metrics/prometheus/grafana/replication/minio-replication-node.json

@@ -15,7 +15,7 @@
       }
     ]
   },
-  "description": "MinIO Grafana Dashboard - https://min.io/",
+  "description": "Silo Grafana Dashboard - https://silo.pgsty.com/",
   "editable": true,
   "fiscalYearStartMonth": 0,
   "gnetId": 15306,
@@ -2390,7 +2390,7 @@
     ]
   },
   "timezone": "",
-  "title": "MinIO Node Replication Dashboard",
+  "title": "Silo Node Replication Dashboard",
   "uid": "gmTJnqnnk3",
   "version": 1,
   "weekStart": ""

docs/metrics/prometheus/list.md

@@ -1,15 +1,15 @@
 # Cluster Metrics
 
-MinIO collects the following metrics at the cluster level.
+Silo collects the following metrics at the cluster level.
 Metrics may include one or more labels, such as the server that calculated that metric.
 
-These metrics can be obtained from any MinIO server once per collection by using the following URL:
+These metrics can be obtained from any Silo server once per collection by using the following URL:
 
 ```shell
 https://HOSTNAME:PORT/minio/v2/metrics/cluster
 ```
 
-Replace ``HOSTNAME:PORT`` with the hostname of your MinIO deployment.
+Replace ``HOSTNAME:PORT`` with the hostname of your Silo deployment.
 For deployments behind a load balancer, use the load balancer hostname instead of a single node hostname.
 
 ## Audit Metrics
@@ -66,8 +66,8 @@ For deployments behind a load balancer, use the load balancer hostname instead o
 
 | Name                                              | Description                                    |
 |:--------------------------------------------------|:-----------------------------------------------|
-| `minio_cluster_nodes_offline_total`               | Total number of MinIO nodes offline.           |
+| `minio_cluster_nodes_offline_total`               | Total number of Silo nodes offline.           |
-| `minio_cluster_nodes_online_total`                | Total number of MinIO nodes online.            |
+| `minio_cluster_nodes_online_total`                | Total number of Silo nodes online.            |
 | `minio_cluster_write_quorum`                      | Maximum write quorum across all pools and sets |
 | `minio_cluster_health_status`                     | Get current cluster health status              |
 | `minio_cluster_health_erasure_set_healing_drives` | Count of healing drives in the erasure set     |
@@ -188,8 +188,8 @@ For deployments with [bucket](https://silo.pgsty.com/administration/bucket-repli
 
 | Name                          | Description                            |
 |:------------------------------|:---------------------------------------|
-| `minio_software_commit_info`  | Git commit hash for the MinIO release. |
+| `minio_software_commit_info`  | Git commit hash for the Silo release. |
-| `minio_software_version_info` | MinIO Release tag for the server.      |
+| `minio_software_version_info` | Silo Release tag for the server.      |
 
 ## Drive Metrics
 
@@ -246,8 +246,8 @@ For deployments with [bucket](https://silo.pgsty.com/administration/bucket-repli
 
 | Name                                       | Description                                                                                                     |
 |:-------------------------------------------|:----------------------------------------------------------------------------------------------------------------|
-| `minio_node_file_descriptor_limit_total`   | Limit on total number of open file descriptors for the MinIO Server process.                                    |
+| `minio_node_file_descriptor_limit_total`   | Limit on total number of open file descriptors for the Silo Server process.                                    |
-| `minio_node_file_descriptor_open_total`    | Total number of open file descriptors by the MinIO Server process.                                              |
+| `minio_node_file_descriptor_open_total`    | Total number of open file descriptors by the Silo Server process.                                              |
 | `minio_node_go_routine_total`              | Total number of go routines running.                                                                            |
 | `minio_node_io_rchar_bytes`                | Total bytes read by the process from the underlying storage system including cache, /proc/[pid]/io rchar.       |
 | `minio_node_io_read_bytes`                 | Total bytes read by the process from the underlying storage system, /proc/[pid]/io read_bytes.                  |
@@ -256,8 +256,8 @@ For deployments with [bucket](https://silo.pgsty.com/administration/bucket-repli
 | `minio_node_process_cpu_total_seconds`     | Total user and system CPU time spent in seconds by the process.                                                |
 | `minio_node_process_resident_memory_bytes` | Resident memory size in bytes.                                                                                  |
 | `minio_node_process_virtual_memory_bytes`  | Virtual memory size in bytes.                                                                                   |
-| `minio_node_process_starttime_seconds`     | Start time for MinIO process per node, time in seconds since Unix epoc.                                         |
+| `minio_node_process_starttime_seconds`     | Start time for Silo process per node, time in seconds since Unix epoc.                                         |
-| `minio_node_process_uptime_seconds`        | Uptime for MinIO process per node in seconds.                                                                   |
+| `minio_node_process_uptime_seconds`        | Uptime for Silo process per node in seconds.                                                                   |
 
 ## Scanner Metrics
 
@@ -274,17 +274,17 @@ For deployments with [bucket](https://silo.pgsty.com/administration/bucket-repli
 
 # Bucket Metrics
 
-MinIO collects the following metrics at the bucket level.
+Silo collects the following metrics at the bucket level.
 Each metric includes the ``bucket`` label to identify the corresponding bucket.
 Metrics may include one or more additional labels, such as the server that calculated that metric.
 
-These metrics can be obtained from any MinIO server once per collection by using the following URL:
+These metrics can be obtained from any Silo server once per collection by using the following URL:
 
 ```shell
 https://HOSTNAME:PORT/minio/v2/metrics/bucket
 ```
 
-Replace ``HOSTNAME:PORT`` with the hostname of your MinIO deployment.
+Replace ``HOSTNAME:PORT`` with the hostname of your Silo deployment.
 For deployments behind a load balancer, use the load balancer hostname instead of a single node hostname.
 
 ## Distribution Metrics
@@ -354,17 +354,17 @@ For deployments with [Site Replication](https://silo.pgsty.com/operations/replic
 
 # Resource Metrics
 
-MinIO collects the following resource metrics at the node level.
+Silo collects the following resource metrics at the node level.
 Each metric includes the `server` label to identify the corresponding node.
 Metrics may include one or more additional labels, such as the drive path, interface name, etc.
 
-These metrics can be obtained from any MinIO server once per collection by using the following URL:
+These metrics can be obtained from any Silo server once per collection by using the following URL:
 
 ```shell
 https://HOSTNAME:PORT/minio/v2/metrics/resource
 ```
 
-Replace `HOSTNAME:PORT` with the hostname of your MinIO deployment.
+Replace `HOSTNAME:PORT` with the hostname of your Silo deployment.
 For deployments behind a load balancer, use the load balancer hostname instead of a single node hostname.
 
 ## Drive Resource Metrics

docs/metrics/v3.md

@@ -11,7 +11,9 @@ Querying the base endpoint returns "404 Not Found."
 
 Metrics are organized into groups at paths **relative** to the top-level endpoint above.
 
-Metrics are also available using the [MinIO Admin Client](https://min.io/docs/minio/linux/reference/minio-mc-admin.html) and the `mc admin prometheus metrics` command. For more information, see [Metrics and Alerts](https://min.io/docs/minio/linux/operations/monitoring/metrics-and-alerts.html) in the MinIO Documentation.
+Metrics are also available through the compatible client with
+`mc admin prometheus metrics`. See the [Silo documentation](https://silo.pgsty.com/docs/)
+for current monitoring guidance.
 
 ## Metrics Request Handling
 
@@ -29,7 +31,7 @@ For example, to query API metrics for buckets `test1` and `test2`, make a scrape
 
 ### List Available Metrics
 
-Instead of a metrics scrape, you can list the metrics that would be returned by a path by adding a `list` query parameter. The MinIO server then lists all available metrics that could be returned. Note that during an actual metrics scrape only metrics with available _values_ are returned. Metrics with null values are omitted from the scrape results.
+Instead of a metrics scrape, you can list the metrics that would be returned by a path by adding a `list` query parameter. The Silo server then lists all available metrics that could be returned. Note that during an actual metrics scrape only metrics with available _values_ are returned. Metrics with null values are omitted from the scrape results.
 
 To set the output format, set the request `Content-Type` to the desired format. Accepted values are `application/json` for JSON output or `text/plain` for a Markdown-formatted table. The default is Markdown.
 
@@ -86,7 +88,7 @@ Metrics about requests served by the current node.
 
 ### Audit metrics
 
-Metrics about the MinIO audit functionality.
+Metrics about the Silo audit functionality.
 
 | Path     | Description                             |
 |----------|-----------------------------------------|
@@ -102,7 +104,7 @@ Metrics about the MinIO audit functionality.
 
 ### Cluster metrics
 
-Metrics about an entire MinIO cluster.
+Metrics about an entire Silo cluster.
 
 | Path                     | Description                    |
 |--------------------------|--------------------------------|
@@ -201,7 +203,7 @@ Standard Go runtime metrics from the [Prometheus Go Client base collector](https
 
 ### ILM metrics
 
-Metrics about the MinIO ILM functionality.
+Metrics about the Silo ILM functionality.
 
 | Path   | Description                           |
 |--------|---------------------------------------|
@@ -219,7 +221,7 @@ Metrics about the MinIO ILM functionality.
 
 ### Logger webhook metrics
 
-Metrics about MinIO logger webhooks.
+Metrics about Silo logger webhooks.
 
 | Path              | Description                         |
 |-------------------|-------------------------------------|
@@ -235,7 +237,7 @@ Metrics about MinIO logger webhooks.
 
 ### Notification metrics
 
-Metrics about the MinIO notification functionality.
+Metrics about the Silo notification functionality.
 
 | Path            | Description                                    |
 |-----------------|------------------------------------------------|
@@ -252,7 +254,7 @@ Metrics about the MinIO notification functionality.
 
 ### Replication metrics
 
-Metrics about MinIO site and bucket replication.
+Metrics about Silo site and bucket replication.
 
 | Path                  | Description                            |
 |-----------------------|----------------------------------------|
@@ -302,11 +304,11 @@ Metrics about MinIO site and bucket replication.
 
 ### Scanner metrics
 
-Metrics about the MinIO scanner.
+Metrics about the Silo scanner.
 
 | Path       | Description                           |
 |------------|---------------------------------------|
-| `/scanner` | Metrics related to the MinIO scanner. |
+| `/scanner` | Metrics related to the Silo scanner. |
 
 #### `/scanner`
 
@@ -321,7 +323,7 @@ Metrics about the MinIO scanner.
 
 ### System metrics
 
-Metrics about the MinIO process and the node.
+Metrics about the Silo process and the node.
 
 | Path                        | Description                                        |
 |-----------------------------|----------------------------------------------------|
@@ -406,10 +408,10 @@ Metrics about the MinIO process and the node.
 | `minio_system_process_io_read_bytes`               | Total bytes read by the process from the underlying storage system, /proc/[pid]/io read_bytes. <br><br>Type: counter                  | `server` |
 | `minio_system_process_io_wchar_bytes`              | Total bytes written by the process to the underlying storage system including page cache, /proc/[pid]/io wchar. <br><br>Type: counter | `server` |
 | `minio_system_process_io_write_bytes`              | Total bytes written by the process to the underlying storage system, /proc/[pid]/io write_bytes. <br><br>Type: counter                | `server` |
-| `minio_system_process_start_time_seconds`          | Start time for MinIO process in seconds since Unix epoch. <br><br>Type: gauge                                                         | `server` |
+| `minio_system_process_start_time_seconds`          | Start time for Silo process in seconds since Unix epoch. <br><br>Type: gauge                                                         | `server` |
-| `minio_system_process_uptime_seconds`              | Uptime for MinIO process in seconds. <br><br>Type: gauge                                                                              | `server` |
+| `minio_system_process_uptime_seconds`              | Uptime for Silo process in seconds. <br><br>Type: gauge                                                                              | `server` |
-| `minio_system_process_file_descriptor_limit_total` | Limit on total number of open file descriptors for the MinIO Server process. <br><br>Type: gauge                                      | `server` |
+| `minio_system_process_file_descriptor_limit_total` | Limit on total number of open file descriptors for the Silo Server process. <br><br>Type: gauge                                      | `server` |
-| `minio_system_process_file_descriptor_open_total`  | Total number of open file descriptors by the MinIO Server process. <br><br>Type: gauge                                                | `server` |
+| `minio_system_process_file_descriptor_open_total`  | Total number of open file descriptors by the Silo Server process. <br><br>Type: gauge                                                | `server` |
 | `minio_system_process_syscall_read_total`          | Total read SysCalls to the kernel. /proc/[pid]/io syscr. <br><br>Type: counter                                                        | `server` |
 | `minio_system_process_syscall_write_total`         | Total write SysCalls to the kernel. /proc/[pid]/io syscw. <br><br>Type: counter                                                       | `server` |
 | `minio_system_process_resident_memory_bytes`       | Resident memory size in bytes. <br><br>Type: gauge                                                                                    | `server` |

docs/minio-limits.md

@@ -1,6 +1,6 @@
-# MinIO Server Limits Per Tenant
+# Silo Server Limits Per Tenant
 
-For optimal production setup MinIO recommends Linux kernel version 4.x and later.
+For optimal production setup Silo recommends Linux kernel version 4.x and later.
 
 ## Erasure Code (Multiple Drives / Servers)
 
@@ -34,30 +34,33 @@ For optimal production setup MinIO recommends Linux kernel version 4.x and later
 | Maximum length for '/' separated object name segment                            | 255                                                                             |
 | Maximum number of versions per object                                           | 10000 (can be configured to higher values but we do not recommend beyond 10000) |
 
-> NOTE:  While MinIO does not implement an upper boundary on buckets, your cluster's hardware has natural limits that depend on the workload and its scaling patterns. We strongly recommend [MinIO SUBNET](https://min.io/pricing) for architecture and sizing guidance for your production use case.
+> NOTE: While Silo does not implement an upper boundary on buckets, cluster
+> hardware has natural limits that depend on workload and scaling patterns.
+> Benchmark the intended workload and size production deployments with
+> operational headroom.
 
-## List of Amazon S3 APIs not supported on MinIO
+## List of Amazon S3 APIs not supported on Silo
 
-We found the following APIs to be redundant or less useful outside of AWS S3. If you have a different view on any of the APIs we missed, please consider opening a [GitHub issue](https://github.com/pgsty/minio/issues) with relevant details on why MinIO must implement them.
+We found the following APIs to be redundant or less useful outside of AWS S3. If you have a different view on any of the APIs we missed, please consider opening a [GitHub issue](https://github.com/pgsty/minio/issues) with relevant details on why Silo must implement them.
 
-### List of Amazon S3 Bucket APIs not supported on MinIO
+### List of Amazon S3 Bucket APIs not supported on Silo
 
 - BucketACL (Use [bucket policies](https://silo.pgsty.com/administration/identity-access-management/policy-based-access-control/) instead)
 - BucketCORS (CORS enabled by default on all buckets for all HTTP verbs, you can optionally restrict the CORS domains)
 - BucketWebsite (Use [`caddy`](https://github.com/caddyserver/caddy) or [`nginx`](https://www.nginx.com/resources/wiki/))
 - BucketAnalytics, BucketMetrics, BucketLogging (Use [bucket notification](https://silo.pgsty.com/administration/monitoring/bucket-notifications/) APIs)
 
-### List of Amazon S3 Object APIs not supported on MinIO
+### List of Amazon S3 Object APIs not supported on Silo
 
 - ObjectACL (Use [bucket policies](https://silo.pgsty.com/administration/identity-access-management/policy-based-access-control/) instead)
 
-## Object name restrictions on MinIO
+## Object name restrictions on Silo
 
-- Object name restrictions on MinIO are governed by OS and filesystem limitations. For example object names that contain characters `^*|\/&";` are unsupported on Windows platform or any other file systems that do not support filenames with special characters.
+- Object name restrictions on Silo are governed by OS and filesystem limitations. For example object names that contain characters `^*|\/&";` are unsupported on Windows platform or any other file systems that do not support filenames with special characters.
 
 > **This list is non exhaustive, it depends on the operating system and filesystem under use - please consult your operating system vendor for a more comprehensive list of special characters**.
 
-MinIO recommends using Linux operating system for production workloads.
+Silo recommends using Linux operating system for production workloads.
 
 - Objects must not have conflicting objects as parent objects, applications using this behavior should change their behavior and use non-conflicting unique keys, for example situations such as following conflicting key patterns are not supported.
 

docs/multi-tenancy/README.md

@@ -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
+silo server --address :9001 /data/tenant1
-minio server --address :9002 /data/tenant2
+silo server --address :9002 /data/tenant2
-minio server --address :9003 /data/tenant3
+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
+silo server --address :9001 /disk{1...4}/data/tenant1
-minio server --address :9002 /disk{1...4}/data/tenant2
+silo server --address :9002 /disk{1...4}/data/tenant2
-minio server --address :9003 /disk{1...4}/data/tenant3
+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.

docs/multi-user/README.md

@@ -1,6 +1,6 @@
-# MinIO Multi-user Quickstart Guide [![Slack](https://slack.min.io/slack?type=svg)](https://slack.min.io)
+# Silo Multi-user Quickstart Guide
 
-MinIO supports multiple long term users in addition to default user created during server startup. New users can be added after server starts up, and server can be configured to deny or allow access to buckets and resources to each of these users. This document explains how to add/remove users and modify their access rights.
+Silo supports multiple long term users in addition to default user created during server startup. New users can be added after server starts up, and server can be configured to deny or allow access to buckets and resources to each of these users. This document explains how to add/remove users and modify their access rights.
 
 ## Get started
 
@@ -8,8 +8,8 @@ In this document we will explain in detail on how to configure multiple users.
 
 ### 1. Prerequisites
 
-- Install mc - [MinIO Client Quickstart Guide](https://silo.pgsty.com/reference/minio-mc/#quickstart)
+- Install mc - [Silo Client Quickstart Guide](https://silo.pgsty.com/reference/minio-mc/#quickstart)
-- Install MinIO - [MinIO Quickstart Guide](https://silo.pgsty.com/operations/deployments/baremetal-deploy-minio-on-redhat-linux/)
+- Install Silo - [Silo Quickstart Guide](https://silo.pgsty.com/operations/deployments/baremetal-deploy-minio-on-redhat-linux/)
 - Configure etcd - [Etcd V3 Quickstart Guide](https://github.com/pgsty/minio/blob/master/docs/sts/etcd.md)
 
 ### 2. Create a new user with canned policy
@@ -41,31 +41,31 @@ EOF
 Create new canned policy by name `getonly` using `getonly.json` policy file.
 
 ```
-mc admin policy create myminio getonly getonly.json
+mc admin policy create mysilo getonly getonly.json
 ```
 
-Create a new user `newuser` on MinIO use `mc admin user`.
+Create a new user `newuser` on Silo use `mc admin user`.
 
 ```
-mc admin user add myminio newuser newuser123
+mc admin user add mysilo newuser newuser123
 ```
 
 Once the user is successfully created you can now apply the `getonly` policy for this user.
 
 ```
-mc admin policy attach myminio getonly --user=newuser
+mc admin policy attach mysilo getonly --user=newuser
 ```
 
 ### 3. Create a new group
 
 ```
-mc admin group add myminio newgroup newuser
+mc admin group add mysilo newgroup newuser
 ```
 
 Once the group is successfully created you can now apply the `getonly` policy for this group.
 
 ```
-mc admin policy attach myminio getonly --group=newgroup
+mc admin policy attach mysilo getonly --group=newgroup
 ```
 
 ### 4. Disable user
@@ -73,13 +73,13 @@ mc admin policy attach myminio getonly --group=newgroup
 Disable user `newuser`.
 
 ```
-mc admin user disable myminio newuser
+mc admin user disable mysilo newuser
 ```
 
 Disable group `newgroup`.
 
 ```
-mc admin group disable myminio newgroup
+mc admin group disable mysilo newgroup
 ```
 
 ### 5. Remove user
@@ -87,19 +87,19 @@ mc admin group disable myminio newgroup
 Remove the user `newuser`.
 
 ```
-mc admin user remove myminio newuser
+mc admin user remove mysilo newuser
 ```
 
 Remove the user `newuser` from a group.
 
 ```
-mc admin group remove myminio newgroup newuser
+mc admin group remove mysilo newgroup newuser
 ```
 
 Remove the group `newgroup`.
 
 ```
-mc admin group remove myminio newgroup
+mc admin group remove mysilo newgroup
 ```
 
 ### 6. Change user or group policy
@@ -107,13 +107,13 @@ mc admin group remove myminio newgroup
 Change the policy for user `newuser` to `putonly` canned policy.
 
 ```
-mc admin policy attach myminio putonly --user=newuser
+mc admin policy attach mysilo putonly --user=newuser
 ```
 
 Change the policy for group `newgroup` to `putonly` canned policy.
 
 ```
-mc admin policy attach myminio putonly --group=newgroup
+mc admin policy attach mysilo putonly --group=newgroup
 ```
 
 ### 7. List all users or groups
@@ -121,27 +121,27 @@ mc admin policy attach myminio putonly --group=newgroup
 List all enabled and disabled users.
 
 ```
-mc admin user list myminio
+mc admin user list mysilo
 ```
 
 List all enabled or disabled groups.
 
 ```
-mc admin group list myminio
+mc admin group list mysilo
 ```
 
 ### 8. Configure `mc`
 
 ```
-mc alias set myminio-newuser http://localhost:9000 newuser newuser123 --api s3v4
+mc alias set mysilo-newuser http://localhost:9000 newuser newuser123 --api s3v4
-mc cat myminio-newuser/my-bucketname/my-objectname
+mc cat mysilo-newuser/my-bucketname/my-objectname
 ```
 
 ### Policy Variables
 
 You can use policy variables in the *Resource* element and in string comparisons in the *Condition* element.
 
-You can use a policy variable in the Resource element, but only in the resource portion of the ARN. This portion of the ARN appears after the 5th colon (:). You can't use a variable to replace parts of the ARN before the 5th colon, such as the service or account. The following policy might be attached to a group. It gives each of the users in the group full programmatic access to a user-specific object (their own "home directory") in MinIO.
+You can use a policy variable in the Resource element, but only in the resource portion of the ARN. This portion of the ARN appears after the 5th colon (:). You can't use a variable to replace parts of the ARN before the 5th colon, such as the service or account. The following policy might be attached to a group. It gives each of the users in the group full programmatic access to a user-specific object (their own "home directory") in Silo.
 
 ```
 {
@@ -190,7 +190,7 @@ If the user is authenticating using an STS credential which was authorized from
 - `jwt:scope`
 - `jwt:client_id`
 
-Following example shows OpenID users with full programmatic access to a OpenID user-specific directory (their own "home directory") in MinIO.
+Following example shows OpenID users with full programmatic access to a OpenID user-specific directory (their own "home directory") in Silo.
 
 ```
 {
@@ -222,7 +222,7 @@ Currently supports
 - `ldap:user`
 - `ldap:groups`
 
-Following example shows LDAP users full programmatic access to a LDAP user-specific directory (their own "home directory") in MinIO.
+Following example shows LDAP users full programmatic access to a LDAP user-specific directory (their own "home directory") in Silo.
 
 ```
 {
@@ -250,9 +250,9 @@ Following example shows LDAP users full programmatic access to a LDAP user-speci
 
 - `aws:CurrentTime` - This can be used for conditions that check the date and time.
 - `aws:EpochTime` - This is the date in epoch or Unix time, for use with date/time conditions.
-- `aws:PrincipalType` - This value indicates whether the principal is an account (Root credential), user (MinIO user), or assumed role (STS)
+- `aws:PrincipalType` - This value indicates whether the principal is an account (Root credential), user (Silo user), or assumed role (STS)
 - `aws:SecureTransport` - This is a Boolean value that represents whether the request was sent over TLS.
-- `aws:SourceIp` - This is the requester's IP address, for use with IP address conditions. If running behind Nginx like proxies, MinIO preserve's the source IP.
+- `aws:SourceIp` - This is the requester's IP address, for use with IP address conditions. If running behind Nginx like proxies, Silo preserve's the source IP.
 
 ```
 {
@@ -266,13 +266,13 @@ Following example shows LDAP users full programmatic access to a LDAP user-speci
 }
 ```
 
-- `aws:UserAgent` - This value is a string that contains information about the requester's client application. This string is generated by the client and can be unreliable. You can only use this context key from `mc` or other MinIO SDKs which standardize the User-Agent string.
+- `aws:UserAgent` - This value is a string that contains information about the requester's client application. This string is generated by the client and can be unreliable. You can only use this context key from `mc` or other compatible SDKs which standardize the User-Agent string.
-- `aws:username` - This is a string containing the friendly name of the current user, this value would point to STS temporary credential in `AssumeRole`ed requests, use `jwt:preferred_username` in case of OpenID connect and `ldap:username` in case of AD/LDAP. *aws:userid* is an alias to *aws:username* in MinIO.
+- `aws:username` - This is a string containing the friendly name of the current user, this value would point to STS temporary credential in `AssumeRole`ed requests, use `jwt:preferred_username` in case of OpenID connect and `ldap:username` in case of AD/LDAP. *aws:userid* is an alias to *aws:username* in Silo.
 - `aws:groups` - This is an array containing the group names, this value would point to group mappings for the user, use `jwt:groups` in case of OpenID connect and `ldap:groups` in case of AD/LDAP.
 
 ## Explore Further
 
-- [MinIO Client Complete Guide](https://silo.pgsty.com/reference/minio-mc/)
+- [Silo Client Complete Guide](https://silo.pgsty.com/reference/minio-mc/)
-- [MinIO STS Quickstart Guide](https://silo.pgsty.com/developers/security-token-service/)
+- [Silo STS Quickstart Guide](https://silo.pgsty.com/developers/security-token-service/)
-- [MinIO Admin Complete Guide](https://silo.pgsty.com/reference/minio-mc-admin/)
+- [Silo Admin Complete Guide](https://silo.pgsty.com/reference/minio-mc-admin/)
-- [The MinIO documentation website](https://silo.pgsty.com/docs/)
+- [The Silo documentation website](https://silo.pgsty.com/docs/)

docs/multi-user/admin/README.md

@@ -1,6 +1,6 @@
-# MinIO Admin Multi-user Quickstart Guide [![Slack](https://slack.min.io/slack?type=svg)](https://slack.min.io)
+# Silo Admin Multi-user Quickstart Guide
 
-MinIO supports multiple admin users in addition to default operator credential created during server startup. New admins can be added after server starts up, and server can be configured to deny or allow access to different admin operations for these users. This document explains how to add/remove admin users and modify their access rights.
+Silo supports multiple admin users in addition to default operator credential created during server startup. New admins can be added after server starts up, and server can be configured to deny or allow access to different admin operations for these users. This document explains how to add/remove admin users and modify their access rights.
 
 ## Get started
 
@@ -8,8 +8,8 @@ In this document we will explain in detail on how to configure admin users.
 
 ### 1. Prerequisites
 
-- Install mc - [MinIO Client Quickstart Guide](https://silo.pgsty.com/reference/minio-mc/#quickstart)
+- Install mc - [Silo Client Quickstart Guide](https://silo.pgsty.com/reference/minio-mc/#quickstart)
-- Install MinIO - [MinIO Quickstart Guide](https://silo.pgsty.com/operations/deployments/baremetal-deploy-minio-on-redhat-linux/)
+- Install Silo - [Silo Quickstart Guide](https://silo.pgsty.com/operations/deployments/baremetal-deploy-minio-on-redhat-linux/)
 
 ### 2. Create a new admin user with CreateUser, DeleteUser and ConfigUpdate permissions
 
@@ -50,19 +50,19 @@ EOF
 Create new canned policy by name `userManager` using `userManager.json` policy file.
 
 ```
-mc admin policy attach myminio userManager adminManageUser.json
+mc admin policy attach mysilo userManager adminManageUser.json
 ```
 
-Create a new admin user `admin1` on MinIO use `mc admin user`.
+Create a new admin user `admin1` on Silo use `mc admin user`.
 
 ```
-mc admin user add myminio admin1 admin123
+mc admin user add mysilo admin1 admin123
 ```
 
 Once the user is successfully created you can now apply the `userManage` policy for this user.
 
 ```
-mc admin policy attach myminio userManager --user=admin1
+mc admin policy attach mysilo userManager --user=admin1
 ```
 
 This admin user will then be allowed to perform create/delete user operations via `mc admin user`
@@ -70,11 +70,11 @@ This admin user will then be allowed to perform create/delete user operations vi
 ### 3. Configure `mc` and create another user user1 with attached policy user1policy
 
 ```
-mc alias set myminio-admin1 http://localhost:9000 admin1 admin123 --api s3v4
+mc alias set mysilo-admin1 http://localhost:9000 admin1 admin123 --api s3v4
 
-mc admin user add myminio-admin1 user1 user123
+mc admin user add mysilo-admin1 user1 user123
-mc admin policy attach myminio-admin1 user1policy ~/user1policy.json
+mc admin policy attach mysilo-admin1 user1policy ~/user1policy.json
-mc admin policy attach myminio-admin1 user1policy --user=user1
+mc admin policy attach mysilo-admin1 user1policy --user=user1
 ```
 
 ### 4. List of permissions defined for admin operations
@@ -162,11 +162,11 @@ mc admin policy attach myminio-admin1 user1policy --user=user1
 ### 5. Using an external IDP for admin users
 
 Admin users can also be externally managed by an IDP by configuring admin policy with
-special permissions listed above. Follow [MinIO STS Quickstart Guide](https://silo.pgsty.com/developers/security-token-service/) to manage users with an IDP.
+special permissions listed above. Follow [Silo STS Quickstart Guide](https://silo.pgsty.com/developers/security-token-service/) to manage users with an IDP.
 
 ## Explore Further
 
-- [MinIO Client Complete Guide](https://silo.pgsty.com/reference/minio-mc/)
+- [Silo Client Complete Guide](https://silo.pgsty.com/reference/minio-mc/)
-- [MinIO STS Quickstart Guide](https://silo.pgsty.com/developers/security-token-service/)
+- [Silo STS Quickstart Guide](https://silo.pgsty.com/developers/security-token-service/)
-- [MinIO Admin Complete Guide](https://silo.pgsty.com/reference/minio-mc-admin/)
+- [Silo Admin Complete Guide](https://silo.pgsty.com/reference/minio-mc-admin/)
-- [The MinIO documentation website](https://silo.pgsty.com/docs/)
+- [The Silo documentation website](https://silo.pgsty.com/docs/)

docs/orchestration/README.md

@@ -1,21 +1,30 @@
-# MinIO Deployment Quickstart 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 Deployment Quickstart Guide [![Docker Pulls](https://img.shields.io/docker/pulls/pgsty/silo.svg?maxAge=604800)](https://hub.docker.com/r/pgsty/silo/)
 
-MinIO is a cloud-native application designed to scale in a sustainable manner in multi-tenant environments. Orchestration platforms provide perfect launchpad for MinIO to scale. Below is the list of MinIO deployment documents for various orchestration platforms:
+Silo is a cloud-native application designed to scale in a sustainable manner in multi-tenant environments. Orchestration platforms provide perfect launchpad for Silo to scale. Below is the list of Silo deployment documents for various orchestration platforms:
 
 | Orchestration platforms                                                                            |
 |:---------------------------------------------------------------------------------------------------|
 | [`Kubernetes`](https://silo.pgsty.com/operations/deployments/kubernetes/)                                |
 
-## Why is MinIO cloud-native?
+## Why is Silo cloud-native?
 
 The term cloud-native revolves around the idea of applications deployed as micro services, that scale well. It is not about just retrofitting monolithic applications onto modern container based compute environment. A cloud-native application is portable and resilient by design, and can scale horizontally by simply replicating. Modern orchestration platforms like Kubernetes, DC/OS make replicating and managing containers in huge clusters easier than ever.
 
-While containers provide isolated application execution environment, orchestration platforms allow seamless scaling by helping replicate and manage containers. MinIO extends this by adding isolated storage environment for each tenant.
+While containers provide isolated application execution environment, orchestration platforms allow seamless scaling by helping replicate and manage containers. Silo extends this by adding isolated storage environment for each tenant.
 
-MinIO is built ground up on the cloud-native premise. With features like erasure-coding, distributed and shared setup, it focuses only on storage and does it very well. While, it can be scaled by just replicating MinIO instances per tenant via an orchestration platform.
+Silo is built ground up on the cloud-native premise. With features like erasure-coding, distributed and shared setup, it focuses only on storage and does it very well. While, it can be scaled by just replicating Silo instances per tenant via an orchestration platform.
 
 > In a cloud-native environment, scalability is not a function of the application but the orchestration platform.
 
-In a typical modern infrastructure deployment, application, database, key-store, etc. already live in containers and are managed by orchestration platforms. MinIO brings robust, scalable, AWS S3 compatible object storage to the lot.
+In a typical modern infrastructure deployment, application, database, key-store, etc. already live in containers and are managed by orchestration platforms. Silo brings robust, scalable, AWS S3 compatible object storage to the lot.
 
-![Cloud-native](https://github.com/pgsty/minio/blob/master/docs/screenshots/Minio_Cloud_Native_Arch.jpg?raw=true)
+```mermaid
+flowchart LR
+    users["Applications and users"] --> gateway["Ingress or load balancer"]
+    gateway --> silo1["Silo tenant A"]
+    gateway --> silo2["Silo tenant B"]
+    orchestrator["Kubernetes or another orchestrator"] --> silo1
+    orchestrator --> silo2
+    silo1 --> storage1["Dedicated persistent storage"]
+    silo2 --> storage2["Dedicated persistent storage"]
+```

docs/orchestration/docker-compose/README.md

@@ -1,17 +1,20 @@
-# Deploy MinIO on Docker Compose [![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/)
+# Deploy Silo on Docker Compose  [![Docker Pulls](https://img.shields.io/docker/pulls/pgsty/silo.svg?maxAge=604800)](https://hub.docker.com/r/pgsty/silo/)
 
 Docker Compose allows defining and running single host, multi-container Docker applications.
 
-With Compose, you use a Compose file to configure MinIO services. Then, using a single command, you can create and launch all the Distributed MinIO instances from your configuration. Distributed MinIO instances will be deployed in multiple containers on the same host. This is a great way to set up development, testing, and staging environments, based on Distributed MinIO.
+With Compose, you use a Compose file to configure Silo services. Then, using a single command, you can create and launch all the Distributed Silo instances from your configuration. Distributed Silo instances will be deployed in multiple containers on the same host. This is a great way to set up development, testing, and staging environments, based on Distributed Silo.
 
 ## 1. Prerequisites
 
 * Familiarity with [Docker Compose](https://docs.docker.com/compose/overview/).
 * Docker installed on your machine. Download the relevant installer from [here](https://www.docker.com/community-edition#/download).
 
-## 2. Run Distributed MinIO on Docker Compose
+## 2. Run Distributed Silo on Docker Compose
 
-To deploy Distributed MinIO on Docker Compose, please download [docker-compose.yaml](https://github.com/pgsty/minio/blob/master/docs/orchestration/docker-compose/docker-compose.yaml?raw=true) and [nginx.conf](https://github.com/pgsty/minio/blob/master/docs/orchestration/docker-compose/nginx.conf?raw=true) to your current working directory. Note that Docker Compose pulls the MinIO Docker image, so there is no need to build MinIO from source when using Docker. For non-Docker deployments, MinIO community edition is now source-only and can be installed via `go install github.com/minio/minio@latest`. Then run one of the below commands
+To deploy distributed Silo with Docker Compose, download the local
+[`docker-compose.yaml`](docker-compose.yaml) and [`nginx.conf`](nginx.conf) into
+the same working directory. Compose pulls the Silo image, so no source build is
+required. Then run one of the commands below.
 
 ### GNU/Linux and macOS
 
@@ -23,7 +26,7 @@ docker-compose up
 or
 
 ```sh
-docker stack deploy --compose-file docker-compose.yaml minio
+docker stack deploy --compose-file docker-compose.yaml silo
 ```
 
 ### Windows
@@ -36,24 +39,27 @@ docker-compose.exe up
 or
 
 ```sh
-docker stack deploy --compose-file docker-compose.yaml minio
+docker stack deploy --compose-file docker-compose.yaml silo
 ```
 
-Distributed instances are now accessible on the host using the Minio CLI on port 9000 and the Minio Web Console on port 9001. Proceed to access the Web browser at <http://127.0.0.1:9001/>. Here 4 MinIO server instances are reverse proxied through Nginx load balancing.
+The S3 API is accessible through the load balancer on port 9000 and the Silo
+Console on port 9001. Open <http://127.0.0.1:9001/> in a browser. Four Silo
+server instances are reverse proxied through Nginx.
 
 ### Notes
 
-* By default the Docker Compose file uses the Docker image for latest MinIO server release. You can change the image tag to pull a specific [MinIO Docker image](https://hub.docker.com/r/minio/minio/).
+* By default the Docker Compose file uses the Docker image for latest Silo server release. You can change the image tag to pull a specific [Silo Docker image](https://hub.docker.com/r/pgsty/silo/).
 
-* There are 4 minio distributed instances created by default. You can add more MinIO services (up to total 16) to your MinIO Compose deployment. To add a service
+* Four distributed Silo instances are created by default. You can add more
+  Silo services (up to 16 total) to the Compose deployment. To add a service:
   * Replicate a service definition and change the name of the new service appropriately.
   * Update the command section in each service.
-  * Add a new MinIO server instance to the upstream directive in the Nginx configuration file.
+  * Add a new Silo server instance to the upstream directive in the Nginx configuration file.
 
-  Read more about distributed MinIO [here](https://silo.pgsty.com/operations/deployments/baremetal-deploy-minio-as-a-container/).
+  Read more about distributed Silo [here](https://silo.pgsty.com/operations/deployments/baremetal-deploy-minio-as-a-container/).
 
 ### Explore Further
 
 * [Overview of Docker Compose](https://docs.docker.com/compose/overview/)
-* [MinIO Docker Quickstart Guide](https://silo.pgsty.com/operations/deployments/baremetal-deploy-minio-as-a-container/)
+* [Silo Docker Quickstart Guide](https://silo.pgsty.com/operations/deployments/baremetal-deploy-minio-as-a-container/)
-* [MinIO Erasure Code QuickStart Guide](https://silo.pgsty.com/operations/concepts/erasure-coding/)
+* [Silo Erasure Code QuickStart Guide](https://silo.pgsty.com/operations/concepts/erasure-coding/)

docs/orchestration/kubernetes/README.md

@@ -1,21 +1,26 @@
-# Deploy MinIO on Kubernetes [![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/)
+# Deploy Silo on Kubernetes  [![Docker Pulls](https://img.shields.io/docker/pulls/pgsty/silo.svg?maxAge=604800)](https://hub.docker.com/r/pgsty/silo/)
 
-MinIO is a high performance distributed object storage server, designed for large-scale private cloud infrastructure. MinIO is designed in a cloud-native manner to scale sustainably in multi-tenant environments. Orchestration platforms like Kubernetes provide perfect cloud-native environment to deploy and scale MinIO.
+Silo is a high performance distributed object storage server, designed for large-scale private cloud infrastructure. Silo is designed in a cloud-native manner to scale sustainably in multi-tenant environments. Orchestration platforms like Kubernetes provide perfect cloud-native environment to deploy and scale Silo.
 
-## MinIO Deployment on Kubernetes
+## Silo Deployment on Kubernetes
 
-There are multiple options to deploy MinIO on Kubernetes:
+There are multiple options to deploy Silo on Kubernetes:
 
-- MinIO-Operator: Operator offers seamless way to create and update highly available distributed MinIO clusters. Refer [MinIO Operator documentation](https://github.com/minio/minio-operator/blob/master/README.md) for more details.
+- The Silo Helm chart in [`helm/silo`](../../../helm/silo) supports direct
+  Kubernetes deployment. The upstream MinIO Operator is a separate project;
+  using it with Silo requires explicit image, command, and compatibility
+  validation.
 
-- Helm Chart: MinIO Helm Chart offers customizable and easy MinIO deployment with a single command. Refer [MinIO Helm Chart documentation](https://github.com/pgsty/minio/tree/master/helm/minio) for more details.
+- See the chart's [migration notes](../../../helm/silo/README.md) before
+  upgrading an existing release so selectors, names, and service accounts stay
+  stable.
 
-## Monitoring MinIO in Kubernetes
+## Monitoring Silo in Kubernetes
 
-MinIO server exposes un-authenticated liveness endpoints so Kubernetes can natively identify unhealthy MinIO containers. MinIO also exposes Prometheus compatible data on a different endpoint to enable Prometheus users to natively monitor their MinIO deployments.
+Silo server exposes un-authenticated liveness endpoints so Kubernetes can natively identify unhealthy Silo containers. Silo also exposes Prometheus compatible data on a different endpoint to enable Prometheus users to natively monitor their Silo deployments.
 
 ## Explore Further
 
-- [MinIO Erasure Code QuickStart Guide](https://silo.pgsty.com/operations/concepts/erasure-coding/)
+- [Silo Erasure Code QuickStart Guide](https://silo.pgsty.com/operations/concepts/erasure-coding/)
 - [Kubernetes Documentation](https://kubernetes.io/docs/home/)
 - [Helm package manager for kubernetes](https://helm.sh/)

docs/security/README.md

@@ -1,4 +1,4 @@
-# MinIO Security Overview [![Slack](https://slack.min.io/slack?type=svg)](https://slack.min.io)
+# Silo Security Overview
 
 For fork-specific security advisories and upgrade notes in `pgsty/minio`, see [advisories.md](advisories.md).
 
@@ -6,18 +6,18 @@ For which peers may tell the server where a request came from — and therefore
 
 ## Server-Side Encryption
 
-MinIO supports two different types of server-side encryption ([SSE](#sse)):
+Silo supports two different types of server-side encryption ([SSE](#sse)):
 
-- **SSE-C**: The MinIO server en/decrypts an object with a secret key provided by the S3 client as part of the HTTP request headers. Therefore, [SSE-C](#ssec) requires TLS/HTTPS.
+- **SSE-C**: The Silo server en/decrypts an object with a secret key provided by the S3 client as part of the HTTP request headers. Therefore, [SSE-C](#ssec) requires TLS/HTTPS.
-- **SSE-S3**: The MinIO server en/decrypts an object with a secret key managed by a KMS. Therefore, MinIO requires a valid KMS configuration for [SSE-S3](#sses3).
+- **SSE-S3**: The Silo server en/decrypts an object with a secret key managed by a KMS. Therefore, Silo requires a valid KMS configuration for [SSE-S3](#sses3).
 
 ### Server-Side Encryption - Preliminaries
 
 #### Secret Keys
 
-The MinIO server uses a unique, randomly generated secret key per object also known as, Object Encryption Key ([OEK](#oek)). Neither the client-provided SSE-C key nor the KMS-managed key is directly used to en/decrypt an object. Instead, the OEK is stored as part of the object metadata next to the object in an encrypted form. To en/decrypt the OEK another secret key is needed also known as, Key Encryption Key ([KEK](#kek)).
+The Silo server uses a unique, randomly generated secret key per object also known as, Object Encryption Key ([OEK](#oek)). Neither the client-provided SSE-C key nor the KMS-managed key is directly used to en/decrypt an object. Instead, the OEK is stored as part of the object metadata next to the object in an encrypted form. To en/decrypt the OEK another secret key is needed also known as, Key Encryption Key ([KEK](#kek)).
 
-The MinIO server runs a key-derivation algorithm to generate the KEK using a pseudo-random function ([PRF](#prf)):
+The Silo server runs a key-derivation algorithm to generate the KEK using a pseudo-random function ([PRF](#prf)):
 `KEK := PRF(EK, IV, context_values)` where:
 
 - [EK](#ek): is the external key. In case of SSE-C this is the client-provided key. In case of SSE-S3  this is secret key generated by the KMS. For further details see [SSE-C](#Server-Side-Encryption-with-client-provided-Keys) or [SSE-S3](#Server-Side-Encryption-with-a-KMS).
@@ -32,7 +32,7 @@ To summarize for any encrypted object there exists (at least) three different ke
 
 #### Content Encryption
 
-The MinIO server uses an authenticated encryption scheme ([AEAD](#aead)) to en/decrypt and authenticate the object content. The AEAD is combined with some state to build a *Secure Channel*. A *Secure Channel* is a cryptographic construction that ensures confidentiality and integrity of the processed data. In particular the *Secure Channel* splits the plaintext content into fixed size chunks and en/decrypts each chunk separately using a unique key-nonce combination.
+The Silo server uses an authenticated encryption scheme ([AEAD](#aead)) to en/decrypt and authenticate the object content. The AEAD is combined with some state to build a *Secure Channel*. A *Secure Channel* is a cryptographic construction that ensures confidentiality and integrity of the processed data. In particular the *Secure Channel* splits the plaintext content into fixed size chunks and en/decrypts each chunk separately using a unique key-nonce combination.
 
 ##### Figure 1 - Secure Channel construction
 
@@ -50,7 +50,7 @@ In case of a S3 multi-part operation each part is en/decrypted with the scheme s
 
 #### Cryptographic Primitives
 
-The SSE schemes described in [Secret Keys](#Secret-Keys) and [Content Encryption](#Content-Encryption) are generic over the cryptographic primitives. However, the MinIO server uses the following cryptographic primitive implementations:
+The SSE schemes described in [Secret Keys](#Secret-Keys) and [Content Encryption](#Content-Encryption) are generic over the cryptographic primitives. However, the Silo server uses the following cryptographic primitive implementations:
 
 - [PRF](#prf): HMAC-SHA-256
 - [AEAD](#aead): AES-256-GCM if the CPU supports AES-NI, ChaCha20-Poly1305 otherwise. More specifically AES-256-GCM is only selected for X86-64 CPUs with AES-NI extension.
@@ -61,13 +61,13 @@ The *Secure Channel* splits the object content into chunks of a fixed size of `6
 
 #### Randomness
 
-The MinIO server generates unique keys and other cryptographic values using a cryptographically secure pseudo-random number generator ([CSPRNG](#csprng)). However, in the context of SSE, the MinIO server does not require that the CSPRNG generates values that are indistinguishable from truly random bit strings. Instead, it is sufficient if the generated values are unique - which is a weaker requirement. Nevertheless other parts - for example the TLS-stack - may require that CSPRNG-generated values are indistinguishable from truly random bit strings.
+The Silo server generates unique keys and other cryptographic values using a cryptographically secure pseudo-random number generator ([CSPRNG](#csprng)). However, in the context of SSE, the Silo server does not require that the CSPRNG generates values that are indistinguishable from truly random bit strings. Instead, it is sufficient if the generated values are unique - which is a weaker requirement. Nevertheless other parts - for example the TLS-stack - may require that CSPRNG-generated values are indistinguishable from truly random bit strings.
 
 ### Server-Side Encryption with client-provided Keys
 
-SSE-C allows an S3 client to en/decrypt an object at the MinIO server. Therefore the S3 client sends a secret key as part of the HTTP request. This secret key is **never** stored by the MinIO server and only resides in RAM during the en/decryption process.
+SSE-C allows an S3 client to en/decrypt an object at the Silo server. Therefore the S3 client sends a secret key as part of the HTTP request. This secret key is **never** stored by the Silo server and only resides in RAM during the en/decryption process.
 
-MinIO does not assume or require that the client-provided key is unique. It may be used for multiple objects or buckets. Especially a single client-provided key may be used for all objects - even though all objects must be treated as compromised if that key is ever compromised.
+Silo does not assume or require that the client-provided key is unique. It may be used for multiple objects or buckets. Especially a single client-provided key may be used for all objects - even though all objects must be treated as compromised if that key is ever compromised.
 
 #### Key rotation
 
@@ -80,7 +80,7 @@ Such a special COPY request is also known as S3 SSE-C key rotation.
 
 ### Server-Side Encryption with a KMS
 
-SSE-S3 allows an S3 client to en/decrypt an object at the MinIO server using a KMS. The MinIO
+SSE-S3 allows an S3 client to en/decrypt an object at the Silo server using a KMS. The Silo
 server only assumes that the KMS provides two services:
 
 - `GenerateKey`: Takes a key ID and generates a new data key from a master key referenced by the key ID. It returns the new data key in two different forms: The plain data key and the data key encrypted using the master key.
@@ -89,7 +89,7 @@ server only assumes that the KMS provides two services:
 
 More details about supported KMS implementations and configuration can be found at the [KMS guide](https://github.com/pgsty/minio/blob/master/docs/kms/README.md).
 
-The MinIO server requests a new data key from the KMS for each uploaded object and uses that data key as EK. Additionally it stores the encrypted form of the data key and the master key ID as part of the object metadata. The plain data only resides in RAM during the en/decryption process. The MinIO server does not store any SSE-related key at the KMS. Instead the KMS is treated as trusted component that performs key sealing/unsealing operations to build a key hierarchy:
+The Silo server requests a new data key from the KMS for each uploaded object and uses that data key as EK. Additionally it stores the encrypted form of the data key and the master key ID as part of the object metadata. The plain data only resides in RAM during the en/decryption process. The Silo server does not store any SSE-related key at the KMS. Instead the KMS is treated as trusted component that performs key sealing/unsealing operations to build a key hierarchy:
 
 #### Figure 2 - KMS key hierarchy
 
@@ -121,7 +121,7 @@ The MinIO server requests a new data key from the KMS for each uploaded object a
 
 #### Key rotation - Basic Operation
 
-The MinIO server supports key rotation for SSE-S3 encrypted objects. The minio server decrypts the OEK using the current encrypted data key and the master key ID of the object metadata. If this succeeds, the server requests a new data key from the KMS using the master key ID of the **current MinIO KMS configuration** and re-wraps the *OEK* with a new *KEK* derived from the new data key / EK:
+The Silo server supports key rotation for SSE-S3 encrypted objects. The Silo server decrypts the OEK using the current encrypted data key and the master key ID of the object metadata. If this succeeds, the server requests a new data key from the KMS using the master key ID of the **current Silo KMS configuration** and re-wraps the *OEK* with a new *KEK* derived from the new data key / EK:
 
 ##### Figure 3 - KMS data key rotation
 
@@ -166,9 +166,9 @@ Only the root/admin user can perform an SSE-S3 key rotation using the Admin-API
 
 #### Secure Erasure and Locking
 
-The MinIO server requires an available KMS to en/decrypt SSE-S3 encrypted objects. Therefore it is possible to erase or lock some or all encrypted objects. For example in case of a detected attack or other emergency situations the following actions can be taken:
+The Silo server requires an available KMS to en/decrypt SSE-S3 encrypted objects. Therefore it is possible to erase or lock some or all encrypted objects. For example in case of a detected attack or other emergency situations the following actions can be taken:
 
-- Seal the KMS such that it cannot be accessed by MinIO server anymore. That will lock **all** SSE-S3 encrypted objects protected by master keys stored on the KMS. All these objects can not be decrypted as long as the KMS is sealed.
+- Seal the KMS such that it cannot be accessed by the Silo server anymore. That will lock **all** SSE-S3 encrypted objects protected by master keys stored on the KMS. All these objects can not be decrypted as long as the KMS is sealed.
 - Seal/Unmount one/some master keys. That will lock all SSE-S3 encrypted objects protected by these master keys. All these objects can not be decrypted as long as the key(s) are sealed.
 - Delete one/some master keys. From a security standpoint, this is equal to erasing all SSE-S3 encrypted objects protected by these master keys. All these objects are lost forever as they cannot be decrypted. Especially deleting all master keys at the KMS is equivalent to secure erasing all SSE-S3 encrypted objects.
 

docs/security/source-address-trust.md

@@ -1,6 +1,6 @@
 # Client source address trust
 
-MinIO decides where a request came from, and that decision is load-bearing. The
+Silo decides where a request came from, and that decision is load-bearing. The
 address it settles on becomes:
 
 - `aws:SourceIp`, so it decides `IpAddress` and `NotIpAddress` policy conditions
@@ -11,7 +11,7 @@ address it settles on becomes:
 
 None of that is derived from the TCP connection by default. It is read out of the
 `X-Forwarded-For`, `X-Real-IP` and RFC 7239 `Forwarded` request headers, which
-any client can set to any value. This document states which peers MinIO believes,
+any client can set to any value. This document states which peers Silo believes,
 how to change that, and what each choice costs.
 
 ## The three modes
@@ -66,7 +66,7 @@ that overwrites all three headers. Two things commonly break that assumption:
 - **Appending proxies.** The stock nginx recipe
   `proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;` *appends* to
   what the client sent. A client sending `X-Forwarded-For: 1.2.3.4` produces
-  `1.2.3.4, <real client>` at MinIO, and this mode reads the left-most entry —
+  `1.2.3.4, <real client>` at Silo, and this mode reads the left-most entry —
   the client's. Overwriting with `$remote_addr` avoids this; so does the
   allow-listed mode below, which reads the chain from the other end.
 
@@ -78,11 +78,11 @@ MINIO_API_TRUSTED_PROXIES=none
 
 No forwarded header is believed. The source address is the TCP peer, always.
 
-Use this when MinIO is reached directly and you would rather have a correct
+Use this when Silo is reached directly and you would rather have a correct
 address that is sometimes a proxy than a plausible one that is sometimes a lie.
 Behind a proxy, every request will be attributed to the proxy.
 
-**On a multi-node deployment this also applies to MinIO's own nodes.** Some
+**On a multi-node deployment this also applies to Silo's own nodes.** Some
 requests are forwarded between nodes (see [Multi-node](#multi-node-deployments)),
 and the receiving node's peer is the forwarding node, so those requests are
 attributed to it rather than to the client. Nothing corrects this under this
@@ -147,7 +147,7 @@ the list.** It is trusted verbatim, and only when the chain headers yield
 nothing. The deployment contract is that a listed proxy overwrites whichever
 headers it sets — for nginx, `proxy_set_header X-Real-IP $remote_addr;`. A proxy
 that relays the client's copy instead is choosing to let the client answer the
-question, and nothing MinIO does can undo that.
+question, and nothing Silo does can undo that.
 
 > **Strip at the edge every source-address header your proxy does not itself
 > write.** This is the one rule that covers every case, and it is worth following
@@ -180,7 +180,7 @@ not skipped — only peers are exempt, not chain entries.
 
 ## Multi-node deployments
 
-**A cluster must list its own nodes.** MinIO forwards some requests between
+**A cluster must list its own nodes.** Silo forwards some requests between
 nodes — bucket-DNS and site-replication routing, listing continuation,
 heal-by-token, batch jobs and pool decommissioning. The receiving node's peer is
 the forwarding node, so unless the cluster's own addresses are on the list, those
@@ -202,7 +202,7 @@ appends, or you are in the second case below. Otherwise:
 - Direct exposure, no proxy: `MINIO_API_TRUSTED_PROXIES=none`.
 - Behind a proxy, but the port is also reachable directly (the usual Kubernetes
   Ingress-plus-Service case, and the usual Pigsty case): set
-  `MINIO_API_TRUSTED_PROXIES` to the proxy addresses plus the MinIO node
+  `MINIO_API_TRUSTED_PROXIES` to the proxy addresses plus the Silo node
   addresses. This is the configuration that makes an `IpAddress` condition mean
   something.
 - Multi-node clusters: use the allow-list with node addresses included, not

docs/select/README.md

@@ -1,4 +1,4 @@
-# Select API Quickstart Guide [![Slack](https://slack.min.io/slack?type=svg)](https://slack.min.io)
+# Select API Quickstart Guide
 
 Traditional retrieval of objects is always as whole entities, i.e GetObject for a 5 GiB object, will always return 5 GiB of data. S3 Select API allows us to retrieve a subset of data by using simple SQL expressions. By using Select API to retrieve only the data needed by the application, drastic performance improvements can be achieved.
 
@@ -14,7 +14,7 @@ Type inference and automatic conversion of values is performed based on the cont
 
 The [mc sql](https://silo.pgsty.com/reference/minio-mc/mc-sql/) command can be used for executing queries using the command line.
 
-(*) Parquet is disabled on the MinIO server by default. See below how to enable it.
+(*) Parquet is disabled on the Silo server by default. See below how to enable it.
 
 ## Enabling Parquet Format
 
@@ -27,7 +27,7 @@ To enable Parquet set the environment variable `MINIO_API_SELECT_PARQUET=on`.
 
 ### 1. Prerequisites
 
-- Install MinIO Server from [here](https://silo.pgsty.com/operations/deployments/baremetal-deploy-minio-on-redhat-linux/#procedure).
+- Install Silo Server from [here](https://silo.pgsty.com/operations/deployments/baremetal-deploy-minio-on-redhat-linux/#procedure).
 - Familiarity with AWS S3 API.
 - Familiarity with Python and installing dependencies.
 
@@ -48,7 +48,7 @@ import boto3
 s3 = boto3.client('s3',
                   endpoint_url='http://localhost:9000',
                   aws_access_key_id='minio',
-                  aws_secret_access_key='minio123',
+                  aws_secret_access_key='silo123',
                   region_name='us-east-1')
 
 r = s3.select_object_content(
@@ -79,13 +79,13 @@ for event in r['Payload']:
 
 ## 4. Run the Program
 
-Upload a sample dataset to MinIO using the following commands.
+Upload a sample dataset to Silo using the following commands.
 
 ```sh
 curl "https://population.un.org/wpp/Download/Files/1_Indicators%20(Standard)/CSV_FILES/WPP2019_TotalPopulationBySex.csv" > TotalPopulation.csv
-mc mb myminio/mycsvbucket
+mc mb mysilo/mycsvbucket
 gzip TotalPopulation.csv
-mc cp TotalPopulation.csv.gz myminio/mycsvbucket/sampledata/
+mc cp TotalPopulation.csv.gz mysilo/mycsvbucket/sampledata/
 ```
 
 Now let us proceed to run our select example to query for `Location` which matches `United States`.
@@ -113,11 +113,11 @@ For a more detailed SELECT SQL reference, please see [here](https://docs.aws.ama
 
 ## 5. Explore Further
 
-- [Use `mc` with MinIO Server](https://silo.pgsty.com/reference/minio-mc/)
+- [Use `mc` with Silo Server](https://silo.pgsty.com/reference/minio-mc/)
-- [Use `mc sql` with MinIO Server](https://silo.pgsty.com/reference/minio-mc/mc-sql/#command-mc.sql)
+- [Use `mc sql` with Silo Server](https://silo.pgsty.com/reference/minio-mc/mc-sql/#command-mc.sql)
-- [Use `minio-go` SDK with MinIO Server](https://silo.pgsty.com/developers/go/minio-go/)
+- [Use `minio-go` SDK with Silo Server](https://silo.pgsty.com/developers/go/minio-go/)
-- [Use `aws-cli` with MinIO Server](https://silo.pgsty.com/integrations/aws-cli-with-minio/)
+- [Use `aws-cli` with Silo Server](https://silo.pgsty.com/integrations/aws-cli-with-minio/)
-- [The MinIO documentation website](https://silo.pgsty.com/docs/)
+- [The Silo documentation website](https://silo.pgsty.com/docs/)
 
 ## 6. Implementation Status
 

docs/site-replication/README.md

@@ -1,6 +1,6 @@
 # Automatic Site Replication
 
-This feature allows multiple independent MinIO sites (or clusters) that are using the same external IDentity Provider (IDP) to be configured as replicas. In this situation the set of replica sites are referred to as peer sites or just sites. When site-replication is enabled on a set of sites, the following changes are replicated to all other sites:
+This feature allows multiple independent Silo sites (or clusters) that are using the same external IDentity Provider (IDP) to be configured as replicas. In this situation the set of replica sites are referred to as peer sites or just sites. When site-replication is enabled on a set of sites, the following changes are replicated to all other sites:
 
 - Creation and deletion of buckets and objects
 - Creation and deletion of all IAM users, groups, policies and their mappings to users or groups
@@ -25,36 +25,36 @@ The following Bucket features will **not be replicated**, is designed to differ
 
 - **Removing a site** is not allowed from a set of replicated sites once configured.
 - All sites must be using the **same** external IDP(s) if any.
-- For [SSE-S3 or SSE-KMS encryption via KMS](https://silo.pgsty.com/operations/server-side-encryption/ "MinIO KMS Guide"), all sites **must**  have access to a central KMS deployment. This can be achieved via a central KES server or multiple KES servers (say one per site) connected via a central KMS (Vault) server.
+- For [SSE-S3 or SSE-KMS encryption via KMS](https://silo.pgsty.com/operations/server-side-encryption/ "Silo KMS Guide"), all sites **must**  have access to a central KMS deployment. This can be achieved via a central KES server or multiple KES servers (say one per site) connected via a central KMS (Vault) server.
 
 ## Configuring Site Replication
 
-- Configure an alias in `mc` for each of the sites. For example if you have three MinIO sites, you may run:
+- Configure an alias in `mc` for each of the sites. For example if you have three Silo sites, you may run:
 
 ```sh
-mc alias set minio1 https://minio1.example.com:9000 adminuser adminpassword
+mc alias set silo1 https://silo1.example.com:9000 adminuser adminpassword
-mc alias set minio2 https://minio2.example.com:9000 adminuser adminpassword
+mc alias set silo2 https://silo2.example.com:9000 adminuser adminpassword
-mc alias set minio3 https://minio3.example.com:9000 adminuser adminpassword
+mc alias set silo3 https://silo3.example.com:9000 adminuser adminpassword
 ```
 
 or
 
 ```sh
-export MC_HOST_minio1=https://adminuser:adminpassword@minio1.example.com
+export MC_HOST_silo1=https://adminuser:adminpassword@silo1.example.com
-export MC_HOST_minio2=https://adminuser:adminpassword@minio2.example.com
+export MC_HOST_silo2=https://adminuser:adminpassword@silo2.example.com
-export MC_HOST_minio3=https://adminuser:adminpassword@minio3.example.com
+export MC_HOST_silo3=https://adminuser:adminpassword@silo3.example.com
 ```
 
 - Add site replication configuration with:
 
 ```sh
-mc admin replicate add minio1 minio2 minio3
+mc admin replicate add silo1 silo2 silo3
 ```
 
 - Once the above command returns success, you may query site replication configuration with:
 
 ```sh
-mc admin replicate info minio1
+mc admin replicate info silo1
 ```
 
 ** Note **

docs/site-replication/gen-oidc-sts-cred.go

@@ -21,7 +21,7 @@
 package main
 
 // This programs mocks user interaction against Dex IDP and generates STS
-// credentials. It is for MinIO testing purposes only.
+// credentials. It is for Silo testing purposes only.
 //
 // Run like:
 //
@@ -43,7 +43,7 @@ func main() {
 
 	endpoint := os.Getenv("MINIO_ENDPOINT")
 	if endpoint == "" {
-		log.Fatalf("Please specify a MinIO server endpoint environment variable like:\n\n\texport MINIO_ENDPOINT=http://localhost:9000")
+		log.Fatalf("Please specify a Silo server endpoint environment variable like:\n\n\texport MINIO_ENDPOINT=http://localhost:9000")
 	}
 
 	appParams := cmd.OpenIDClientAppParams{

docs/sts/README.md

@@ -1,8 +1,8 @@
-# MinIO STS Quickstart Guide [![Slack](https://slack.min.io/slack?type=svg)](https://slack.min.io)
+# Silo STS Quickstart Guide
 
-The MinIO Security Token Service (STS) is an endpoint service that enables clients to request temporary credentials for MinIO resources. Temporary credentials work almost identically to default admin credentials, with some differences:
+The Silo Security Token Service (STS) is an endpoint service that enables clients to request temporary credentials for Silo resources. Temporary credentials work almost identically to default admin credentials, with some differences:
 
-- Temporary credentials are short-term, as the name implies. They can be configured to last for anywhere from a few minutes to several hours. After the credentials expire, MinIO no longer recognizes them or allows any kind of access from API requests made with them.
+- Temporary credentials are short-term, as the name implies. They can be configured to last for anywhere from a few minutes to several hours. After the credentials expire, Silo no longer recognizes them or allows any kind of access from API requests made with them.
 - Temporary credentials do not need to be stored with the application but are generated dynamically and provided to the application when requested. When (or even before) the temporary credentials expire, the application can request new credentials.
 
 Following are advantages for using temporary credentials:
@@ -17,7 +17,7 @@ Following are advantages for using temporary credentials:
 | :----------------------                                                                | ------------------------------------------                                                                                                    |
 | [**WebIdentity**](https://github.com/pgsty/minio/blob/master/docs/sts/web-identity.md) | Let users request temporary credentials using any OpenID(OIDC) compatible web identity providers such as KeyCloak, Dex, Facebook, Google etc. |
 | [**AD/LDAP**](https://github.com/pgsty/minio/blob/master/docs/sts/ldap.md)             | Let AD/LDAP users request temporary credentials using AD/LDAP username and password.                                                          |
-| [**AssumeRole**](https://github.com/pgsty/minio/blob/master/docs/sts/assume-role.md)   | Let MinIO users request temporary credentials using user access and secret keys.                                                              |
+| [**AssumeRole**](https://github.com/pgsty/minio/blob/master/docs/sts/assume-role.md)   | Let Silo users request temporary credentials using user access and secret keys.                                                              |
 
 ### Understanding JWT Claims
 
@@ -44,33 +44,33 @@ In this document we will explain in detail on how to configure all the prerequis
 - [Configuring keycloak](https://github.com/pgsty/minio/blob/master/docs/sts/keycloak.md) or [Configuring Casdoor](https://github.com/pgsty/minio/blob/master/docs/sts/casdoor.md)
 - [Configuring etcd](https://github.com/pgsty/minio/blob/master/docs/sts/etcd.md)
 
-### Setup MinIO with Identity Provider
+### Setup Silo with Identity Provider
 
-Make sure we have followed the previous step and configured each software independently, once done we can now proceed to use MinIO STS API and MinIO server to use these credentials to perform object API operations.
+Make sure we have followed the previous step and configured each software independently, once done we can now proceed to use Silo STS API and Silo server to use these credentials to perform object API operations.
 
 #### KeyCloak
 
 ```
 export MINIO_ROOT_USER=minio
-export MINIO_ROOT_PASSWORD=minio123
+export MINIO_ROOT_PASSWORD=silo123
 export MINIO_IDENTITY_OPENID_CONFIG_URL=http://localhost:8080/auth/realms/demo/.well-known/openid-configuration
 export MINIO_IDENTITY_OPENID_CLIENT_ID="843351d4-1080-11ea-aa20-271ecba3924a"
-minio server /mnt/data
+silo server /mnt/data
 ```
 
 #### Casdoor
 
 ```
 export MINIO_ROOT_USER=minio
-export MINIO_ROOT_PASSWORD=minio123
+export MINIO_ROOT_PASSWORD=silo123
 export MINIO_IDENTITY_OPENID_CONFIG_URL=http://CASDOOR_ENDPOINT/.well-known/openid-configuration
 export MINIO_IDENTITY_OPENID_CLIENT_ID="843351d4-1080-11ea-aa20-271ecba3924a"
-minio server /mnt/data
+silo server /mnt/data
 ```
 
 ### Using WebIdentiy API
 
-On another terminal run `web-identity.go` a sample client application which obtains JWT id_tokens from an identity provider, in our case its Keycloak. Uses the returned id_token response to get new temporary credentials from the MinIO server using the STS API call `AssumeRoleWithWebIdentity`.
+On another terminal run `web-identity.go` a sample client application which obtains JWT id_tokens from an identity provider, in our case its Keycloak. Uses the returned id_token response to get new temporary credentials from the Silo server using the STS API call `AssumeRoleWithWebIdentity`.
 
 ```
 $ go run docs/sts/web-identity.go -cid account -csec 072e7f00-4289-469c-9ab2-bbe843c7f5a8  -config-ep "http://localhost:8080/auth/realms/demo/.well-known/openid-configuration" -port 8888
@@ -95,16 +95,16 @@ This will open the login page of keycloak, upon successful login, STS credential
 
 > NOTE: You can use the `-cscopes` parameter to restrict the requested scopes, for example to `"openid,policy_role_attribute"`, being `policy_role_attribute` a client_scope / client_mapper that maps a role attribute called policy to a `policy` claim returned by Keycloak.
 
-These credentials can now be used to perform MinIO API operations.
+These credentials can now be used to perform Silo API operations.
 
-### Using MinIO Console
+### Using Silo Console
 
-- Open MinIO URL on the browser, lets say <http://localhost:9000/>
+- Open Silo URL on the browser, lets say <http://localhost:9000/>
 - Click on `Login with SSO`
-- User will be redirected to the Keycloak user login page, upon successful login the user will be redirected to MinIO page and logged in automatically,
+- User will be redirected to the Keycloak user login page, upon successful login the user will be redirected to Silo page and logged in automatically,
   the user should see now the buckets and objects they have access to.
 
 ## Explore Further
 
-- [MinIO Admin Complete Guide](https://silo.pgsty.com/reference/minio-mc-admin/)
+- [Silo Admin Complete Guide](https://silo.pgsty.com/reference/minio-mc-admin/)
-- [The MinIO documentation website](https://silo.pgsty.com/docs/)
+- [The Silo documentation website](https://silo.pgsty.com/docs/)

docs/sts/assume-role.go

@@ -36,7 +36,7 @@ import (
 )
 
 var (
-	// Minio endpoint (for STS API)
+	// Silo endpoint (for STS API)
 	stsEndpoint string
 
 	// User account credentials
@@ -58,8 +58,8 @@ var (
 
 func init() {
 	flag.StringVar(&stsEndpoint, "sts-ep", "http://localhost:9000", "STS endpoint")
-	flag.StringVar(&minioUsername, "u", "", "MinIO Username")
+	flag.StringVar(&minioUsername, "u", "", "Silo username")
-	flag.StringVar(&minioPassword, "p", "", "MinIO Password")
+	flag.StringVar(&minioPassword, "p", "", "Silo password")
 	flag.BoolVar(&displayCreds, "d", false, "Only show generated credentials")
 	flag.DurationVar(&expiryDuration, "e", 0, "Request a duration of validity for the generated credential")
 	flag.StringVar(&bucketToList, "b", "", "Bucket to list (defaults to username)")
@@ -132,7 +132,7 @@ func main() {
 	}
 
 	// API requests are secure (HTTPS) if secure=true and insecure (HTTP) otherwise.
-	// New returns an MinIO Admin client object.
+	// New returns a compatible Admin API client object.
 	madmClnt, err := madmin.NewWithOptions(stsEndpointURL.Host, mopts)
 	if err != nil {
 		log.Fatalln(err)
@@ -143,13 +143,13 @@ func main() {
 		log.Fatalln(err)
 	}
 
-	// Use generated credentials to authenticate with MinIO server
+	// Use generated credentials to authenticate with Silo server
 	minioClient, err := minio.New(stsEndpointURL.Host, opts)
 	if err != nil {
 		log.Fatalf("Error initializing client: %v", err)
 	}
 
-	// Use minIO Client object normally like the regular client.
+	// Use the minio-go Client object like a regular client.
 	if bucketToList == "" {
 		bucketToList = minioUsername
 	}

docs/sts/assume-role.md

@@ -1,13 +1,13 @@
-# AssumeRole [![Slack](https://slack.min.io/slack?type=svg)](https://slack.min.io)
+# AssumeRole
 
 ## Introduction
 
-Returns a set of temporary security credentials that you can use to access MinIO resources. AssumeRole requires authorization credentials for an existing user on MinIO. The advantages of this API are
+Returns a set of temporary security credentials that you can use to access Silo resources. AssumeRole requires authorization credentials for an existing user on Silo. The advantages of this API are
 
 - To be able to reliably use S3 multipart APIs feature of the SDKs without re-inventing the wheel of pre-signing the each URL in multipart API. This is very tedious to implement with all the scenarios of fault tolerance that's already implemented by the client SDK. The general client SDKs don't support multipart with presigned URLs.
 - To be able to easily get the temporary credentials to upload to a prefix. Make it possible for a client to upload a whole folder using the session. The server side applications need not create a presigned URL and serve to the client for each file. Since, the client would have the session it can do it by itself.
 
-The temporary security credentials returned by this API consists of an access key, a secret key, and a security token. Applications can use these temporary security credentials to sign calls to MinIO API operations. The policy applied to these temporary credentials is inherited from the MinIO user credentials. By default, the temporary security credentials created by AssumeRole last for one hour. However, use the optional DurationSeconds parameter to specify the duration of the credentials. This value varies from 900 seconds (15 minutes) up to the maximum session duration of 365 days.
+The temporary security credentials returned by this API consists of an access key, a secret key, and a security token. Applications can use these temporary security credentials to sign calls to Silo API operations. The policy applied to these temporary credentials is inherited from the Silo user credentials. By default, the temporary security credentials created by AssumeRole last for one hour. However, use the optional DurationSeconds parameter to specify the duration of the credentials. This value varies from 900 seconds (15 minutes) up to the maximum session duration of 365 days.
 
 ## API Request Parameters
 
@@ -85,8 +85,8 @@ http://minio:9000/?Action=AssumeRole&DurationSeconds=3600&Version=2011-06-15&Pol
 
 ```
 export MINIO_ROOT_USER=minio
-export MINIO_ROOT_PASSWORD=minio123
+export MINIO_ROOT_PASSWORD=silo123
-minio server ~/test
+silo server ~/test
 ```
 
 Create new users following the multi-user guide [here](https://silo.pgsty.com/administration/identity-access-management/)
@@ -102,7 +102,7 @@ aws_access_key_id = foobar
 aws_secret_access_key = foo12345
 ```
 
-> NOTE: In the following commands `--role-arn` and `--role-session-name` are not meaningful for MinIO and can be set to any value satisfying the command line requirements.
+> NOTE: In the following commands `--role-arn` and `--role-session-name` are not meaningful for Silo and can be set to any value satisfying the command line requirements.
 
 ```
 $ aws --profile foobar --endpoint-url http://localhost:9000 sts assume-role --policy '{"Version":"2012-10-17","Statement":[{"Sid":"Stmt1","Effect":"Allow","Action":"s3:*","Resource":"arn:aws:s3:::*"}]}' --role-arn arn:xxx:xxx:xxx:xxxx --role-session-name anything
@@ -134,5 +134,5 @@ SessionToken: eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJhY2Nlc3NLZXkiOiIyN1lEUllFT
 
 ## Explore Further
 
-- [MinIO Admin Complete Guide](https://silo.pgsty.com/reference/minio-mc-admin/)
+- [Silo Admin Complete Guide](https://silo.pgsty.com/reference/minio-mc-admin/)
-- [The MinIO documentation website](https://silo.pgsty.com/docs/)
+- [The Silo documentation website](https://silo.pgsty.com/docs/)

docs/sts/casdoor.md

@@ -1,6 +1,6 @@
-# Casdoor Quickstart Guide [![Slack](https://slack.min.io/slack?type=svg)](https://slack.min.io)
+# Casdoor Quickstart Guide
 
-Casdoor is a UI-first centralized authentication / Single-Sign-On (SSO) platform supporting OAuth 2.0, OIDC and SAML, integrated with Casbin RBAC and ABAC permission management. This document covers configuring Casdoor identity provider support with MinIO.
+Casdoor is a UI-first centralized authentication / Single-Sign-On (SSO) platform supporting OAuth 2.0, OIDC and SAML, integrated with Casbin RBAC and ABAC permission management. This document covers configuring Casdoor identity provider support with Silo.
 
 ## Prerequisites
 
@@ -18,23 +18,23 @@ For a quick installation, docker-compose reference configs are also available on
 
 - Go to Users
   - Edit the user
-    - Add your MinIO policy (ex: `readwrite`) in `Tag`
+    - Add your Silo policy (ex: `readwrite`) in `Tag`
     - Save
 
 - Open your favorite browser and visit: **http://`CASDOOR_ENDPOINT`/.well-known/openid-configuration**, you will see the OIDC configure of Casdoor.
 
-### Configure MinIO
+### Configure Silo
 
 ```
 export MINIO_ROOT_USER=minio
-export MINIO_ROOT_PASSWORD=minio123
+export MINIO_ROOT_PASSWORD=silo123
-minio server /mnt/export
+silo server /mnt/export
 ```
 
 Here are all the available options to configure OpenID connect
 
 ```
-mc admin config set myminio/ identity_openid
+mc admin config set mysilo/ identity_openid
 
 KEY:
 identity_openid  enable OpenID SSO support
@@ -51,7 +51,7 @@ comment       (sentence)  optionally add a comment to this setting
 and ENV based options
 
 ```
-mc admin config set myminio/ identity_openid --env
+mc admin config set mysilo/ identity_openid --env
 
 KEY:
 identity_openid  enable OpenID SSO support
@@ -65,23 +65,23 @@ MINIO_IDENTITY_OPENID_SCOPES        (csv)       Comma separated list of OpenID s
 MINIO_IDENTITY_OPENID_COMMENT       (sentence)  optionally add a comment to this setting
 ```
 
-Set `identity_openid` config with `config_url`, `client_id` and restart MinIO
+Set `identity_openid` config with `config_url`, `client_id` and restart Silo
 
 ```
-~ mc admin config set myminio identity_openid config_url="http://CASDOOR_ENDPOINT/.well-known/openid-configuration" client_id=<client id> client_secret=<client secret> claim_name="tag"
+~ mc admin config set mysilo identity_openid config_url="http://CASDOOR_ENDPOINT/.well-known/openid-configuration" client_id=<client id> client_secret=<client secret> claim_name="tag"
 ```
 
-> NOTE: As MinIO needs to use a claim attribute in JWT for its policy, you should configure it in casdoor as well. Currently, casdoor uses `tag` as a workaround for configuring MinIO's policy.
+> NOTE: As Silo needs to use a claim attribute in JWT for its policy, you should configure it in casdoor as well. Currently, casdoor uses `tag` as a workaround for configuring Silo's policy.
 
-Once successfully set restart the MinIO instance.
+Once successfully set restart the Silo instance.
 
 ```
-mc admin service restart myminio
+mc admin service restart mysilo
 ```
 
 ### Using WebIdentiy API
 
-On another terminal run `web-identity.go` a sample client application which obtains JWT id_tokens from an identity provider, in our case its Keycloak. Uses the returned id_token response to get new temporary credentials from the MinIO server using the STS API call `AssumeRoleWithWebIdentity`.
+On another terminal run `web-identity.go` a sample client application which obtains JWT id_tokens from an identity provider, in our case its Keycloak. Uses the returned id_token response to get new temporary credentials from the Silo server using the STS API call `AssumeRoleWithWebIdentity`.
 
 ```
 $ go run docs/sts/web-identity.go -cid account -csec 072e7f00-4289-469c-9ab2-bbe843c7f5a8  -config-ep "http://CASDOOR_ENDPOINT/.well-known/openid-configuration" -port 8888
@@ -102,15 +102,15 @@ This will open the login page of Casdoor, upon successful login, STS credentials
 }
 ```
 
-### Using MinIO Console
+### Using Silo Console
 
-- Open MinIO URL on the browser, lets say <http://localhost:9000/>
+- Open Silo URL on the browser, lets say <http://localhost:9000/>
 - Click on `Login with SSO`
-- User will be redirected to the Casdoor user login page, upon successful login the user will be redirected to MinIO page and logged in automatically,
+- User will be redirected to the Casdoor user login page, upon successful login the user will be redirected to Silo page and logged in automatically,
   the user should see now the buckets and objects they have access to.
 
 ## Explore Further
 
-- [Casdoor MinIO Integration](https://casdoor.org/docs/integration/minio)
+- [Casdoor Silo Integration](https://casdoor.org/docs/integration/minio)
-- [MinIO STS Quickstart Guide](https://silo.pgsty.com/developers/security-token-service/)
+- [Silo STS Quickstart Guide](https://silo.pgsty.com/developers/security-token-service/)
-- [The MinIO documentation website](https://silo.pgsty.com/docs/)
+- [The Silo documentation website](https://silo.pgsty.com/docs/)

docs/sts/client-grants.go

@@ -102,7 +102,7 @@ func main() {
 		log.Fatal(err)
 	}
 
-	// Uncomment this to use MinIO API operations by initializing minio
+	// Uncomment this to use Silo API operations with the compatible minio-go client.
 	// client with obtained credentials.
 
 	opts := &minio.Options{

docs/sts/client-grants.md

@@ -1,12 +1,12 @@
-# AssumeRoleWithClientGrants [![Slack](https://slack.min.io/slack?type=svg)](https://slack.min.io)
+# AssumeRoleWithClientGrants
 
 ## Introduction
 
 Returns a set of temporary security credentials for applications/clients who have been authenticated through client credential grants provided by identity provider. Example providers include KeyCloak, Okta etc.
 
-Calling AssumeRoleWithClientGrants does not require the use of MinIO default credentials. Therefore, client application can be distributed that requests temporary security credentials without including MinIO default credentials. Instead, the identity of the caller is validated by using a JWT access token from the identity provider. The temporary security credentials returned by this API consists of an access key, a secret key, and a security token. Applications can use these temporary security credentials to sign calls to MinIO API operations.
+Calling AssumeRoleWithClientGrants does not require the use of Silo default credentials. Therefore, client application can be distributed that requests temporary security credentials without including Silo default credentials. Instead, the identity of the caller is validated by using a JWT access token from the identity provider. The temporary security credentials returned by this API consists of an access key, a secret key, and a security token. Applications can use these temporary security credentials to sign calls to Silo API operations.
 
-**Breaking change (`CVE-2026-33322`)**: releases after `RELEASE.2026-03-25T00-00-00Z` validate the JWT access token with the provider JWKS endpoint advertised by the configured OpenID discovery document. In practice, MinIO currently accepts the RSA PKCS#1 v1.5 and ECDSA families already implemented in the verifier (`RS256`, `RS384`, `RS512`, `ES256`, `ES384`, `ES512`, plus the existing `RS3*` and `ES3*` aliases). HMAC-signed tokens such as `HS256`, `HS384`, and `HS512` are rejected. Algorithms such as `PS256` and `EdDSA` are not currently supported. `MINIO_IDENTITY_OPENID_CLIENT_SECRET` is used for OpenID/OAuth client interactions only and is not used as a JWT verification key. If your provider previously issued HMAC-signed access tokens for this flow, reconfigure it to publish RSA or ECDSA signing keys through JWKS before upgrading.
+**Breaking change (`CVE-2026-33322`)**: releases after `RELEASE.2026-03-25T00-00-00Z` validate the JWT access token with the provider JWKS endpoint advertised by the configured OpenID discovery document. In practice, Silo currently accepts the RSA PKCS#1 v1.5 and ECDSA families already implemented in the verifier (`RS256`, `RS384`, `RS512`, `ES256`, `ES384`, `ES512`, plus the existing `RS3*` and `ES3*` aliases). HMAC-signed tokens such as `HS256`, `HS384`, and `HS512` are rejected. Algorithms such as `PS256` and `EdDSA` are not currently supported. `MINIO_IDENTITY_OPENID_CLIENT_SECRET` is used for OpenID/OAuth client interactions only and is not used as a JWT verification key. If your provider previously issued HMAC-signed access tokens for this flow, reconfigure it to publish RSA or ECDSA signing keys through JWKS before upgrading.
 
 By default, the temporary security credentials created by AssumeRoleWithClientGrants last for one hour. However, use the optional DurationSeconds parameter to specify the duration of the credentials. This value varies from 900 seconds (15 minutes) up to the maximum session duration of 365 days.
 
@@ -62,7 +62,7 @@ XML error response for this API is similar to [AWS STS AssumeRoleWithWebIdentity
 ## Sample `POST` Request
 
 ```
-http://minio.cluster:9000?Action=AssumeRoleWithClientGrants&DurationSeconds=3600&Token=eyJ4NXQiOiJOVEF4Wm1NeE5ETXlaRGczTVRVMVpHTTBNekV6T0RKaFpXSTRORE5sWkRVMU9HRmtOakZpTVEiLCJraWQiOiJOVEF4Wm1NeE5ETXlaRGczTVRVMVpHTTBNekV6T0RKaFpXSTRORE5sWkRVMU9HRmtOakZpTVEiLCJhbGciOiJSUzI1NiJ9.eyJhdWQiOiJQb0VnWFA2dVZPNDVJc0VOUm5nRFhqNUF1NVlhIiwiYXpwIjoiUG9FZ1hQNnVWTzQ1SXNFTlJuZ0RYajVBdTVZYSIsImlzcyI6Imh0dHBzOlwvXC9sb2NhbGhvc3Q6OTQ0M1wvb2F1dGgyXC90b2tlbiIsImV4cCI6MTU0MTgwOTU4MiwiaWF0IjoxNTQxODA1OTgyLCJqdGkiOiI2Y2YyMGIwZS1lNGZmLTQzZmQtYTdiYS1kYTc3YTE3YzM2MzYifQ.Jm29jPliRvrK6Os34nSK3rhzIYLFjE__zdVGNng3uGKXGKzP3We_i6NPnhA0szJXMOKglXzUF1UgSz8MctbaxFS8XDusQPVe4LkB_45hwBm6TmBxzui911nt-1RbBLN_jZIlvl2lPrbTUH5hSn9kEkph6seWanTNQpz9tNEoVa6R_OX3kpJqxe8tLQUWw453A1JTwFNhdHa6-f1K8_Q_eEZ_4gOYINQ9t_fhTibdbkXZkJQFLop-Jwoybi9s4nwQU_dATocgcufq5eCeNItQeleT-23lGxIz0X7CiJrJynYLdd-ER0F77SumqEb5iCxhxuf4H7dovwd1kAmyKzLxpw&Version=2011-06-15
+http://silo.cluster:9000?Action=AssumeRoleWithClientGrants&DurationSeconds=3600&Token=eyJ4NXQiOiJOVEF4Wm1NeE5ETXlaRGczTVRVMVpHTTBNekV6T0RKaFpXSTRORE5sWkRVMU9HRmtOakZpTVEiLCJraWQiOiJOVEF4Wm1NeE5ETXlaRGczTVRVMVpHTTBNekV6T0RKaFpXSTRORE5sWkRVMU9HRmtOakZpTVEiLCJhbGciOiJSUzI1NiJ9.eyJhdWQiOiJQb0VnWFA2dVZPNDVJc0VOUm5nRFhqNUF1NVlhIiwiYXpwIjoiUG9FZ1hQNnVWTzQ1SXNFTlJuZ0RYajVBdTVZYSIsImlzcyI6Imh0dHBzOlwvXC9sb2NhbGhvc3Q6OTQ0M1wvb2F1dGgyXC90b2tlbiIsImV4cCI6MTU0MTgwOTU4MiwiaWF0IjoxNTQxODA1OTgyLCJqdGkiOiI2Y2YyMGIwZS1lNGZmLTQzZmQtYTdiYS1kYTc3YTE3YzM2MzYifQ.Jm29jPliRvrK6Os34nSK3rhzIYLFjE__zdVGNng3uGKXGKzP3We_i6NPnhA0szJXMOKglXzUF1UgSz8MctbaxFS8XDusQPVe4LkB_45hwBm6TmBxzui911nt-1RbBLN_jZIlvl2lPrbTUH5hSn9kEkph6seWanTNQpz9tNEoVa6R_OX3kpJqxe8tLQUWw453A1JTwFNhdHa6-f1K8_Q_eEZ_4gOYINQ9t_fhTibdbkXZkJQFLop-Jwoybi9s4nwQU_dATocgcufq5eCeNItQeleT-23lGxIz0X7CiJrJynYLdd-ER0F77SumqEb5iCxhxuf4H7dovwd1kAmyKzLxpw&Version=2011-06-15
 ```
 
 ## Sample Response
@@ -90,10 +90,10 @@ http://minio.cluster:9000?Action=AssumeRoleWithClientGrants&DurationSeconds=3600
 
 ```
 export MINIO_ROOT_USER=minio
-export MINIO_ROOT_PASSWORD=minio123
+export MINIO_ROOT_PASSWORD=silo123
 export MINIO_IDENTITY_OPENID_CONFIG_URL=http://localhost:8080/auth/realms/demo/.well-known/openid-configuration
 export MINIO_IDENTITY_OPENID_CLIENT_ID="843351d4-1080-11ea-aa20-271ecba3924a"
-minio server /mnt/export
+silo server /mnt/export
 ```
 
 Testing with an example
@@ -113,5 +113,5 @@ $ go run client-grants.go -cid PoEgXP6uVO45IsENRngDXj5Au5Ya -csec eKsw6z8CtOJVBt
 
 ## Explore Further
 
-- [MinIO Admin Complete Guide](https://silo.pgsty.com/reference/minio-mc-admin/)
+- [Silo Admin Complete Guide](https://silo.pgsty.com/reference/minio-mc-admin/)
-- [The MinIO documentation website](https://silo.pgsty.com/docs/)
+- [The Silo documentation website](https://silo.pgsty.com/docs/)

docs/sts/custom-token-identity.go

@@ -33,7 +33,7 @@ import (
 )
 
 var (
-	// LDAP integrated Minio endpoint
+	// Identity-provider-integrated Silo endpoint
 	stsEndpoint string
 
 	// token to use with AssumeRoleWithCustomToken
@@ -95,7 +95,7 @@ func main() {
 		return
 	}
 
-	// Use generated credentials to authenticate with MinIO server
+	// Use generated credentials to authenticate with Silo server
 	stsEndpointURL, err := url.Parse(stsEndpoint)
 	if err != nil {
 		log.Fatalf("Error parsing sts endpoint: %v", err)
@@ -109,7 +109,7 @@ func main() {
 		log.Fatalf("Error initializing client: ", err)
 	}
 
-	// Use minIO Client object normally like the regular client.
+	// Use the minio-go Client object like a regular client.
 	fmt.Printf("Calling list objects on bucket named `%s` with temp creds:\n===\n", bucketToList)
 	objCh := minioClient.ListObjects(context.Background(), bucketToList, minio.ListObjectsOptions{})
 	for obj := range objCh {

docs/sts/custom-token-identity.md

@@ -1,14 +1,14 @@
-# AssumeRoleWithCustomToken [![Slack](https://slack.min.io/slack?type=svg)](https://slack.min.io)
+# AssumeRoleWithCustomToken
 
 ## Introduction
 
-To integrate with custom authentication methods using the [Identity Management Plugin](../iam/identity-management-plugin.md)), MinIO provides an STS API extension called `AssumeRoleWithCustomToken`.
+To integrate with custom authentication methods using the [Identity Management Plugin](../iam/identity-management-plugin.md)), Silo provides an STS API extension called `AssumeRoleWithCustomToken`.
 
 After configuring the plugin, use the generated Role ARN with `AssumeRoleWithCustomToken` to get temporary credentials to access object storage.
 
 ## API Request
 
-To make an STS API request with this method, send a POST request to the MinIO endpoint with following query parameters:
+To make an STS API request with this method, send a POST request to the Silo endpoint with following query parameters:
 
 | Parameter       | Type    | Required |                                                                      |
 |-----------------|---------|----------|----------------------------------------------------------------------|

docs/sts/dex.md

@@ -1,4 +1,4 @@
-# Dex Quickstart Guide [![Slack](https://slack.min.io/slack?type=svg)](https://slack.min.io)
+# Dex Quickstart Guide
 
 Dex is an identity service that uses OpenID Connect to drive authentication for apps. Dex acts as a portal to other identity providers through "connectors." This lets dex defer authentication to LDAP servers, SAML providers, or established identity providers like GitHub, Google, and Active Directory. Clients write their authentication logic once to talk to dex, then dex handles the protocols for a given backend.
 
@@ -22,12 +22,12 @@ time="2020-07-12T20:45:50Z" level=info msg="config id tokens valid for: 3h0m0s"
 time="2020-07-12T20:45:50Z" level=info msg="listening (http) on 0.0.0.0:5556"
 ```
 
-### Configure MinIO server with Dex
+### Configure Silo server with Dex
 
 ```
 ~ export MINIO_IDENTITY_OPENID_CLAIM_NAME=name
 ~ export MINIO_IDENTITY_OPENID_CONFIG_URL=http://127.0.0.1:5556/dex/.well-known/openid-configuration
-~ minio server ~/test
+~ silo server ~/test
 ```
 
 ### Run the `web-identity.go`
@@ -69,7 +69,7 @@ You will be redirected to dex login screen - click "Login with email", enter use
 
 and then click "Grant access"
 
-On the browser now you shall see the list of buckets output, along with your temporary credentials obtained from MinIO.
+On the browser now you shall see the list of buckets output, along with your temporary credentials obtained from Silo.
 
 ```
 {
@@ -87,7 +87,7 @@ On the browser now you shall see the list of buckets output, along with your tem
 }
 ```
 
-Now you have successfully configured Dex IdP with MinIO.
+Now you have successfully configured Dex IdP with Silo.
 
 > NOTE: Dex supports groups with external connectors so you can use `groups` as policy claim instead of `name`.
 
@@ -95,9 +95,9 @@ Now you have successfully configured Dex IdP with MinIO.
 export MINIO_IDENTITY_OPENID_CLAIM_NAME=groups
 ```
 
-and add relevant policies on MinIO using `mc admin policy create myminio/ <group_name> group-access.json`
+and add relevant policies on Silo using `mc admin policy create mysilo/ <group_name> group-access.json`
 
 ## Explore Further
 
-- [MinIO STS Quickstart Guide](https://silo.pgsty.com/developers/security-token-service/)
+- [Silo STS Quickstart Guide](https://silo.pgsty.com/developers/security-token-service/)
-- [The MinIO documentation website](https://silo.pgsty.com/docs/)
+- [The Silo documentation website](https://silo.pgsty.com/docs/)

docs/sts/etcd.md

@@ -1,4 +1,4 @@
-# etcd V3 Quickstart Guide [![Slack](https://slack.min.io/slack?type=svg)](https://slack.min.io)
+# etcd V3 Quickstart Guide
 
 etcd is a distributed key value store that provides a reliable way to store data across a cluster of machines.
 
@@ -35,22 +35,22 @@ rm -rf /tmp/etcd-data.tmp && mkdir -p /tmp/etcd-data.tmp && \
 
 You may also setup etcd with TLS following this documentation [here](https://coreos.com/etcd/docs/latest/op-guide/security.html)
 
-### 3. Setup MinIO with etcd
+### 3. Setup Silo with etcd
 
-MinIO server expects environment variable for etcd as `MINIO_ETCD_ENDPOINTS`, this environment variable takes many comma separated entries.
+Silo server expects environment variable for etcd as `MINIO_ETCD_ENDPOINTS`, this environment variable takes many comma separated entries.
 
 ```
 export MINIO_ETCD_ENDPOINTS=http://localhost:2379
-minio server /data
+silo server /data
 ```
 
 NOTE: If `etcd` is configured with `Client-to-server authentication with HTTPS client certificates` then you need to use additional envs such as `MINIO_ETCD_CLIENT_CERT` pointing to path to `etcd-client.crt` and `MINIO_ETCD_CLIENT_CERT_KEY` path to `etcd-client.key` .
 
-### 4. Test with MinIO STS API
+### 4. Test with Silo STS API
 
 Once etcd is configured, **any STS configuration** will work including Client Grants, Web Identity or AD/LDAP.
 
-For example, you can configure STS with Client Grants (KeyCloak) using the guides at [MinIO STS Quickstart Guide](https://silo.pgsty.com/developers/security-token-service/) and [KeyCloak Configuration Guide](https://github.com/pgsty/minio/blob/master/docs/sts/keycloak.md). Once this is done, STS credentials can be generated:
+For example, you can configure STS with Client Grants (KeyCloak) using the guides at [Silo STS Quickstart Guide](https://silo.pgsty.com/developers/security-token-service/) and [KeyCloak Configuration Guide](https://github.com/pgsty/minio/blob/master/docs/sts/keycloak.md). Once this is done, STS credentials can be generated:
 
 ```
 go run client-grants.go -cid PoEgXP6uVO45IsENRngDXj5Au5Ya -csec eKsw6z8CtOJVBtrOWvhRWL4TUCga
@@ -64,9 +64,9 @@ go run client-grants.go -cid PoEgXP6uVO45IsENRngDXj5Au5Ya -csec eKsw6z8CtOJVBtrO
 }
 ```
 
-These credentials can now be used to perform MinIO API operations, these credentials automatically expire in 1hr. To understand more about credential expiry duration and client grants STS API read further [here](https://github.com/pgsty/minio/blob/master/docs/sts/client-grants.md).
+These credentials can now be used to perform Silo API operations, these credentials automatically expire in 1hr. To understand more about credential expiry duration and client grants STS API read further [here](https://github.com/pgsty/minio/blob/master/docs/sts/client-grants.md).
 
 ## Explore Further
 
-- [MinIO STS Quickstart Guide](https://silo.pgsty.com/developers/security-token-service/)
+- [Silo STS Quickstart Guide](https://silo.pgsty.com/developers/security-token-service/)
-- [The MinIO documentation website](https://silo.pgsty.com/docs/)
+- [The Silo documentation website](https://silo.pgsty.com/docs/)

docs/sts/keycloak.md

@@ -1,6 +1,6 @@
-# Keycloak Quickstart Guide [![Slack](https://slack.min.io/slack?type=svg)](https://slack.min.io)
+# Keycloak Quickstart Guide
 
-Keycloak is an open source Identity and Access Management solution aimed at modern applications and services, this document covers configuring Keycloak identity provider support with MinIO.
+Keycloak is an open source Identity and Access Management solution aimed at modern applications and services, this document covers configuring Keycloak identity provider support with Silo.
 
 ## Prerequisites
 
@@ -16,11 +16,11 @@ For a quick installation, docker-compose reference configs are also available on
     - Save
   - Click on credentials tab
     - Copy the `Secret` to clipboard.
-    - This value is needed for `MINIO_IDENTITY_OPENID_CLIENT_SECRET` for MinIO.
+    - This value is needed for `MINIO_IDENTITY_OPENID_CLIENT_SECRET` for Silo.
 
 - Go to Users
   - Click on the user
-  - Attribute, add a new attribute `Key` is `policy`, `Value` is name of the `policy` on MinIO (ex: `readwrite`)
+  - Attribute, add a new attribute `Key` is `policy`, `Value` is name of the `policy` on Silo (ex: `readwrite`)
   - Add and Save
 
 - Go to Clients
@@ -78,18 +78,18 @@ curl \
   "http://localhost:8080/auth/admin/realms/{realm}/users/{userid}"
 ```
 
-### Configure MinIO
+### Configure Silo
 
 ```
 export MINIO_ROOT_USER=minio
-export MINIO_ROOT_PASSWORD=minio123
+export MINIO_ROOT_PASSWORD=silo123
-minio server /mnt/export
+silo server /mnt/export
 ```
 
 Here are all the available options to configure OpenID connect
 
 ```
-mc admin config set myminio/ identity_openid
+mc admin config set mysilo/ identity_openid
 
 KEY:
 identity_openid  enable OpenID SSO support
@@ -106,7 +106,7 @@ comment       (sentence)  optionally add a comment to this setting
 and ENV based options
 
 ```
-mc admin config set myminio/ identity_openid --env
+mc admin config set mysilo/ identity_openid --env
 
 KEY:
 identity_openid  enable OpenID SSO support
@@ -120,18 +120,18 @@ MINIO_IDENTITY_OPENID_SCOPES        (csv)       Comma separated list of OpenID s
 MINIO_IDENTITY_OPENID_COMMENT       (sentence)  optionally add a comment to this setting
 ```
 
-Set `identity_openid` config with `config_url`, `client_id` and restart MinIO
+Set `identity_openid` config with `config_url`, `client_id` and restart Silo
 
 ```
-~ mc admin config set myminio identity_openid config_url="http://localhost:8080/auth/realms/{your-realm-name}/.well-known/openid-configuration" client_id="account"
+~ mc admin config set mysilo identity_openid config_url="http://localhost:8080/auth/realms/{your-realm-name}/.well-known/openid-configuration" client_id="account"
 ```
 
 > NOTE: You can configure the `scopes` parameter to restrict the OpenID scopes requested by minio to the IdP, for example, `"openid,policy_role_attribute"`, being `policy_role_attribute` a client_scope / client_mapper that maps a role attribute called policy to a `policy` claim returned by Keycloak
 
-Once successfully set restart the MinIO instance.
+Once successfully set restart the Silo instance.
 
 ```
-mc admin service restart myminio
+mc admin service restart mysilo
 ```
 
 ### Using WebIdentiy API
@@ -161,16 +161,16 @@ This will open the login page of keycloak, upon successful login, STS credential
 
 > NOTE: You can use the `-cscopes` parameter to restrict the requested scopes, for example to `"openid,policy_role_attribute"`, being `policy_role_attribute` a client_scope / client_mapper that maps a role attribute called policy to a `policy` claim returned by Keycloak.
 
-These credentials can now be used to perform MinIO API operations.
+These credentials can now be used to perform Silo API operations.
 
-### Using MinIO Console
+### Using Silo Console
 
-- Open MinIO URL on the browser, lets say <http://localhost:9000/>
+- Open Silo URL on the browser, lets say <http://localhost:9000/>
 - Click on `Login with SSO`
-- User will be redirected to the Keycloak user login page, upon successful login the user will be redirected to MinIO page and logged in automatically,
+- User will be redirected to the Keycloak user login page, upon successful login the user will be redirected to Silo page and logged in automatically,
   the user should see now the buckets and objects they have access to.
 
 ## Explore Further
 
-- [MinIO STS Quickstart Guide](https://silo.pgsty.com/developers/security-token-service/)
+- [Silo STS Quickstart Guide](https://silo.pgsty.com/developers/security-token-service/)
-- [The MinIO documentation website](https://silo.pgsty.com/docs/)
+- [The Silo documentation website](https://silo.pgsty.com/docs/)

docs/sts/ldap.go

@@ -35,7 +35,7 @@ import (
 )
 
 var (
-	// LDAP integrated Minio endpoint
+	// LDAP-integrated Silo endpoint
 	stsEndpoint string
 
 	// LDAP credentials
@@ -121,13 +121,13 @@ func main() {
 		return
 	}
 
-	// Use generated credentials to authenticate with MinIO server
+	// Use generated credentials to authenticate with Silo server
 	minioClient, err := minio.New(stsEndpointURL.Host, opts)
 	if err != nil {
 		log.Fatalf("Error initializing client: %v", err)
 	}
 
-	// Use minIO Client object normally like the regular client.
+	// Use the minio-go Client object like a regular client.
 	if bucketToList == "" {
 		bucketToList = ldapUsername
 	}

docs/sts/ldap.md

@@ -1,35 +1,35 @@
-# AssumeRoleWithLDAPIdentity [![Slack](https://slack.min.io/slack?type=svg)](https://slack.min.io)
+# AssumeRoleWithLDAPIdentity
 
 ## Introduction
 
-MinIO provides a custom STS API that allows integration with LDAP based corporate environments including Microsoft Active Directory. The MinIO server uses a separate LDAP service account to lookup user information. The login flow for a user is as follows:
+Silo provides a custom STS API that allows integration with LDAP based corporate environments including Microsoft Active Directory. The Silo server uses a separate LDAP service account to lookup user information. The login flow for a user is as follows:
 
 - User provides their AD/LDAP username and password to the STS API.
-- MinIO looks up the user's information (specifically the user's Distinguished Name) in the LDAP server.
+- Silo looks up the user's information (specifically the user's Distinguished Name) in the LDAP server.
-- On finding the user's info, MinIO verifies the login credentials with the AD/LDAP server.
+- On finding the user's info, Silo verifies the login credentials with the AD/LDAP server.
-- MinIO optionally queries the AD/LDAP server for a list of groups that the user is a member of.
+- Silo optionally queries the AD/LDAP server for a list of groups that the user is a member of.
-- MinIO then checks if there are any policies [explicitly associated](#managing-usergroup-access-policy) with the user or their groups.
+- Silo then checks if there are any policies [explicitly associated](#managing-usergroup-access-policy) with the user or their groups.
-- On finding at least one associated policy, MinIO generates temporary credentials for the user storing the list of groups in a cryptographically secure session token. The temporary access key, secret key and session token are returned to the user.
+- On finding at least one associated policy, Silo generates temporary credentials for the user storing the list of groups in a cryptographically secure session token. The temporary access key, secret key and session token are returned to the user.
-- The user can now use these credentials to make requests to the MinIO server.
+- The user can now use these credentials to make requests to the Silo server.
 
-The administrator will associate IAM access policies with each group and if required with the user too. The MinIO server then evaluates applicable policies on a user (these are the policies associated with the groups along with the policy on the user if any) to check if the request should be allowed or denied.
+The administrator will associate IAM access policies with each group and if required with the user too. The Silo server then evaluates applicable policies on a user (these are the policies associated with the groups along with the policy on the user if any) to check if the request should be allowed or denied.
 
-To ensure that changes in the LDAP directory are reflected in object storage access changes, MinIO performs an **Automatic LDAP sync**. MinIO periodically queries the LDAP service to:
+To ensure that changes in the LDAP directory are reflected in object storage access changes, Silo performs an **Automatic LDAP sync**. Silo periodically queries the LDAP service to:
 
-- find accounts (user DNs) that have been removed; any active STS credentials or MinIO service accounts belonging to these users are purged.
+- find accounts (user DNs) that have been removed; any active STS credentials or Silo service accounts belonging to these users are purged.
 
 - find accounts whose group memberships have changed; access policies available to a credential are updated to reflect the change, i.e. they will lose any privileges associated with a group they are removed from, and gain any privileges associated with a group they are added to.
 
-**Please note that when AD/LDAP is configured, MinIO will not support long term users defined internally.** Only AD/LDAP users (and the root user) are allowed. In addition to this, the server will not support operations on users or groups using `mc admin user` or `mc admin group` commands except `mc admin user info` and `mc admin group info` to list set policies for users and groups. This is because users and groups are defined externally in AD/LDAP.
+**Please note that when AD/LDAP is configured, Silo will not support long term users defined internally.** Only AD/LDAP users (and the root user) are allowed. In addition to this, the server will not support operations on users or groups using `mc admin user` or `mc admin group` commands except `mc admin user info` and `mc admin group info` to list set policies for users and groups. This is because users and groups are defined externally in AD/LDAP.
 
-## Configuring AD/LDAP on MinIO
+## Configuring AD/LDAP on Silo
 
-LDAP STS configuration can be performed via MinIO's standard configuration API (i.e. using `mc admin config set/get` commands) or equivalently via environment variables. For brevity we refer to environment variables here.
+LDAP STS configuration can be performed via Silo's standard configuration API (i.e. using `mc admin config set/get` commands) or equivalently via environment variables. For brevity we refer to environment variables here.
 
 LDAP is configured via the following environment variables:
 
 ```
-$ mc admin config set myminio identity_ldap --env
+$ mc admin config set mysilo identity_ldap --env
 KEY:
 identity_ldap  enable LDAP SSO support
 
@@ -64,21 +64,21 @@ MINIO_IDENTITY_LDAP_SERVER_STARTTLS         (on|off)    use StartTLS connection
 
 The server address variable is _required_. TLS is assumed to be on by default. The port in the server address is optional and defaults to 636 if not provided.
 
-**MinIO sends LDAP credentials to the LDAP server for validation. So we _strongly recommend_ to use MinIO with AD/LDAP server over TLS or StartTLS _only_. Using plain-text connection between MinIO and LDAP server means _credentials can be compromised_ by anyone listening to network traffic.**
+**Silo sends LDAP credentials to the LDAP server for validation. So we _strongly recommend_ to use Silo with AD/LDAP server over TLS or StartTLS _only_. Using plain-text connection between Silo and LDAP server means _credentials can be compromised_ by anyone listening to network traffic.**
 
-If a self-signed certificate is being used, the certificate can be added to MinIO's certificates directory, so it can be trusted by the server.
+If a self-signed certificate is being used, the certificate can be added to Silo's certificates directory, so it can be trusted by the server.
 
 #### DNS SRV Records
 
 Many Active Directory and other LDAP services are setup with [DNS SRV Records](https://ldap.com/dns-srv-records-for-ldap/) for high-availability of the directory service. To use this to find LDAP servers to connect to, an LDAP client makes a DNS SRV record request to the DNS service on a domain that looks like `_service._proto.example.com`. For LDAP the `proto` value is always `tcp`, and `service` is usually `ldap` or `ldaps`.
 
-To enable MinIO to use the SRV records, specify the `srv_record_name` config parameter (or equivalently the `MINIO_IDENTITY_LDAP_SRV_RECORD_NAME` environment variable). This parameter can be set to `ldap` or `ldaps` and MinIO will substitute it into the `service` value. For example, when `server_addr=myldapserver.com` and `srv_record_name=ldap`, MinIO will lookup the SRV record for `_ldap._tcp.myldapserver.com` and pick an appropriate target for LDAP requests.
+To enable Silo to use the SRV records, specify the `srv_record_name` config parameter (or equivalently the `MINIO_IDENTITY_LDAP_SRV_RECORD_NAME` environment variable). This parameter can be set to `ldap` or `ldaps` and Silo will substitute it into the `service` value. For example, when `server_addr=myldapserver.com` and `srv_record_name=ldap`, Silo will lookup the SRV record for `_ldap._tcp.myldapserver.com` and pick an appropriate target for LDAP requests.
 
 If the DNS SRV record is at an entirely different place, say `_ldapsrv._tcpish.myldapserver.com`, then set `srv_record_name` to the special value `on` and set `server_addr=_ldapsrv._tcpish.myldapserver.com`.
 
 When using this feature, do not specify a port in the `server_addr` as the port is picked up automatically from the SRV record.
 
-With the default (empty) value for `srv_record_name`, MinIO **will not** perform any SRV record request.
+With the default (empty) value for `srv_record_name`, Silo **will not** perform any SRV record request.
 
 The value of `srv_record_name` does not affect any TLS settings - they must be configured with their own parameters.
 
@@ -86,7 +86,7 @@ The value of `srv_record_name` does not affect any TLS settings - they must be c
 
 LDAP STS rate limiting is enforced before each LDAP bind. Requests are tracked by source IP. A login attempt is throttled when that bucket is exhausted. Rate limiting is deliberately not keyed by username: a username-keyed bucket is shared across all sources, so an attacker could drain a known account's bucket with bad-password attempts and lock the legitimate user out. The per-source bucket caps the attempt rate from any single source, while the uniform auth-failure response is what conceals whether a username exists. This combination does not stop attackers who spread requests across many source IPs (botnets, IPv6 address rotation) or the residual bind-timing side channel; those are accepted limitations of an in-memory, per-source control.
 
-By default, the source IP used for this key is the socket peer address. This is the safe default because MinIO does **not** trust `X-Forwarded-For`, `X-Real-IP`, or `Forwarded` headers for this security-sensitive rate-limit key unless you opt in explicitly.
+By default, the source IP used for this key is the socket peer address. This is the safe default because Silo does **not** trust `X-Forwarded-For`, `X-Real-IP`, or `Forwarded` headers for this security-sensitive rate-limit key unless you opt in explicitly.
 
 Each login attempt reserves capacity for the duration of the LDAP bind. Successful logins and LDAP infrastructure failures refund that reservation. Only real authentication failures permanently consume tokens. Concurrent bursts above the burst capacity can still receive `429` responses even if those in-flight requests later succeed.
 
@@ -101,11 +101,11 @@ Each login attempt reserves capacity for the duration of the LDAP bind. Successf
 | Scope | Per-node, in-memory, not cluster-wide |
 | Configurability | Not currently configurable |
 
-In a multi-node deployment behind a load balancer, each MinIO node tracks its own buckets. The effective aggregate budget therefore depends on how requests are distributed across nodes.
+In a multi-node deployment behind a load balancer, each Silo node tracks its own buckets. The effective aggregate budget therefore depends on how requests are distributed across nodes.
 
 #### Trusted proxies
 
-If MinIO is deployed behind a trusted reverse proxy, load balancer, or API gateway and you want LDAP STS throttling to bucket by the forwarded client IP instead of the proxy peer address, configure:
+If Silo is deployed behind a trusted reverse proxy, load balancer, or API gateway and you want LDAP STS throttling to bucket by the forwarded client IP instead of the proxy peer address, configure:
 
 ```
 MINIO_IDENTITY_LDAP_STS_TRUSTED_PROXIES     (list)      comma/semicolon/whitespace-separated list of trusted proxy IPs or CIDRs
@@ -123,7 +123,7 @@ This allowlist governs LDAP STS rate-limit bucketing only. The client address us
 
 ### Lookup-Bind
 
-A low-privilege read-only LDAP service account is configured in the MinIO server by providing the account's Distinguished Name (DN) and password. This service account is used to perform directory lookups as needed.
+A low-privilege read-only LDAP service account is configured in the Silo server by providing the account's Distinguished Name (DN) and password. This service account is used to perform directory lookups as needed.
 
 ```
 MINIO_IDENTITY_LDAP_LOOKUP_BIND_DN*          (string)    DN for LDAP read-only service account used to perform DN and group lookups
@@ -134,7 +134,7 @@ If you set an empty lookup bind password, the lookup bind will use the unauthent
 
 ### User lookup
 
-When a user provides their LDAP credentials, MinIO runs a lookup query to find the user's Distinguished Name (DN). The search filter and base DN used in this lookup query are configured via the following variables:
+When a user provides their LDAP credentials, Silo runs a lookup query to find the user's Distinguished Name (DN). The search filter and base DN used in this lookup query are configured via the following variables:
 
 ```
 MINIO_IDENTITY_LDAP_USER_DN_SEARCH_BASE_DN*  (list)      ";" separated list of user search base DNs e.g. "dc=myldapserver,dc=com"
@@ -153,7 +153,7 @@ is optional and can be used to specify additional attributes to lookup on the Us
 
 ### Group membership search
 
-MinIO can be optionally configured to find the groups of a user from AD/LDAP by specifying the following variables:
+Silo can be optionally configured to find the groups of a user from AD/LDAP by specifying the following variables:
 
 ```
 MINIO_IDENTITY_LDAP_GROUP_SEARCH_FILTER     (string)    search filter for groups e.g. "(&(objectclass=groupOfNames)(memberUid=%s))"
@@ -196,30 +196,30 @@ In the configuration variables, `%s` is substituted with the _username_ from the
 
 ## Managing User/Group Access Policy
 
-Access policies may be associated by their name with a group or user directly. Access policies are first defined on the MinIO server using IAM policy JSON syntax. To define a new policy, you can use the [AWS policy generator](https://awspolicygen.s3.amazonaws.com/policygen.html). Copy the policy into a text file `mypolicy.json` and issue the command like so:
+Access policies may be associated by their name with a group or user directly. Access policies are first defined on the Silo server using IAM policy JSON syntax. To define a new policy, you can use the [AWS policy generator](https://awspolicygen.s3.amazonaws.com/policygen.html). Copy the policy into a text file `mypolicy.json` and issue the command like so:
 
 ```sh
-mc admin policy create myminio mypolicy mypolicy.json
+mc admin policy create mysilo mypolicy mypolicy.json
 ```
 
 To associate the policy with an LDAP user or group, use the full DN of the user or group:
 
 ```sh
-mc idp ldap policy attach myminio mypolicy --user='uid=james,cn=accounts,dc=myldapserver,dc=com'
+mc idp ldap policy attach mysilo mypolicy --user='uid=james,cn=accounts,dc=myldapserver,dc=com'
 ```
 
 ```sh
-mc idp ldap policy attach myminio mypolicy ----group='cn=projectx,ou=groups,ou=hwengg,dc=min,dc=io'
+mc idp ldap policy attach mysilo mypolicy ----group='cn=projectx,ou=groups,ou=hwengg,dc=min,dc=io'
 ```
 
 To remove a policy association, use the similar `detach` command:
 
 ```sh
-mc idp ldap policy detach myminio mypolicy --user='uid=james,cn=accounts,dc=myldapserver,dc=com'
+mc idp ldap policy detach mysilo mypolicy --user='uid=james,cn=accounts,dc=myldapserver,dc=com'
 ```
 
 ```sh
-mc idp ldap policy detach myminio mypolicy ----group='cn=projectx,ou=groups,ou=hwengg,dc=min,dc=io'
+mc idp ldap policy detach mysilo mypolicy ----group='cn=projectx,ou=groups,ou=hwengg,dc=min,dc=io'
 ```
 
 
@@ -230,12 +230,12 @@ Note that the commands above attempt to validate if the given entity (user or gr
 Please **do not use** these as they may be removed or their behavior may change.
 
 ```sh
-mc admin policy attach myminio mypolicy --user='uid=james,cn=accounts,dc=myldapserver,dc=com'
+mc admin policy attach mysilo mypolicy --user='uid=james,cn=accounts,dc=myldapserver,dc=com'
 ```
 
 
 ```sh
-mc admin policy attach myminio mypolicy --group='cn=projectx,ou=groups,ou=hwengg,dc=min,dc=io'
+mc admin policy attach mysilo mypolicy --group='cn=projectx,ou=groups,ou=hwengg,dc=min,dc=io'
 ```
 
 </details>
@@ -312,7 +312,7 @@ Authentication failures caused by unknown users and invalid passwords intentiona
 ## Sample `POST` Request
 
 ```
-http://minio.cluster:9000?Action=AssumeRoleWithLDAPIdentity&LDAPUsername=foouser&LDAPPassword=foouserpassword&Version=2011-06-15&DurationSeconds=7200
+http://silo.cluster:9000?Action=AssumeRoleWithLDAPIdentity&LDAPUsername=foouser&LDAPPassword=foouserpassword&Version=2011-06-15&DurationSeconds=7200
 ```
 
 ## Sample Response
@@ -342,13 +342,13 @@ With multiple OU hierarchies for users, and multiple group search base DN's.
 
 ```
 export MINIO_ROOT_USER=minio
-export MINIO_ROOT_PASSWORD=minio123
+export MINIO_ROOT_PASSWORD=silo123
 export MINIO_IDENTITY_LDAP_SERVER_ADDR='my.ldap-active-dir-server.com:636'
 export MINIO_IDENTITY_LDAP_LOOKUP_BIND_DN='cn=admin,dc=min,dc=io'
 export MINIO_IDENTITY_LDAP_LOOKUP_BIND_PASSWORD=admin
 export MINIO_IDENTITY_LDAP_GROUP_SEARCH_BASE_DN='dc=minioad,dc=local;dc=somedomain,dc=com'
 export MINIO_IDENTITY_LDAP_GROUP_SEARCH_FILTER='(&(objectclass=groupOfNames)(member=%d))'
-minio server ~/test
+silo server ~/test
 ```
 
 You can make sure it works appropriately using our [example program](https://raw.githubusercontent.com/pgsty/minio/master/docs/sts/ldap.go):
@@ -367,5 +367,5 @@ $ go run ldap.go -u foouser -p foopassword
 
 ## Explore Further
 
-- [MinIO Admin Complete Guide](https://silo.pgsty.com/reference/minio-mc-admin/)
+- [Silo Admin Complete Guide](https://silo.pgsty.com/reference/minio-mc-admin/)
-- [The MinIO documentation website](https://silo.pgsty.com/docs/)
+- [The Silo documentation website](https://silo.pgsty.com/docs/)

docs/sts/tls.md

@@ -1,15 +1,15 @@
-# AssumeRoleWithCertificate [![Slack](https://slack.min.io/slack?type=svg)](https://slack.min.io)
+# AssumeRoleWithCertificate
 
 ## Introduction
 
-MinIO provides a custom STS API that allows authentication with client X.509 / TLS certificates.
+Silo provides a custom STS API that allows authentication with client X.509 / TLS certificates.
 
 A major advantage of certificate-based authentication compared to other STS authentication methods, like OpenID Connect or LDAP/AD, is that client authentication works without any additional/external component that must be constantly available. Therefore, certificate-based authentication may provide better availability / lower operational complexity.
 
-The MinIO TLS STS API can be configured via MinIO's standard configuration API (i.e. using `mc admin config set/get`). Further, it can be configured via the following environment variables:
+The Silo TLS STS API can be configured via Silo's standard configuration API (i.e. using `mc admin config set/get`). Further, it can be configured via the following environment variables:
 
 ```
-mc admin config set myminio identity_tls --env
+mc admin config set mysilo identity_tls --env
 KEY:
 identity_tls  enable X.509 TLS certificate SSO support
 
@@ -17,7 +17,7 @@ ARGS:
 MINIO_IDENTITY_TLS_SKIP_VERIFY  (on|off)    trust client certificates without verification. Defaults to "off" (verify)
 ```
 
-The MinIO TLS STS API is disabled by default. However, it can be *enabled* by setting environment variable:
+The Silo TLS STS API is disabled by default. However, it can be *enabled* by setting environment variable:
 
 ```
 export MINIO_IDENTITY_TLS_ENABLE=on
@@ -25,10 +25,10 @@ export MINIO_IDENTITY_TLS_ENABLE=on
 
 ## Example
 
-MinIO exposes a custom S3 STS API endpoint as `Action=AssumeRoleWithCertificate`. A client has to send an HTTP `POST` request to `https://<host>:<port>?Action=AssumeRoleWithCertificate&Version=2011-06-15`. Since the authentication and authorization happens via X.509 certificates the client has to send the request over **TLS** and has to provide
+Silo exposes a custom S3 STS API endpoint as `Action=AssumeRoleWithCertificate`. A client has to send an HTTP `POST` request to `https://<host>:<port>?Action=AssumeRoleWithCertificate&Version=2011-06-15`. Since the authentication and authorization happens via X.509 certificates the client has to send the request over **TLS** and has to provide
 a client certificate.
 
-The following curl example shows how to authenticate to a MinIO server with client certificate and obtain STS access credentials.
+The following curl example shows how to authenticate to a Silo server with client certificate and obtain STS access credentials.
 
 ```curl
 curl -X POST --key private.key --cert public.crt "https://minio:9000?Action=AssumeRoleWithCertificate&Version=2011-06-15&DurationSeconds=3600"
@@ -53,11 +53,11 @@ curl -X POST --key private.key --cert public.crt "https://minio:9000?Action=Assu
 
 ## Authentication Flow
 
-A client can request temp. S3 credentials via the STS API. It can authenticate via a client certificate and obtain a access/secret key pair as well as a session token. These credentials are associated to an S3 policy at the MinIO server.
+A client can request temp. S3 credentials via the STS API. It can authenticate via a client certificate and obtain a access/secret key pair as well as a session token. These credentials are associated to an S3 policy at the Silo server.
 
-In case of certificate-based authentication, MinIO has to map the client-provided certificate to an S3 policy. MinIO does this via the subject common name field of the X.509 certificate. So, MinIO will associate a certificate with a subject `CN = foobar` to a S3 policy named `foobar`.
+In case of certificate-based authentication, Silo has to map the client-provided certificate to an S3 policy. Silo does this via the subject common name field of the X.509 certificate. So, Silo will associate a certificate with a subject `CN = foobar` to a S3 policy named `foobar`.
 
-The following self-signed certificate is issued for `consoleAdmin`. So, MinIO would associate it with the pre-defined `consoleAdmin` policy.
+The following self-signed certificate is issued for `consoleAdmin`. So, Silo would associate it with the pre-defined `consoleAdmin` policy.
 
 ```
 Certificate:
@@ -94,18 +94,18 @@ Certificate:
 
 > Observe the `Subject: CN = consoleAdmin` field.
 
-Also, note that the certificate has to contain the `Extended Key Usage: TLS Web Client Authentication`. Otherwise, MinIO would not accept the certificate as client certificate.
+Also, note that the certificate has to contain the `Extended Key Usage: TLS Web Client Authentication`. Otherwise, Silo would not accept the certificate as client certificate.
 
 Now, the STS certificate-based authentication happens in 4 steps:
 
-- Client sends HTTP `POST` request over a TLS connection hitting the MinIO TLS STS API.
+- Client sends HTTP `POST` request over a TLS connection hitting the Silo TLS STS API.
-- MinIO verifies that the client certificate is valid.
+- Silo verifies that the client certificate is valid.
-- MinIO tries to find a policy that matches the `CN` of the client certificate.
+- Silo tries to find a policy that matches the `CN` of the client certificate.
-- MinIO returns temp. S3 credentials associated to the found policy.
+- Silo returns temp. S3 credentials associated to the found policy.
 
 The returned credentials expiry after a certain period of time that can be configured via `&DurationSeconds=3600`. By default, the STS credentials are valid for 1 hour. The minimum expiration allowed is 15 minutes.
 
-Further, the temp. S3 credentials will never out-live the client certificate. For example, if the `MINIO_IDENTITY_TLS_STS_EXPIRY` is 7 days but the certificate itself is only valid for the next 3 days, then MinIO will return S3 credentials that are valid for 3 days only.
+Further, the temp. S3 credentials will never out-live the client certificate. For example, if the `MINIO_IDENTITY_TLS_STS_EXPIRY` is 7 days but the certificate itself is only valid for the next 3 days, then Silo will return S3 credentials that are valid for 3 days only.
 
 ## Caveat
 
@@ -113,5 +113,5 @@ Further, the temp. S3 credentials will never out-live the client certificate. Fo
 
 ## Explore Further
 
-- [MinIO Admin Complete Guide](https://silo.pgsty.com/reference/minio-mc-admin/)
+- [Silo Admin Complete Guide](https://silo.pgsty.com/reference/minio-mc-admin/)
-- [The MinIO documentation website](https://silo.pgsty.com/docs/)
+- [The Silo documentation website](https://silo.pgsty.com/docs/)

docs/sts/web-identity.go

@@ -239,7 +239,7 @@ func main() {
 
 		clnt, err := minio.New(u.Host, opts)
 		if err != nil {
-			log.Println(fmt.Errorf("Error while initializing Minio client, %s", err))
+			log.Println(fmt.Errorf("error while initializing minio-go client: %s", err))
 			http.Error(w, err.Error(), http.StatusBadRequest)
 			return
 		}

docs/sts/web-identity.md

@@ -1,21 +1,21 @@
-# AssumeRoleWithWebIdentity [![Slack](https://slack.min.io/slack?type=svg)](https://slack.min.io)
+# AssumeRoleWithWebIdentity
 
 ## Introduction
 
-MinIO supports the standard AssumeRoleWithWebIdentity STS API to enable integration with OIDC/OpenID based identity provider environments. This allows the generation of temporary credentials with pre-defined access policies for applications/users to interact with MinIO object storage.
+Silo supports the standard AssumeRoleWithWebIdentity STS API to enable integration with OIDC/OpenID based identity provider environments. This allows the generation of temporary credentials with pre-defined access policies for applications/users to interact with Silo object storage.
 
-Calling AssumeRoleWithWebIdentity does not require the use of MinIO root or IAM credentials. Therefore, you can distribute an application (for example, on mobile devices) that requests temporary security credentials without including MinIO long lasting credentials in the application. Instead, the identity of the caller is validated by using a JWT id_token from the web identity provider. The temporary security credentials returned by this API consists of an access key, a secret key, and a security token. Applications can use these temporary security credentials to sign calls to MinIO API operations.
+Calling AssumeRoleWithWebIdentity does not require the use of Silo root or IAM credentials. Therefore, you can distribute an application (for example, on mobile devices) that requests temporary security credentials without including Silo long lasting credentials in the application. Instead, the identity of the caller is validated by using a JWT id_token from the web identity provider. The temporary security credentials returned by this API consists of an access key, a secret key, and a security token. Applications can use these temporary security credentials to sign calls to Silo API operations.
 
-**Breaking change (`CVE-2026-33322`)**: releases after `RELEASE.2026-03-25T00-00-00Z` validate the `id_token` with the provider JWKS endpoint advertised by the OpenID discovery document at `MINIO_IDENTITY_OPENID_CONFIG_URL`. In practice, MinIO currently accepts the RSA PKCS#1 v1.5 and ECDSA families already implemented in the verifier (`RS256`, `RS384`, `RS512`, `ES256`, `ES384`, `ES512`, plus the existing `RS3*` and `ES3*` aliases). HMAC-signed tokens such as `HS256`, `HS384`, and `HS512` are rejected. Algorithms such as `PS256` and `EdDSA` are not currently supported. `MINIO_IDENTITY_OPENID_CLIENT_SECRET` is used for OpenID/OAuth client interactions only and is not used as a JWT verification key. If your provider previously issued HMAC-signed `id_token`s, reconfigure it to publish RSA or ECDSA signing keys through JWKS before upgrading.
+**Breaking change (`CVE-2026-33322`)**: releases after `RELEASE.2026-03-25T00-00-00Z` validate the `id_token` with the provider JWKS endpoint advertised by the OpenID discovery document at `MINIO_IDENTITY_OPENID_CONFIG_URL`. In practice, Silo currently accepts the RSA PKCS#1 v1.5 and ECDSA families already implemented in the verifier (`RS256`, `RS384`, `RS512`, `ES256`, `ES384`, `ES512`, plus the existing `RS3*` and `ES3*` aliases). HMAC-signed tokens such as `HS256`, `HS384`, and `HS512` are rejected. Algorithms such as `PS256` and `EdDSA` are not currently supported. `MINIO_IDENTITY_OPENID_CLIENT_SECRET` is used for OpenID/OAuth client interactions only and is not used as a JWT verification key. If your provider previously issued HMAC-signed `id_token`s, reconfigure it to publish RSA or ECDSA signing keys through JWKS before upgrading.
 
 By default, the temporary security credentials created by AssumeRoleWithWebIdentity last for one hour. However, the optional DurationSeconds parameter can be used to specify the validity duration of the generated credentials. This value varies from 900 seconds (15 minutes) up to the maximum session duration of 365 days.
 
-## Configuring OpenID Identity Provider on MinIO
+## Configuring OpenID Identity Provider on Silo
 
-Configuration can be performed via MinIO's standard configuration API (i.e. using `mc admin config set/get` commands) or equivalently via environment variables. For brevity we show only environment variables here:
+Configuration can be performed via Silo's standard configuration API (i.e. using `mc admin config set/get` commands) or equivalently via environment variables. For brevity we show only environment variables here:
 
 ```
-$ mc admin config set myminio identity_openid --env
+$ mc admin config set mysilo identity_openid --env
 KEY:
 identity_openid[:name]  enable OpenID SSO support
 
@@ -28,7 +28,7 @@ MINIO_IDENTITY_OPENID_CLIENT_SECRET*        (string)    secret for the unique pu
 MINIO_IDENTITY_OPENID_ROLE_POLICY           (string)    Set the IAM access policies applicable to this client application and IDP e.g. "app-bucket-write,app-bucket-list"
 MINIO_IDENTITY_OPENID_CLAIM_NAME            (string)    JWT canned policy claim name (default: 'policy')
 MINIO_IDENTITY_OPENID_SCOPES                (csv)       Comma separated list of OpenID scopes for server, defaults to advertised scopes from discovery document e.g. "email,admin"
-MINIO_IDENTITY_OPENID_VENDOR                (string)    Specify vendor type for vendor specific behavior to checking validity of temporary credentials and service accounts on MinIO
+MINIO_IDENTITY_OPENID_VENDOR                (string)    Specify vendor type for vendor specific behavior to checking validity of temporary credentials and service accounts on Silo
 MINIO_IDENTITY_OPENID_CLAIM_USERINFO        (on|off)    Enable fetching claims from UserInfo Endpoint for authenticated user
 MINIO_IDENTITY_OPENID_KEYCLOAK_REALM        (string)    Specify Keycloak 'realm' name, only honored if vendor was set to 'keycloak' as value, if no realm is specified 'master' is default
 MINIO_IDENTITY_OPENID_KEYCLOAK_ADMIN_URL    (string)    Specify Keycloak 'admin' REST API endpoint e.g. http://localhost:8080/auth/admin/
@@ -40,7 +40,7 @@ MINIO_IDENTITY_OPENID_COMMENT               (sentence)  optionally add a comment
 
 Either `MINIO_IDENTITY_OPENID_ROLE_POLICY` (recommended) or `MINIO_IDENTITY_OPENID_CLAIM_NAME` must be specified but not both. See the section Access Control Policies to understand the differences between the two.
 
-**NOTE**: When configuring multiple OpenID based authentication providers on a MinIO cluster, any number of Role Policy based providers may be configured, and at most one JWT Claim based provider may be configured.
+**NOTE**: When configuring multiple OpenID based authentication providers on a Silo cluster, any number of Role Policy based providers may be configured, and at most one JWT Claim based provider may be configured.
 
 <details><summary>Example 1: Two role policy providers</summary>
 
@@ -83,23 +83,23 @@ MINIO_IDENTITY_OPENID_CLAIM_NAME="groups"
 
 ### Redirection from OpenID Provider
 
-To login to MinIO, the user first loads the MinIO console on their browser, and selects the OpenID Provider they wish to use (the `MINIO_IDENTITY_OPENID_DISPLAY_NAME` value is shown here). The user is then redirected to the OpenID provider's login page and performs necessary login actions (e.g. entering credentials, responding to MFA authentication challenges, etc). After successful login, the user is redirected back to the MinIO console. This redirect URL is specified as a parameter by MinIO when the user is redirected to the OpenID Provider in the beginning. For some setups, extra configuration may be required for this step to work correctly.
+To login to Silo, the user first loads the Silo console on their browser, and selects the OpenID Provider they wish to use (the `MINIO_IDENTITY_OPENID_DISPLAY_NAME` value is shown here). The user is then redirected to the OpenID provider's login page and performs necessary login actions (e.g. entering credentials, responding to MFA authentication challenges, etc). After successful login, the user is redirected back to the Silo console. This redirect URL is specified as a parameter by Silo when the user is redirected to the OpenID Provider in the beginning. For some setups, extra configuration may be required for this step to work correctly.
 
-For a simple setup where the user/client app accesses MinIO directly (i.e. with no intervening proxies/load-balancers), and each MinIO server (if there are more than one) has a unique domain name, this redirection should work automatically with no further configuration. For example, if the MinIO service is being accessed by the browser at the URL `https://minio-node-1.example.org`, the redirect URL will be `https://minio-node-1.example.org/oauth_callback` and all is well.
+For a simple setup where the user/client app accesses Silo directly (i.e. with no intervening proxies/load-balancers), and each Silo server (if there are more than one) has a unique domain name, this redirection should work automatically with no further configuration. For example, if the Silo service is being accessed by the browser at the URL `https://silo-node-1.example.org`, the redirect URL will be `https://silo-node-1.example.org/oauth_callback` and all is well.
 
-For deployments with a load-balancer (LB), it is required that the LB is configured to send requests from the same user/client-app to the same backend MinIO server (at least for the initial login request and subsequent redirection, as the OpenID auth flow's state parameter is currently local to the MinIO server). For this setup, set the `MINIO_BROWSER_REDIRECT_URL` parameter to the publicly/client-accessible endpoint for the MinIO Console. For example `MINIO_BROWSER_REDIRECT_URL=https://console.minio.example.org`. This will ensure that the redirect URL is set to `https://console.minio.example.org/oauth_callback` and the login process should work correctly.
+For deployments with a load-balancer (LB), it is required that the LB is configured to send requests from the same user/client-app to the same backend Silo server (at least for the initial login request and subsequent redirection, as the OpenID auth flow's state parameter is currently local to the Silo server). For this setup, set the `MINIO_BROWSER_REDIRECT_URL` parameter to the publicly/client-accessible endpoint for the Silo Console. For example `MINIO_BROWSER_REDIRECT_URL=https://console.silo.example.org`. This will ensure that the redirect URL is set to `https://console.silo.example.org/oauth_callback` and the login process should work correctly.
 
-For deployments employing DNS round-robin on a single domain to all the MinIO servers, it is possible that after redirection the browser may land on a different MinIO server. For example, the domain `console.minio.example.org` may resolve to `console-X.minio.example.org`, where `X` is `1`, `2`, `3` or `4`. For the login to work, if the user first landed on `console-1.minio.example.org`, they must be redirected back to the same place after logging in at the OpenID provider's web-page. To ensure this, set the `MINIO_IDENTITY_OPENID_REDIRECT_URI_DYNAMIC=on` parameter - this lets MinIO set the redirect URL based on the "Host" header of the (initial login) request.
+For deployments employing DNS round-robin on a single domain to all the Silo servers, it is possible that after redirection the browser may land on a different Silo server. For example, the domain `console.silo.example.org` may resolve to `console-X.silo.example.org`, where `X` is `1`, `2`, `3` or `4`. For the login to work, if the user first landed on `console-1.silo.example.org`, they must be redirected back to the same place after logging in at the OpenID provider's web-page. To ensure this, set the `MINIO_IDENTITY_OPENID_REDIRECT_URI_DYNAMIC=on` parameter - this lets Silo set the redirect URL based on the "Host" header of the (initial login) request.
 
 The **deprecated** parameter `MINIO_IDENTITY_OPENID_REDIRECT_URI` works similar to the `MINIO_BROWSER_REDIRECT_URL` but needs to include the `/oauth_callback` suffix. Please do not use it, as it is sufficient to the set the `MINIO_BROWSER_REDIRECT_URL` parameter (which is required anyway for most load-balancer based setups to work correctly). This deprecated parameter **will be removed** in a future release. 
 
 ## Specifying Access Control with IAM Policies
 
-The STS API authenticates the user by verifying the JWT provided in the request. However access to object storage resources are controlled via named IAM policies defined in the MinIO instance. Once authenticated via the STS API, the MinIO server applies one or more IAM policies to the generated credentials. MinIO's AssumeRoleWithWebIdentity implementation supports specifying IAM policies in two ways:
+The STS API authenticates the user by verifying the JWT provided in the request. However access to object storage resources are controlled via named IAM policies defined in the Silo instance. Once authenticated via the STS API, the Silo server applies one or more IAM policies to the generated credentials. Silo's AssumeRoleWithWebIdentity implementation supports specifying IAM policies in two ways:
 
-1. Role Policy (Recommended): When specified as part of the OpenID provider configuration, all users authenticating via this provider are authorized to (only) use the specified role policy. The policy to associate with such users is specified via the `role_policy` configuration parameter or the `MINIO_IDENTITY_OPENID_ROLE_POLICY` environment variable. The value is a comma-separated list of IAM access policy names already defined in the server. In this situation, the server prints a role ARN at startup that must be specified as a `RoleArn` API request parameter in the STS AssumeRoleWithWebIdentity API call. When using Role Policies, multiple OpenID providers and/or client applications (with unique client IDs) may be configured with independent role policies. Each configuration is assigned a unique RoleARN by the MinIO server and this is used to select the policies to apply to temporary credentials generated in the AssumeRoleWithWebIdentity call.
+1. Role Policy (Recommended): When specified as part of the OpenID provider configuration, all users authenticating via this provider are authorized to (only) use the specified role policy. The policy to associate with such users is specified via the `role_policy` configuration parameter or the `MINIO_IDENTITY_OPENID_ROLE_POLICY` environment variable. The value is a comma-separated list of IAM access policy names already defined in the server. In this situation, the server prints a role ARN at startup that must be specified as a `RoleArn` API request parameter in the STS AssumeRoleWithWebIdentity API call. When using Role Policies, multiple OpenID providers and/or client applications (with unique client IDs) may be configured with independent role policies. Each configuration is assigned a unique RoleARN by the Silo server and this is used to select the policies to apply to temporary credentials generated in the AssumeRoleWithWebIdentity call.
 
-2. `id_token` claims: When the role policy is not configured, MinIO looks for a specific claim in the `id_token` (JWT) returned by the OpenID provider in the STS request. The default claim is `policy` and can be overridden by the `claim_name` configuration parameter or the `MINIO_IDENTITY_OPENID_CLAIM_NAME` environment variable. The claim value can be a string (comma-separated list) or an array of IAM access policy names defined in the server. A `RoleArn` API request parameter *must not* be specified in the STS AssumeRoleWithWebIdentity API call.
+2. `id_token` claims: When the role policy is not configured, Silo looks for a specific claim in the `id_token` (JWT) returned by the OpenID provider in the STS request. The default claim is `policy` and can be overridden by the `claim_name` configuration parameter or the `MINIO_IDENTITY_OPENID_CLAIM_NAME` environment variable. The claim value can be a string (comma-separated list) or an array of IAM access policy names defined in the server. A `RoleArn` API request parameter *must not* be specified in the STS AssumeRoleWithWebIdentity API call.
 
 ## API Request Parameters
 
@@ -113,7 +113,7 @@ The OAuth 2.0 id_token that is provided by the web identity provider. Applicatio
 | *Length Constraints* | *Minimum length of 4. Maximum length of 2048.* |
 | *Required*           | *Yes*                                          |
 
-### WebIdentityAccessToken (MinIO Extension)
+### WebIdentityAccessToken (Silo Extension)
 
 There are situations when identity provider does not provide user claims in `id_token` instead it needs to be retrieved from UserInfo endpoint, this extension is only useful in this scenario. This is rare so use it accordingly depending on your Identity provider implementation. `access_token` is available as part of the OIDC authentication flow similar to `id_token`.
 
@@ -171,7 +171,7 @@ XML error response for this API is similar to [AWS STS AssumeRoleWithWebIdentity
 ## Sample `POST` Request
 
 ```
-http://minio.cluster:9000?Action=AssumeRoleWithWebIdentity&DurationSeconds=3600&WebIdentityToken=eyJ4NXQiOiJOVEF4Wm1NeE5ETXlaRGczTVRVMVpHTTBNekV6T0RKaFpXSTRORE5sWkRVMU9HRmtOakZpTVEiLCJraWQiOiJOVEF4Wm1NeE5ETXlaRGczTVRVMVpHTTBNekV6T0RKaFpXSTRORE5sWkRVMU9HRmtOakZpTVEiLCJhbGciOiJSUzI1NiJ9.eyJhdWQiOiJQb0VnWFA2dVZPNDVJc0VOUm5nRFhqNUF1NVlhIiwiYXpwIjoiUG9FZ1hQNnVWTzQ1SXNFTlJuZ0RYajVBdTVZYSIsImlzcyI6Imh0dHBzOlwvXC9sb2NhbGhvc3Q6OTQ0M1wvb2F1dGgyXC90b2tlbiIsImV4cCI6MTU0MTgwOTU4MiwiaWF0IjoxNTQxODA1OTgyLCJqdGkiOiI2Y2YyMGIwZS1lNGZmLTQzZmQtYTdiYS1kYTc3YTE3YzM2MzYifQ.Jm29jPliRvrK6Os34nSK3rhzIYLFjE__zdVGNng3uGKXGKzP3We_i6NPnhA0szJXMOKglXzUF1UgSz8MctbaxFS8XDusQPVe4LkB_45hwBm6TmBxzui911nt-1RbBLN_jZIlvl2lPrbTUH5hSn9kEkph6seWanTNQpz9tNEoVa6R_OX3kpJqxe8tLQUWw453A1JTwFNhdHa6-f1K8_Q_eEZ_4gOYINQ9t_fhTibdbkXZkJQFLop-Jwoybi9s4nwQU_dATocgcufq5eCeNItQeleT-23lGxIz0X7CiJrJynYLdd-ER0F77SumqEb5iCxhxuf4H7dovwd1kAmyKzLxpw&Version=2011-06-15
+http://silo.cluster:9000?Action=AssumeRoleWithWebIdentity&DurationSeconds=3600&WebIdentityToken=eyJ4NXQiOiJOVEF4Wm1NeE5ETXlaRGczTVRVMVpHTTBNekV6T0RKaFpXSTRORE5sWkRVMU9HRmtOakZpTVEiLCJraWQiOiJOVEF4Wm1NeE5ETXlaRGczTVRVMVpHTTBNekV6T0RKaFpXSTRORE5sWkRVMU9HRmtOakZpTVEiLCJhbGciOiJSUzI1NiJ9.eyJhdWQiOiJQb0VnWFA2dVZPNDVJc0VOUm5nRFhqNUF1NVlhIiwiYXpwIjoiUG9FZ1hQNnVWTzQ1SXNFTlJuZ0RYajVBdTVZYSIsImlzcyI6Imh0dHBzOlwvXC9sb2NhbGhvc3Q6OTQ0M1wvb2F1dGgyXC90b2tlbiIsImV4cCI6MTU0MTgwOTU4MiwiaWF0IjoxNTQxODA1OTgyLCJqdGkiOiI2Y2YyMGIwZS1lNGZmLTQzZmQtYTdiYS1kYTc3YTE3YzM2MzYifQ.Jm29jPliRvrK6Os34nSK3rhzIYLFjE__zdVGNng3uGKXGKzP3We_i6NPnhA0szJXMOKglXzUF1UgSz8MctbaxFS8XDusQPVe4LkB_45hwBm6TmBxzui911nt-1RbBLN_jZIlvl2lPrbTUH5hSn9kEkph6seWanTNQpz9tNEoVa6R_OX3kpJqxe8tLQUWw453A1JTwFNhdHa6-f1K8_Q_eEZ_4gOYINQ9t_fhTibdbkXZkJQFLop-Jwoybi9s4nwQU_dATocgcufq5eCeNItQeleT-23lGxIz0X7CiJrJynYLdd-ER0F77SumqEb5iCxhxuf4H7dovwd1kAmyKzLxpw&Version=2011-06-15
 ```
 
 ## Sample Response
@@ -199,18 +199,18 @@ http://minio.cluster:9000?Action=AssumeRoleWithWebIdentity&DurationSeconds=3600&
 
 ```
 export MINIO_ROOT_USER=minio
-export MINIO_ROOT_PASSWORD=minio123
+export MINIO_ROOT_PASSWORD=silo123
 export MINIO_IDENTITY_OPENID_CONFIG_URL=https://accounts.google.com/.well-known/openid-configuration
 export MINIO_IDENTITY_OPENID_CLIENT_ID="843351d4-1080-11ea-aa20-271ecba3924a"
 # Optional: Allow to specify the requested OpenID scopes (OpenID only requires the `openid` scope)
 #export MINIO_IDENTITY_OPENID_SCOPES="openid,profile,email"
-minio server /mnt/export
+silo server /mnt/export
 ```
 
 or using `mc`
 
 ```
-mc admin config get myminio identity_openid
+mc admin config get mysilo identity_openid
 identity_openid config_url=https://accounts.google.com/.well-known/openid-configuration client_id=843351d4-1080-11ea-aa20-271ecba3924a
 ```
 
@@ -246,32 +246,32 @@ $ go run web-identity.go -cid 204367807228-ok7601k6gj1pgge7m09h7d79co8p35xx.apps
 - Visit <http://localhost:8080>, login will direct the user to the Google OAuth2 Auth URL to obtain a permission grant.
 - The redirection URI (callback handler) receives the OAuth2 callback, verifies the state parameter, and obtains a Token.
 - Using the id_token the callback handler further talks to Google OAuth2 Token URL to obtain an JWT id_token.
-- Once obtained the JWT id_token is further sent to STS endpoint i.e MinIO to retrieve temporary credentials.
+- Once obtained the JWT id_token is further sent to STS endpoint i.e Silo to retrieve temporary credentials.
 - Temporary credentials are displayed on the browser upon successful retrieval.
 
-## Using MinIO Console
+## Using Silo Console
 
-To support WebIdentity based login for MinIO Console, set openid configuration and restart MinIO
+To support WebIdentity based login for Silo Console, set openid configuration and restart Silo
 
 ```
-mc admin config set myminio identity_openid config_url="<CONFIG_URL>" client_id="<client_identifier>"
+mc admin config set mysilo identity_openid config_url="<CONFIG_URL>" client_id="<client_identifier>"
 ```
 
 ```
-mc admin service restart myminio
+mc admin service restart mysilo
 ```
 
 Sample URLs for Keycloak are
 
 `config_url` - `http://localhost:8080/auth/realms/demo/.well-known/openid-configuration`
 
-JWT token returned by the Identity Provider should include a custom claim for the policy, this is required to create a STS user in MinIO. The name of the custom claim could be either `policy` or `<NAMESPACE_PREFIX>policy`.  If there is no namespace then `claim_prefix` can be ignored. For example if the custom claim name is `https://min.io/policy` then, `claim_prefix` should be set as `https://min.io/`.
+JWT token returned by the Identity Provider should include a custom claim for the policy, this is required to create a STS user in Silo. The name of the custom claim could be either `policy` or `<NAMESPACE_PREFIX>policy`.  If there is no namespace then `claim_prefix` can be ignored. For example if the custom claim name is `https://min.io/policy` then, `claim_prefix` should be set as `https://min.io/`.
 
-- Open MinIO Console and click `Login with SSO`
+- Open Silo Console and click `Login with SSO`
 - The user will be redirected to the Identity Provider login page
-- Upon successful login on Identity Provider page the user will be automatically logged into MinIO Console.
+- Upon successful login on Identity Provider page the user will be automatically logged into Silo Console.
 
 ## Explore Further
 
-- [MinIO Admin Complete Guide](https://silo.pgsty.com/reference/minio-mc-admin/)
+- [Silo Admin Complete Guide](https://silo.pgsty.com/reference/minio-mc-admin/)
-- [The MinIO documentation website](https://silo.pgsty.com/docs/)
+- [The Silo documentation website](https://silo.pgsty.com/docs/)

docs/sts/wso2.md

@@ -1,6 +1,6 @@
-# WSO2 Quickstart Guide [![Slack](https://slack.min.io/slack?type=svg)](https://slack.min.io)
+# WSO2 Quickstart Guide
 
-WSO2 is an Identity Server open source and is released under Apache Software License Version 2.0, this document covers configuring WSO2 to be used as an identity provider for MinIO server STS API.
+WSO2 is an Identity Server open source and is released under Apache Software License Version 2.0, this document covers configuring WSO2 to be used as an identity provider for Silo server STS API.
 
 ## Get started
 
@@ -16,7 +16,7 @@ Once WSO2 is up and running, configure WSO2 to generate Self contained id_tokens
 1. The id_token is an identifier that is hard to guess. For example, a randomly generated string of sufficient length, that the server handling the protected resource can use to lookup the associated authorization information.
 2. The id_token self-contains the authorization information in a manner that can be verified. For example, by encoding authorization information along with a signature into the token.
 
-WSO2 generates tokens in first style by default, but if to be used with MinIO we should configure WSO2 to provide JWT tokens instead.
+WSO2 generates tokens in first style by default, but if to be used with Silo we should configure WSO2 to provide JWT tokens instead.
 
 ### 3. Generate Self-contained Access Tokens
 
@@ -73,21 +73,21 @@ The id_token received is a signed JSON Web Token (JWT). Use a JWT decoder to dec
 | jti        | _string_       | Unique identifier for the JWT token.                                                                                                                                                    |
 | policy     | _string_       | Canned policy name to be applied for STS credentials. (Recommended)                                                                                                                     |
 
-Using the above `id_token` we can perform an STS request to MinIO to get temporary credentials for MinIO API operations. MinIO STS API uses [JSON Web Key Set Endpoint](https://docs.wso2.com/display/IS541/JSON+Web+Key+Set+Endpoint) to validate if JWT is valid and is properly signed.
+Using the above `id_token` we can perform an STS request to Silo to get temporary credentials for Silo API operations. Silo STS API uses [JSON Web Key Set Endpoint](https://docs.wso2.com/display/IS541/JSON+Web+Key+Set+Endpoint) to validate if JWT is valid and is properly signed.
 
 **We recommend setting `policy` as a custom claim for the JWT service provider follow [here](https://docs.wso2.com/display/IS550/Configuring+Claims+for+a+Service+Provider) and [here](https://docs.wso2.com/display/IS550/Handling+Custom+Claims+with+the+JWT+Bearer+Grant+Type) for relevant docs on how to configure claims for a service provider.**
 
-### 5. Setup MinIO with OpenID configuration URL
+### 5. Setup Silo with OpenID configuration URL
 
-MinIO server expects environment variable for OpenID configuration url as `MINIO_IDENTITY_OPENID_CONFIG_URL`, this environment variable takes a single entry.
+Silo server expects environment variable for OpenID configuration url as `MINIO_IDENTITY_OPENID_CONFIG_URL`, this environment variable takes a single entry.
 
 ```
 export MINIO_IDENTITY_OPENID_CONFIG_URL=https://localhost:9443/oauth2/oidcdiscovery/.well-known/openid-configuration
 export MINIO_IDENTITY_OPENID_CLIENT_ID="843351d4-1080-11ea-aa20-271ecba3924a"
-minio server /mnt/data
+silo server /mnt/data
 ```
 
-Assuming that MinIO server is configured to support STS API by following the doc [MinIO STS Quickstart Guide](https://silo.pgsty.com/developers/security-token-service/), execute the following command to temporary credentials from MinIO server.
+Assuming that Silo server is configured to support STS API by following the doc [Silo STS Quickstart Guide](https://silo.pgsty.com/developers/security-token-service/), execute the following command to temporary credentials from Silo server.
 
 ```
 go run client-grants.go -cid PoEgXP6uVO45IsENRngDXj5Au5Ya -csec eKsw6z8CtOJVBtrOWvhRWL4TUCga
@@ -101,9 +101,9 @@ go run client-grants.go -cid PoEgXP6uVO45IsENRngDXj5Au5Ya -csec eKsw6z8CtOJVBtrO
 }
 ```
 
-These credentials can now be used to perform MinIO API operations, these credentials automatically expire in 1hr. To understand more about credential expiry duration and client grants STS API read further [here](https://github.com/pgsty/minio/blob/master/docs/sts/client-grants.md).
+These credentials can now be used to perform Silo API operations, these credentials automatically expire in 1hr. To understand more about credential expiry duration and client grants STS API read further [here](https://github.com/pgsty/minio/blob/master/docs/sts/client-grants.md).
 
 ## Explore Further
 
-- [MinIO STS Quickstart Guide](https://silo.pgsty.com/developers/security-token-service/)
+- [Silo STS Quickstart Guide](https://silo.pgsty.com/developers/security-token-service/)
-- [The MinIO documentation website](https://silo.pgsty.com/docs/)
+- [The Silo documentation website](https://silo.pgsty.com/docs/)

docs/throttle/README.md

@@ -1,6 +1,6 @@
-# MinIO Server Throttling 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 Server Throttling Guide [![Docker Pulls](https://img.shields.io/docker/pulls/pgsty/silo.svg?maxAge=604800)](https://hub.docker.com/r/pgsty/silo/)
 
-MinIO server allows to throttle incoming requests:
+Silo server allows to throttle incoming requests:
 
 - limit the number of active requests allowed across the cluster
 - limit the wait duration for each request in the queue
@@ -11,23 +11,23 @@ These values are enabled using server's configuration or environment variables.
 
 ### Configuring connection limit
 
-If you have traditional spinning (hdd) drives, some applications with high concurrency might require MinIO cluster to be tuned such that to avoid random I/O on the drives. The way to convert high concurrent I/O into a sequential I/O is by reducing the number of concurrent operations allowed per cluster. This allows MinIO cluster to be operationally resilient to such workloads, while also making sure the drives are at optimal efficiency and responsive.
+If you have traditional spinning (hdd) drives, some applications with high concurrency might require Silo cluster to be tuned such that to avoid random I/O on the drives. The way to convert high concurrent I/O into a sequential I/O is by reducing the number of concurrent operations allowed per cluster. This allows Silo cluster to be operationally resilient to such workloads, while also making sure the drives are at optimal efficiency and responsive.
 
-Example: Limit a MinIO cluster to accept at max 1600 simultaneous S3 API requests across all nodes of the cluster.
+Example: Limit a Silo cluster to accept at max 1600 simultaneous S3 API requests across all nodes of the cluster.
 
 ```sh
 export MINIO_API_REQUESTS_MAX=1600
 export MINIO_ROOT_USER=your-access-key
 export MINIO_ROOT_PASSWORD=your-secret-key
-minio server http://server{1...8}/mnt/hdd{1...16}
+silo server http://server{1...8}/mnt/hdd{1...16}
 ```
 
 or
 
 ```sh
-mc admin config set myminio/ api requests_max=1600
+mc admin config set mysilo/ api requests_max=1600
-mc admin service restart myminio/
+mc admin service restart mysilo/
 ```
 
-> NOTE: A zero value of `requests_max` means MinIO will automatically calculate requests based on available RAM size and that is the default behavior.
+> NOTE: A zero value of `requests_max` means Silo will automatically calculate requests based on available RAM size and that is the default behavior.
 

docs/tls/README.md

@@ -1,23 +1,23 @@
-# How to secure access to MinIO server with TLS [![Slack](https://slack.min.io/slack?type=svg)](https://slack.min.io)
+# How to secure access to Silo server with TLS
 
-This guide explains how to configure MinIO Server with TLS certificates on Linux and Windows platforms.
+This guide explains how to configure Silo Server with TLS certificates on Linux and Windows platforms.
 
-1. [Install MinIO Server](#install-minio-server)
+1. [Install Silo Server](#install-minio-server)
-2. [Use an Existing Key and Certificate with MinIO](#use-an-existing-key-and-certificate-with-minio)
+2. [Use an Existing Key and Certificate with Silo](#use-an-existing-key-and-certificate-with-minio)
-3. [Generate and use Self-signed Keys and Certificates with MinIO](#generate-use-self-signed-keys-certificates)
+3. [Generate and use Self-signed Keys and Certificates with Silo](#generate-use-self-signed-keys-certificates)
 4. [Install Certificates from Third-party CAs](#install-certificates-from-third-party-cas)
 
-## 1. Install MinIO Server
+## 1. Install Silo Server
 
-Install MinIO Server using the instructions in the [MinIO Quickstart Guide](https://silo.pgsty.com/operations/deployments/baremetal-deploy-minio-on-redhat-linux/).
+Install Silo Server using the instructions in the [Silo Quickstart Guide](https://silo.pgsty.com/operations/deployments/baremetal-deploy-minio-on-redhat-linux/).
 
-## 2. Use an Existing Key and Certificate with MinIO
+## 2. Use an Existing Key and Certificate with Silo
 
-This section describes how to use a private key and public certificate that have been obtained from a certificate authority (CA). If these files have not been obtained, skip to [3. Generate Self-signed Certificates](#generate-use-self-signed-keys-certificates) or generate them with [Let's Encrypt](https://letsencrypt.org) using these instructions: [Generate Let's Encrypt certificate using Certbot for MinIO](https://silo.pgsty.com/integrations/generate-lets-encrypt-certificate-using-certbot-for-minio/). For more about TLS and certificates in MinIO, see the [Network Encryption documentation](https://silo.pgsty.com/operations/network-encryption/).
+This section describes how to use a private key and public certificate that have been obtained from a certificate authority (CA). If these files have not been obtained, skip to [3. Generate Self-signed Certificates](#generate-use-self-signed-keys-certificates) or generate them with [Let's Encrypt](https://letsencrypt.org) using these instructions: [Generate Let's Encrypt certificate using Certbot for Silo](https://silo.pgsty.com/integrations/generate-lets-encrypt-certificate-using-certbot-for-minio/). For more about TLS and certificates in Silo, see the [Network Encryption documentation](https://silo.pgsty.com/operations/network-encryption/).
 
 Copy the existing private key and public certificate to the `certs` directory. The default certs directory is:
 
-* **Linux:** `${HOME}/.minio/certs`
+* **Linux:** `${HOME}/.silo/certs`
 * **Windows:** `%%USERPROFILE%%\.minio\certs`
 
 **Note:**
@@ -26,7 +26,7 @@ Copy the existing private key and public certificate to the `certs` directory. T
 * Inside the `certs` directory, the private key must by named `private.key` and the public key must be named `public.crt`.
 * A certificate signed by a CA contains information about the issued identity (e.g. name, expiry, public key) and any intermediate certificates. The root CA is not included.
 
-## 3. Generate and use Self-signed Keys and Certificates with MinIO
+## 3. Generate and use Self-signed Keys and Certificates with Silo
 
 This section describes how to generate a self-signed certificate using various tools:
 
@@ -37,8 +37,8 @@ This section describes how to generate a self-signed certificate using various t
 
 **Note:**
 
-* MinIO only supports keys and certificates in PEM format on Linux and Windows.
+* Silo only supports keys and certificates in PEM format on Linux and Windows.
-* MinIO doesn't currently support PFX certificates.
+* Silo doesn't currently support PFX certificates.
 
 ### 3.1 Use `certgen` to Generate a Certificate
 
@@ -115,7 +115,7 @@ openssl genrsa -aes256 -passout pass:PASSWORD -out private.key 2048
 export MINIO_CERT_PASSWD=<PASSWORD>
 ```
 
-The default OpenSSL format for private encrypted keys is PKCS-8, but MinIO only supports PKCS-1. An RSA key that has been formatted with PKCS-8 can be converted to PKCS-1 using the following command:
+The default OpenSSL format for private encrypted keys is PKCS-8, but Silo only supports PKCS-1. An RSA key that has been formatted with PKCS-8 can be converted to PKCS-1 using the following command:
 
 ```sh
 openssl rsa -in private-pkcs8-key.key -aes256 -passout pass:PASSWORD -out private.key
@@ -230,15 +230,15 @@ certtool.exe --generate-self-signed --load-privkey private.key --template cert.c
 
 ## 4. Install Certificates from Third-party CAs
 
-MinIO can connect to other servers, including MinIO nodes or other server types such as NATs and Redis. If these servers use certificates that were not registered with a known CA, add trust for these certificates to MinIO Server by placing these certificates under one of the following MinIO configuration paths:
+Silo can connect to other servers, including Silo nodes or other server types such as NATs and Redis. If these servers use certificates that were not registered with a known CA, add trust for these certificates to Silo Server by placing these certificates under one of the following Silo configuration paths:
 
-* **Linux:** `~/.minio/certs/CAs/`
+* **Linux:** `~/.silo/certs/CAs/`
 * **Windows**: `C:\Users\<Username>\.minio\certs\CAs`
 
 ## Explore Further
 
-* [TLS Configuration for MinIO server on Kubernetes](https://github.com/pgsty/minio/tree/master/docs/tls/kubernetes)
+* [TLS Configuration for Silo server on Kubernetes](https://github.com/pgsty/minio/tree/master/docs/tls/kubernetes)
-* [MinIO Client Complete Guide](https://silo.pgsty.com/reference/minio-mc/)
+* [Silo Client Complete Guide](https://silo.pgsty.com/reference/minio-mc/)
-* [MinIO Network Encryption Overview](https://silo.pgsty.com/operations/network-encryption/)
+* [Silo Network Encryption Overview](https://silo.pgsty.com/operations/network-encryption/)
 * [Generate Let's Encrypt Certificate](https://silo.pgsty.com/integrations/generate-lets-encrypt-certificate-using-certbot-for-minio/)
-* [Setup nginx Proxy with MinIO Server](https://silo.pgsty.com/integrations/setup-nginx-proxy-with-minio/)
+* [Setup nginx Proxy with Silo Server](https://silo.pgsty.com/integrations/setup-nginx-proxy-with-minio/)

docs/tls/kubernetes/README.md

@@ -1,16 +1,16 @@
-# How to secure access to MinIO on Kubernetes with TLS [![Slack](https://slack.min.io/slack?type=svg)](https://slack.min.io)
+# How to secure access to Silo on Kubernetes with TLS
 
-This document explains how to configure MinIO server with TLS certificates on Kubernetes.
+This document explains how to configure Silo server with TLS certificates on Kubernetes.
 
 ## 1. Prerequisites
 
-- Familiarity with [MinIO deployment process on Kubernetes](https://silo.pgsty.com/operations/deployments/kubernetes/).
+- Familiarity with [Silo deployment process on Kubernetes](https://silo.pgsty.com/operations/deployments/kubernetes/).
 
 - Kubernetes cluster with `kubectl` configured.
 
 - Acquire TLS certificates, either from a CA or [create self-signed certificates](https://silo.pgsty.com/operations/network-encryption/).
 
-For a [distributed MinIO setup](https://silo.pgsty.com/operations/deployments/kubernetes/), where there are multiple pods with different domain names expected to run, you will either need wildcard certificates valid for all the domains or have specific certificates for each domain. If you are going to use specific certificates, make sure to create Kubernetes secrets accordingly.
+For a [distributed Silo setup](https://silo.pgsty.com/operations/deployments/kubernetes/), where there are multiple pods with different domain names expected to run, you will either need wildcard certificates valid for all the domains or have specific certificates for each domain. If you are going to use specific certificates, make sure to create Kubernetes secrets accordingly.
 
 For testing purposes, here is [how to create self-signed certificates](https://github.com/pgsty/minio/tree/master/docs/tls#3-generate-self-signed-certificates).
 
@@ -60,12 +60,12 @@ Note that the `secretName` should be same as the secret name created in previous
 ```yaml
     volumeMounts:
         - name: secret-volume
-          mountPath: /<user-running-minio>/.minio/certs
+          mountPath: /<user-running-silo>/.silo/certs
 ```
 
 Here the name of `volumeMount` should match the name of `volume` created previously. Also `mountPath` must be set to the path of
-the MinIO server's config sub-directory that is used to store certificates. By default, the location is
+the Silo server's config sub-directory that is used to store certificates. By default, the location is
-`/<user-running-minio>/.minio/certs`.
+`/<user-running-silo>/.silo/certs`.
 
-*Tip*: In a standard Kubernetes configuration, this will be `/root/.minio/certs`. Kubernetes will mount the secrets volume read-only,
+*Tip*: In a standard Kubernetes configuration, this will be `/root/.silo/certs`. Kubernetes will mount the secrets volume read-only,
-so avoid setting `mountPath` to a path that MinIO server expects to write to.
+so avoid setting `mountPath` to a path that Silo server expects to write to.

docs/tuning/README.md

@@ -1,4 +1,4 @@
-# How to enable 'minio' performance profile with tuned?
+# How to enable the `silo` performance profile with tuned
 
 ## Prerequisites
 
@@ -16,11 +16,11 @@ wget https://raw.githubusercontent.com/pgsty/minio/master/docs/tuning/tuned.conf
 
 #### Step 2 - install tuned.conf as supported performance profile on all nodes
 ```
-sudo mkdir -p /usr/lib/tuned/minio/
+sudo mkdir -p /usr/lib/tuned/silo/
-sudo mv tuned.conf /usr/lib/tuned/minio
+sudo mv tuned.conf /usr/lib/tuned/silo
 ```
 
-#### Step 3 - to enable minio performance profile on all the nodes
+#### Step 3 - enable the Silo performance profile on all nodes
 ```
-sudo tuned-adm profile minio
+sudo tuned-adm profile silo
 ```