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.

MinIO AIStor uses Policy-Based Access Control (PBAC) to define the authorized actions and resources to which an authenticated user has access. Each policy describes one or more actions and conditions that outline the permissions of a user or group of users. MinIO AIStor PBAC is built for compatibility with AWS IAM policy syntax, structure, and behavior. This documentation makes a best-effort to cover IAM-specific behavior and functionality. Refer also to the AWS IAM documentation for more information.

MinIO AIStor Table Shares support grouping multiple tables under a single share. Each share has one or more schema under which you can associate multiple tables. When you access the share from a remote client, you can perform operations against any table under a given schema. When you create a new table share, you define the initial schema and table associated to that share. You can then add new tables to that share under the same or a different schema.

If an MinIO AIStor node suffers complete hardware failure (for example, loss of all drives, data, etc.), the node begins healing operations once it rejoins the deployment. MinIO AIStor healing occurs only on the replaced hardware and does not typically impact deployment performance. MinIO AIStor healing ensures consistency and correctness of all data restored onto the drive. Changed in RELEASE.2025-02-04T00-52-01Z If multiple drives within the same erasure set require healing, MinIO AIStor prioritizes the first drive that begins healing within the erasure set. Other drives in the erasure set wait until healing finishes on the first drive before the next drive starts healing.

MinIO AIStor supports publishing bucket notification events to a Redis service endpoint. Prerequisites The MinIO AIStor mc command line tool This procedure uses the mc command line tool for certain actions. See the mc Quickstart for installation instructions. Add a Redis endpoint to an AIStor Server The following procedure adds a new Redis service endpoint for supporting bucket notifications in an AIStor Server.

The procedure on this page creates a new object lifecycle management rule that transition objects from an MinIO AIStor bucket to a remote storage tier on the storage backend. This procedure supports use cases like moving aged data to low-cost public cloud storage solutions after a certain time period or calendar date. Requirements Install and configure mc This procedure uses mc for performing operations on the MinIO AIStor cluster. Install mc on a machine with network access to both source and destination clusters. See the mc Installation Quickstart for instructions on downloading and installing mc.

Upgrade MinIO to MinIO AIStor in airgapped Kubernetes environments using private registries, mirrored images, and custom service registry configurations.