Deploy Silo on macOS
This page documents deploying Silo onto Apple macOS hosts for development and evaluation.
Silo publishes separate macOS archives for Intel and Apple Silicon. The current project CI runs on Linux and does not establish a macOS support-lifecycle guarantee, so the inherited, dated list of “supported” macOS releases has been removed. Validate the exact operating-system version and workload before production use.
The procedure includes guidance for deploying Single-Node Multi-Drive (SNMD) and Single-Node Single-Drive (SNSD) topologies in support of early development and evaluation environments.
This guide does not validate Multi-Node Multi-Drive (MNMD) distributed configurations on macOS hosts.
Considerations
Review Checklists
Ensure you have reviewed our published Hardware, Software, and Security checklists before attempting this procedure.
Erasure Coding Parity
MinIO automatically determines the default erasure coding configuration for the cluster based on the total number of nodes and drives in the topology. You can configure the per-object parity setting when you set up the cluster or let MinIO select the default (EC:4 for production-grade clusters).
Parity controls the relationship between object availability and storage on disk. Use the MinIO Erasure Code Calculator for guidance in selecting the appropriate erasure code parity level for your cluster.
While you can change erasure parity settings at any time, objects written with a given parity do not automatically update to the new parity settings.
Procedure
1. Download the Silo Binary
Choose the Intel (darwin_amd64) or Apple Silicon (darwin_arm64) archive from Download & Install. Verify the archive against the checksum published with the same release, extract it, and install the silo binary:
The old Homebrew commands on this page installed the upstream MinIO formula, not Silo, and have therefore been removed.
2. Enable TLS Connectivity
You can skip this step to deploy without TLS enabled. MinIO strongly recommends against non-TLS deployments outside of early development.
Create or provide Transport Layer Security (TLS) certificates to MinIO to automatically enable HTTPS-secured connections between the server and clients.
MinIO expects the default certificate names of private.key and public.crt for the private and public keys respectively. Place the certificates in a dedicated directory:
SILO uses the operating system trust store and the configured CAs directory to verify TLS peers when connecting to other services, such as nodes and replication targets. For a private CA, place its CA certificate in /opt/minio/certs/CAs and make it readable by the service account. Enabling server TLS alone does not enable client-certificate authentication.
For more specific guidance on configuring MinIO for TLS, including multi-domain support via Server Name Indication (SNI), see Network Encryption (TLS).
Certificates for Early Development
For local testing or development environments, you can use the MinIO certgen to mint self-signed certificates. For example, the following command generates a self-signed certificate with a set of IP and DNS Subject Alternate Names (SANs) associated to the MinIO Server hosts:
Place the generated public.crt and private.key into the /path/to/certs directory to enable TLS for the MinIO deployment. Applications can use the public.crt as a trusted Certificate Authority to allow connections to the MinIO deployment without disabling certificate validation.
3. Create the MinIO Environment File
Create an environment file at /etc/default/silo. The launch command below reads it through MINIO_CONFIG_ENV_FILE; macOS does not use the Linux systemd unit.
Modify the example to reflect your deployment topology.
Use Single-Node Multi-Drive deployments in development and evaluation environments. You can also use them for smaller storage workloads which can tolerate data loss or unavailability due to node downtime.
Use Single-Node Single-Drive (“Standalone”) deployments in early development and evaluation environments. MinIO does not recommend Standalone deployments in production, as the loss of the node or its storage medium results in data loss.
Specify any other environment variables or server command-line options as required by your deployment.
MINIO_CONFIG_ENV_FILE is parsed by the server; it is not sourced as a shell script. Quote values when leading or trailing spaces are significant. Named configuration targets may contain visible punctuation such as my-hook; malformed keys, NUL, and invisible characters stop startup with a value-redacted file-and-line error. See Config Environment Files Are Not Shell Scripts.
4. Start the MinIO Server
The following command starts the MinIO Server attached to the current terminal/shell window:
The command output resembles the following:
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.
To run the MinIO server process in the background or as a daemon, defer to the macOS documentation for best practices and procedures.
5. Connect to the Deployment
Open your browser and access any of the MinIO hostnames at port :9001 to open the MinIO Console login page. For example, https://minio1.example.com:9001.
Log in with the MINIO_ROOT_USER and MINIO_ROOT_PASSWORD from the previous step.
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.
Follow the installation instructions for mcli on your local host. Run mcli --version to verify the installation. Substitute the installed mcli for the mc examples below; the arguments are unchanged.
If your MinIO deployment uses third-party or self-signed TLS certificates, copy the CA files to ~/.mc/certs/CAs to allow mc
Once installed, create an alias for the MinIO deployment:
Change the hostname, username, and password to reflect your deployment. The hostname can be any MinIO node in the deployment. You can also specify the hostname load balancer, reverse proxy, or similar network control plane that handles connections to the deployment.
6. Next Steps
- Enable TLS before exposing the service beyond a trusted development network.
- Create least-privilege users and policies through Identity and Access Management.
- Configure monitoring and alerting before relying on the deployment for persistent data.