What You Configure on a Bucket

Most of what you configure in MinIO AIStor is set on a bucket rather than on the deployment. Each setting has its own page in this section, which makes them hard to see as one set. This page collects them.

Nothing here is configured on a bucket by default. A new bucket has no versioning, no lifecycle rules, no replication, no notifications, and no limits until you add them.

Versioning makes every write create a new version rather than replacing the object, so a delete or an overwrite is recoverable. It is the setting most others depend on: object locking, replication, and version-count expiry rules all require it.

Enable it per bucket, and narrow it if you need to. Excluded prefixes stay unversioned inside a versioned bucket.

Object locking and immutability enforces Write-Once Read-Many protection on a versioned bucket. A GOVERNANCE or COMPLIANCE retention mode protects an object for a fixed period, and a legal hold protects it indefinitely.

You set object locking when you create the bucket. It cannot be added to a bucket that already exists.

Object lifecycle management expires objects after a period or after a number of versions, and can transition them to a remote storage tier instead of deleting them.

Bucket replication copies objects to another deployment, in one direction or both. It requires versioning on both ends.

Replicating everything instead of selected buckets is a deployment-level choice. See site replication.

Bucket notifications publish an event when an object is created, removed, or accessed, to targets including Kafka, RabbitMQ, Elasticsearch, webhooks, and several databases.

Bucket-level Quality of Service caps request rate and concurrent operations, with a network layer that caps bandwidth. Use it so no single workload overloads a shared cluster.

Bucket quotas cap how much data the bucket holds. The scanner evaluates them periodically rather than in real time, so a bucket can pass its quota between cycles.

CORS configuration sets which web origins may call the bucket, either globally or per bucket.

Access is not configured on the bucket itself. It comes from policies attached to users and groups, which name buckets and prefixes as resources.

Anonymous access is the exception, and it is set on the bucket. An anonymous policy grants unauthenticated callers access to the bucket or a prefix, which can make its contents public. Manage it with mc anonymous.

For separating teams or customers across buckets in one deployment, see the multi-tenancy guidance.