AIStor supports deploying resources onto macOS hosts for local development and evaluation. For the purposes of evaluation or local development, MinIO recommends using a machine released in the last 4 years with at least 8 GB of RAM. You can use any supported version of macOS. For testing or local development using a virtualized environment, use a machine with a higher number of cores and 16 or 32GB of RAM.

This procedure downloads and installs the AIStor Server onto bare-metal hosts running Red Hat Enterprise Linux Review the Hardware and System Requirements to ensure your target infrastructure meets our guidance. You can also open a SUBNET issue to request an architecture review or assistance during deployment. MinIO strongly recommends using only RHEL releases in the Full Support lifecycle with Long-Term Support (LTS) Kernels in the 6.12 or later release series, such as RHEL 10. See Linux Kernel Requirements for recommended distributions and performance details.

This procedure provides guidance for enabling Server-Side Encryption (SSE) using MinIO KMS as the Key Management Service (KMS). Enabling SSE on an AIStor deployment automatically encrypts the backend data for that deployment using the default encryption key selected during the setup process.

Configure load balancers and Ingress controllers for AIStor on Kubernetes. Includes examples for NGINX, HAProxy, and Traefik.

This page describes how to enable FIPS 140-3 ready cryptography for AIStor deployments on Kubernetes. 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. 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 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.

Install on Red Hat Enterprise Linux Deploy AIStor onto RHEL 10+

The procedure on this page creates a new object lifecycle management rule that transitions objects from a bucket on a primary AIStor deployment to a bucket on a remote AIStor deployment. This procedure supports cost-management strategies such as tiering objects from a “hot” AIStor deployment using NVMe storage to a “warm” AIStor deployment using SSD. Requirements Install and configure mc This procedure uses mc for performing operations on the 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.

AIStor provides multiple replication strategies to ensure data availability, support disaster recovery, enable geographic distribution, and facilitate data migration between clusters. Each replication method serves different use cases and operates at different levels, from entire cluster to individual objects. Replication methods AIStor supports four distinct replication and synchronization approaches:

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. You must set up TLS before you can enable data encryption, also called server-side encryption. AIStor supports the following types of certificate signatures: self-signed internal or private certificate authorities (CAs) third-party CAs Multiple certificates are implemented with SNI to determine which certificate to return to a client based on the hostname in the request.

For identities managed by an external OpenID Connect (OIDC) compatible provider, AIStor can use either of two methods to assign policies to the authenticated user. AIStor by default denies access to all actions or resources not explicitly allowed by a user’s assigned or inherited policies. Authorization options with OIDC OIDC integration in AIStor supports either of the following authorization methods: