Back to Article List

How to install Miniconda on macOS (Intel and Apple Silicon)

How to install Miniconda on macOS (Intel and Apple Silicon)

Anaconda publishes four macOS installers for Miniconda, two architectures (arm64 and x86_64) times two formats (a graphical .pkg and a command-line .sh script), and only one of the four is right for the Mac in front of you. My advice up front: it's the .sh matching your chip. What follows covers picking it, running it, wiring conda into zsh and the Homebrew alternative, which comes with one real gotcha.

arm64 or x86_64: Check your chip first

Every Apple Silicon Mac, M1 through the current generation, takes the arm64 installer, and Intel Macs take x86_64. When you're not sure what's in the machine:

uname -m

Whatever it prints is the word that belongs in your installer filename. The x86_64 build will technically run on Apple Silicon through Rosetta 2, and this sounds harmless right up until every numpy operation is paying an emulation tax and some compiled packages won't load at all. It's the classic outcome of copying an install command from a pre-2021 blog post.

Skip the .pkg, use the .sh installer

The .pkg gives you a familiar double-click wizard, and I don't recommend it anyway, for two reasons. The first is reliability: community threads (r/learnpython has a well-worn one from the Ventura era) report the PKG dying with "This package is incompatible with this version of macOS. The package is trying to install content to the system volume" on Macs where the .sh script proceeds without complaint. The second is control, since the .pkg offers no batch flags and no scripting. The shell installer is also character-for-character what you'd run on a Linux server, so whatever you learn here transfers.

Install Miniconda with the shell installer

Download the build for your architecture (swap in x86_64 on Intel):

curl -O https://repo.anaconda.com/miniconda/Miniconda3-latest-MacOSX-arm64.sh

Check it against the SHA256 hash published beside the file on the Miniconda repo index:

shasum -a 256 Miniconda3-latest-MacOSX-arm64.sh

Then run it:

bash Miniconda3-latest-MacOSX-arm64.sh

The license shows up inside a pager: Enter opens it, q closes it, and typing yes accepts. Take the default install location of ~/miniconda3, and when the installer asks about running conda init, say yes, since that's the step that teaches your shell where conda lives.

Set up conda in zsh

macOS has defaulted to zsh since Catalina, so the installer's conda init writes its block into ~/.zshrc. Reload it:

source ~/.zshrc

Your prompt gains a (base) prefix and conda --version answers. If you declined the init question earlier, it can be run at any point:

~/miniconda3/bin/conda init zsh

The command takes any shell you name, so long-time Mac users who carried bash across upgrades run conda init bash instead. A terminal that still says "conda: command not found" after all of this usually means the init block landed in the wrong profile file; fixing that is one of the walkthroughs in the Miniconda troubleshooting guide.

Installing Miniconda with Homebrew

On a Mac that's brew-managed end to end there's a cask, and the miniconda cask currently tracks py314_26.5.3-2, the same release as the official installers:

brew install --cask miniconda

Two things before choosing this route. The cask prints a caveat after install that people routinely skip: your shell still needs initializing by hand, with

conda init "$(basename "${SHELL}")"

which on a stock Mac resolves to conda init zsh, and skipping it means new terminals never learn conda exists. And the miniconda cask conflicts with the miniforge cask, so brew won't hold both. That second point deserves more thought than it usually gets, because Miniforge is the community installer preconfigured for conda-forge, the licensing difference between the two is real, and the Miniconda vs Miniforge comparison is worth reading before you commit either way.

Between brew and the official installer, the official .sh wins for anything serious. You pick the exact version, verify the hash yourself and the install lands predictably in ~/miniconda3, where the cask puts it under Homebrew's Caskroom directory instead (brew info --cask miniconda shows the path on your machine). You also end up with two package managers holding opinions about one tool, because conda updates itself independently of whatever version brew's cask has pinned. The drift is mostly cosmetic, but "mostly" is doing some work in that sentence when a colleague asks why brew list and conda --version disagree.

Where Miniconda is installed on a Mac

With the official installer, everything, conda itself, base and every environment you create, sits under ~/miniconda3 unless you chose another prefix. Nothing touches the system Python that macOS guards, nothing sprawls into /usr/local, and removal later is essentially one directory plus the shell init block, the short procedure in the uninstall Miniconda guide.

Verify the install did what it claims:

conda --version
conda create -n test python=3.12 -y
conda activate test

On Apple Silicon, packages inside that environment resolve to native osx-arm64 builds, visible in the platform line of conda info. Current installers support macOS 12.1 and newer, per the official install documentation, and earlier releases stay downloadable from the archive section of the repo index for anyone nursing an older machine. From here the daily work is creating and managing conda environments, identical on a Mac to everywhere else.

Questions?

I installed the x86_64 build on an M2 Mac by mistake. Do I have to start over?

Reinstalling is the clean fix and takes about ten minutes: remove the install directory and the shell init block, then run the arm64 installer. Recreate your environments from an exported file instead of migrating folders, since every compiled package needs its arm64 counterpart anyway. Rosetta will keep the x86_64 install limping along in the meantime, at a real speed cost on every scientific package.

About the author

Alice Langley

I got my first writing work through open-source projects. Before anybody paid me, I was the person rewriting installation notes, answering the same question in Discord for the 25th time and fixing READMEs because the instructions were driving me mad. I was studying then and honestly didn't know technical writing was a job.

But now it's MY job: mostly tutorials, occasionally docs, KBs, sometimes editing. I work freelance. The non-computer part of my life is fairly crowded. I make cosplay costumes and props (sewing is the bit I'm best at, wigs are a different story for now), watch a lot of horror films and have recently started learning bookbinding from somebody who is much more patient than I am.

Deploy your next project in seconds

Bring your winning ideas online faster, with modern hardware and unmetered bandwidth. Join a European cloud trusted by thousands of developers and businesses worldwide.