The mc event rm command removes an event notification trigger from a bucket. The mc event remove command has equivalent functionality to mc event rm. Syntax Example The following command removes a configured event notifications for the specified bucket notification target for the mydata bucket on the myaistor AIStor deployment:

The mc admin scanner status command displays a real-time summary of scanner information for an AIStor Server. This command has an alias of mc admin scanner info. Syntax Example The following example returns information about the current state of the scanner process.

This procedure deploys MinIO AIStor on Kubernetes clusters using a private container registry for images while installing Helm charts from the public MinIO Helm repository. Use this procedure when your environment has internet access to install Helm charts from helm.min.io but you need to pull container images from a private container registry instead of the public quay.io registry. This procedure requires installation of Kubernetes operators and associated resources including CustomResourceDefinitions, StatefulSets, and Secrets into new or existing Namespaces. You must perform the operations in this procedure as a user that has broad permissions to create resources within multiple Namespaces.

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.

MinIO AIStor implements Transport Layer Security (TLS) 1.2+ encryption with support for Server Name Indication (SNI) for selecting relevant TLS certificates in response to client requests. MinIO AIStor supports two types of certificate management: Automatic TLS certificate provisioning (default) User-provided TLS certificates When deploying an MinIO AIStor resource, the CRD definition provides a certificates field for controlling certificate generation and behavior. This field is also available in the object store Helm chart.

This page explains how to deploy MinIO AIStor with KES for Server Side Encryption. For instructions on running KES, see the KES docs. Broadly, the required steps are: Create a new external key (EK) for server-side encryption (SSE). Create or modify an MinIO AIStor deployment to support SSE with KES. Configure automatic bucket-default SSE. Enabling SSE on an MinIO AIStor deployment automatically encrypts the backend data for that deployment using the default encryption key.

Deployment Checklists The following checklists provide a high-level guideline for validating production-readiness of AIStor Servers. These checklists may not meet the precise requirements of your unique deployment topology or architecture, and are intended as a best-effort guide to reliable production deployments.

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.

This page describes how to enable FIPS 140-3 ready cryptography for MinIO AIStor deployments on Linux. When enabled, FIPS mode restricts cryptographic operations to algorithms that align with the Federal Information Processing Standards (FIPS) 140-3 program. Organizations subject to U.S. federal government compliance requirements, or those with similar regulatory needs, may require FIPS-aligned cryptography. MinIO AIStor FIPS mode uses Go’s native cryptographic module, which restricts operations to FIPS 140-3 approved algorithms. MinIO makes no statements or representations regarding FIPS 140-3 certification status. Evaluate whether this implementation meets your specific compliance requirements. Overview MinIO AIStor uses Go 1.24’s native FIPS 140-3 cryptographic module. Enable FIPS mode at runtime with the GODEBUG environment variable. There is no separate binary required.

Site replication configures multiple independent MinIO AIStor deployments as a cluster of replicas called peer sites. Site replication assumes the use of either the included MinIO AIStor identity provider (IDP) or an external IDP. All configured deployments must use the same IDP. Deployments using an external IDP must use the same configuration across sites. MinIO AIStor does not recommend using macOS, Windows, or non-orchestrated containerized deployments for site replication except for early development, evaluation, or general experimentation.