Deploy MinIO: Single-Node Single-Drive

The procedures on this page cover deploying MinIO in a Single-Node Single-Drive (SNSD) configuration for early development and evaluation. SNSD deployments use a zero-parity erasure coded backend that provides no added reliability or availability beyond what the underlying storage volume implements. These deployments are best suited for local testing and evaluation, or for small-scale data workloads that do not have availability or performance requirements.

Important

RELEASE.2022-10-29T06-21-33Z fully removes the deprecated Gateway/Filesystem backends. MinIO returns an error if it starts up and detects existing Filesystem backend files.

To migrate from an FS-backend deployment, use mc mirror or mc cp to copy your data over to a new MinIO SNSD deployment. You should also recreate any necessary users, groups, policies, and bucket configurations on the SNSD deployment.

Pre-Existing Data

MinIO startup behavior depends on the the contents of the specified storage volume or path. The server checks for both MinIO-internal backend data and the structure of existing folders and files. The following table lists the possible storage volume states and MinIO behavior:

Storage Volume State	Behavior
Empty with no files, folders, or MinIO backend data	MinIO starts in SNSD mode and creates the zero-parity backend
Existing SNSD zero-parity objects and MinIO backend data	MinIO resumes in SNSD mode
Existing filesystem folders, files, but no MinIO backend data	MinIO returns an error and does not start
Existing filesystem folders, files, and legacy “FS-mode” backend data	MinIO returns an error and does not start Changed in version RELEASE.2022-10-29T06-21-33Z.

Prerequisites

Storage Requirements

The following requirements summarize the Storage section of MinIO’s hardware recommendations:

Use Local Storage

Direct-Attached Storage (DAS) has significant performance and consistency advantages over networked storage (NAS, SAN, NFS). MinIO strongly recommends flash storage (NVMe, SSD) for primary or “hot” data.

Use XFS-Formatting for Drives

MinIO strongly recommends provisioning XFS formatted drives for storage. MinIO uses XFS as part of internal testing and validation suites, providing additional confidence in performance and behavior at all scales.

Persist Drive Mounting and Mapping Across Reboots

Use /etc/fstab to ensure consistent drive-to-mount mapping across node reboots.

Non-Linux Operating Systems should use the equivalent drive mount management tool.

Exclusive access to drives

MinIO requires exclusive access to the drives or volumes provided for object storage. No other processes, software, scripts, or persons should perform any actions directly on the drives or volumes provided to MinIO or the objects or files MinIO places on them.

Unless directed by MinIO Engineering, do not use scripts or tools to directly modify, delete, or move any of the data shards, parity shards, or metadata files on the provided drives, including from one drive or node to another. Such operations are very likely to result in widespread corruption and data loss beyond MinIO’s ability to heal.

Memory Requirements

Changed in version RELEASE.2024-01-28T22-35-53Z: MinIO pre-allocates 2GiB of system memory at startup.

MinIO recommends a minimum of 32GiB of memory per host. See Memory for more guidance on memory allocation in MinIO.

Deploy Single-Node Single-Drive MinIO

The following procedure deploys MinIO consisting of a single MinIO server and a single drive or storage volume.

Network File System Volumes Break Consistency Guarantees

MinIO’s strict read-after-write and list-after-write consistency model requires local drive filesystems.

MinIO cannot provide consistency guarantees if the underlying storage volumes are NFS or a similar network-attached storage volume.

1) Download the MinIO Server

Homebrew

Open a Terminal and run the following command to install the latest stable MinIO package using Homebrew.

brew install minio/stable/minio

Important

If you previously installed the MinIO server using brew install minio, then we recommend that you reinstall from minio/stable/minio instead.

brew uninstall minio
brew install minio/stable/minio

Binary - arm64

Open a Terminal, then use the following commands to download the latest stable MinIO binary, set it to executable, and install it to the system $PATH:

curl -O https://dl.min.io/server/minio/release/darwin-arm64/minio
chmod +x ./minio
sudo mv ./minio /usr/local/bin/

Binary - amd64

Open a Terminal, then use the following commands to download the latest stable MinIO binary, set it to executable, and install it to the system $PATH:

curl -O https://dl.min.io/server/minio/release/darwin-amd64/minio
chmod +x ./minio
sudo mv ./minio /usr/local/bin/

2) Create the Environment Variable File

Create an environment variable file at /etc/default/minio. For Windows hosts, specify a Windows-style path similar to C:\minio\config. The MinIO Server container can use this file as the source of all environment variables.

The following example provides a starting environment file:

# MINIO_ROOT_USER and MINIO_ROOT_PASSWORD sets the root account for the MinIO server.
# This user has unrestricted permissions to perform S3 and administrative API operations on any resource in the deployment.
# Omit to use the default values 'minioadmin:minioadmin'.
# MinIO recommends setting non-default values as a best practice, regardless of environment

MINIO_ROOT_USER=myminioadmin
MINIO_ROOT_PASSWORD=minio-secret-key-change-me

# MINIO_VOLUMES sets the storage volume or path to use for the MinIO server.

MINIO_VOLUMES="/mnt/data"

# MINIO_OPTS sets any additional commandline options to pass to the MinIO server.
# For example, `--console-address :9001` sets the MinIO Console listen port
MINIO_OPTS="--console-address :9001"

Include any other environment variables as required for your deployment.

New in version Server: RELEASE.2024-03-03T17-50-39Z

MinIO automatically generates unique root credentials if all of the following conditions are true:

KES Release 2024-03-01T18-06-46Z or later running
Have not defined:
- MINIO_ROOT_USER variable
- MINIO_ROOT_PASSWORD variable
Have:
- set up KES with a supported KMS target
- disabled root access with the MinIO environment variable

When those conditions are met at startup, MinIO uses the KMS to generate unique root credentials for the deployment using a hash-based message authentication code (HMAC).

If MinIO generates such credentials, the key used to generate the credentials must remain the same and continue to exist. All data on the deployment is encrypted with this key!

To rotate the generated root credentials, generate a new key in the KMS, then update the value of the MINIO_KMS_KES_KEY_NAME with the new key.

3) Start the MinIO Deployment

Issue the following command on the local host to start the MinIO SNSD deployment as a foreground process. You must keep the shell or terminal session open to keep the process running.

From the Terminal, use the minio server to start a local MinIO instance in the ~/data folder. If desired, you can replace ~/data with another location to which the user has read, write, and delete access for the MinIO instance.

export MINIO_CONFIG_ENV_FILE=/etc/default/minio
minio server --console-address :9001

Status:         1 Online, 0 Offline.
API: http://192.168.2.100:9000  http://127.0.0.1:9000
RootUser: myminioadmin
RootPass: minio-secret-key-change-me
Console: http://192.168.2.100:9001 http://127.0.0.1:9001
RootUser: myminioadmin
RootPass: minio-secret-key-change-me

Command-line: https://min.io/docs/minio/linux/reference/minio-mc.html
   $ mc alias set myminio http://10.0.2.100:9000 myminioadmin minio-secret-key-change-me

Documentation: https://min.io/docs/minio/linux/index.html

The API block lists the network interfaces and port on which clients can access the MinIO S3 API. The Console block lists the network interfaces and port on which clients can access the MinIO Web Console.

4) Connect to the MinIO Deployment

MinIO Console

You can access the MinIO Console by entering any of the hostnames or IP addresses from the MinIO server Console block in your preferred browser, such as http://localhost:9001.

Log in with the MINIO_ROOT_USER and MINIO_ROOT_PASSWORD configured in the environment file specified to the container.

MinIO Console displaying Buckets view in a fresh installation

You can use the MinIO Console for general administration tasks like Identity and Access Management, Metrics and Log Monitoring, or Server Configuration. Each MinIO server includes its own embedded MinIO Console.

If your local host firewall permits external access to the Console port, other hosts on the same network can access the Console using the IP or hostname for your local host.

MinIO CLI (mc)

You can access the MinIO deployment over a Terminal or Shell using the MinIO Client (mc). See MinIO Client Installation Quickstart for instructions on installing mc.

Create a new alias corresponding to the MinIO deployment. Specify any of the hostnames or IP addresses from the MinIO Server API block, such as http://localhost:9000.

mc alias set myminio http://localhost:9000 myminioadmin minio-secret-key-change-me

Replace myminio with the desired name to use for the alias.
Replace myminioadmin with the MINIO_ROOT_USER value in the environment file specified to the container.
Replace minio-secret-key-change-me with the MINIO_ROOT_PASSWORD value in the environment file specified to the container.

You can then interact with the container using any mc command. If your local host firewall permits external access to the MinIO S3 API port, other hosts on the same network can access the MinIO deployment using the IP or hostname for your local host.