MinIO AIStor supports publishing audit logs to one or more configured Apache Kafka receivers. MinIO AIStor send an event for each API operation to the receiver for processing and storage. The receiver is responsible for correctly processing events, including returning 200OK or similar success messages upon receipt of the event. MinIO AIStor cannot recover events that were successfully sent but not correctly stored on the receiver. You can configure a new Kafka audit endpoint using either environment variables or runtime configuration settings. If you configure both, MinIO AIStor uses the environment variables.

MinIO AIStor allows you to temporarily remove nodes from active service for planned maintenance operations. Removing nodes allows administrators to gracefully take nodes offline without disrupting cluster operations, similar to the cordon functionality in Kubernetes. A cordoned node finishes in-flight operations and marks itself as unavailable for any other operation. Use this to do hardware maintenance on a node, complete operating system updates, or perform troubleshooting. MinIO AIStor cordoning on Kubernetes In Kubernetes environments, the MinIO AIStor cordoning function applies to the Pod running the associated workload. It does not affect any other Pods or services running on the Kubernetes worker, and acts to ensure the scheduler does not reschedule that Pod during ongoing maintenance operations. The following diagram illustrates the node state transitions during the maintenance workflow:

The following procedure adds a server pool to an existing MinIO AIStor cluster running on Kubernetes infrastructure. Each pool expands the total available storage capacity of the cluster with new nodes and persistent volumes while maintaining the overall availability of the cluster. Pay particular attention to the parity (EC:M) value of the existing cluster and the new pool. MinIO strongly recommends seeking an architecture review from MinIO Engineering through SUBNET to analyze potential performance impacts before committing to a new pool for your cluster.

AIStor Server publishes cluster and node metrics using the Prometheus Data Model. You can use any scraping tool to pull metrics data from AIStor Server for further analysis and alerting. This page covers metrics version 3, which has additional metrics and endpoints. Existing deployments can continue to use version 2 metrics. Version 3 endpoints The base endpoint, without an added path, returns cluster, node, and per-bucket statistic metrics from /cluster/usage/buckets.

The MinIO AIStor Operator runs an internal upgrade webhook server on port 4221. MinIO pods connect to this webhook during in-pod version updates to download new binaries. This connection requires TLS, and the MinIO pods must trust the certificate presented by the operator. How operator autocert works By default, the operator generates its own TLS certificate using the Kubernetes Certificate Signing Request (CSR) API. The operator creates a CSR with the kubernetes.io/kubelet-serving signer, which the Kubernetes API server signs using the cluster’s kubelet CA.

MinIO AIStor is licensed under the MinIO Software License. An active license is required for production deployments. This section documents steps for running MinIO AIStor as a container. Procedure Pull the latest stable image of AIStor Server Docker docker pull quay.io/minio/aistor/minio Podman podman pull quay.io/minio/aistor/minio Create the directory structure Create directories for data and certificates. The following example uses $HOME/minio as the base path.

Use the following checklist when planning the software configuration for a production, distributed MinIO deployment. MinIO AIStor pre-requisites Operating system Servers must run a Linux operating system with a kernel version of 6.8 or later to access critical performance features.

Use the following checklist when planning the security configuration for a production, distributed AIStor Server. Required steps Identity and access management Step Details Group policies Define group policies either on MinIO AIStor or the selected 3rd party Identity Provider (LDAP/Active Directory or OpenID Connect) Individual access policies Define individual access policies on MinIO AIStor or the selected 3rd party Identity Provider Identity provider configuration Configure MinIO AIStor to use the selected 3rd party Identity Provider Firewall access Port Details S3 API listen port Grant firewall access for TCP traffic to the Object Store S3 API Listen Port (Default: 9000) Console port Grant firewall access for TCP traffic to the AIStor Server console port (Recommended Default: 9443) Encryption-at-rest MinIO AIStor supports Server-Side Encryption using MinIO KMS:

You may create objects whose sole purpose is organizing a bucket. These objects end with the / character. Versioning is often not of value for these types of objects that have no data. For example, an object at ALIAS/team-bucket/reports may serve as an organization path only and not be a data object. Instead, it contains objects under it, such as ALIAS/team-bucket/reports/2025/june.csv. You may exclude folder objects to prevent ALIAS/team-bucket/reports from being versioned while allowing all objects under it to be versioned.

Manage TLS certificates for MinIO AIStor deployments. TLS certificate management with cert-manager: automate certificate provisioning and renewal using cert-manager issuers Certificate rotation: rotate certificates without downtime on Linux and Kubernetes, monitor expiry with Prometheus TLS certificate troubleshooting: diagnose common TLS errors, inspect certificates, and resolve trust chain issues