Install AutoDock Vina with Conda on Apple Silicon (the Right Way)

AutoDock Vina is one of the most widely used open-source engines for molecular docking and virtual screening. It predicts how a small-molecule ligand fits into a protein receptor and scores that pose as an estimated binding free energy in kcal/mol. Modern versions (the 1.2.x line) ship both the command-line tools (vina, vina_split) and a Python API, so you can script whole docking pipelines.

This guide is a cautionary tale with a happy ending. On an Apple Silicon Mac, the "obvious" install (bioconda autodock-vina) leads to a binary that literally cannot run on your CPU. We will show you that failure honestly, with the real terminal output, and then the clean fix: the native arm64 vina package from conda-forge. The lesson at the heart of this whole series lives here in plain sight: put the build that matches your architecture inside its own isolated env, and everything just works.

Why isolate it, and why it matters extra here

Every tool in this series gets its own conda environment. That keeps its exact dependencies (a specific python, numpy, and C++ runtime) pinned and reproducible, and stops one tool from breaking another. Vina makes the case vividly: the packaged binary is architecture-specific. An environment is where the right architecture lives. Pick the wrong package and the env cheerfully installs a 32-bit executable that your Mac cannot execute at all.

Prerequisites

You need conda. If you have not set it up yet, follow our Miniconda on Apple Silicon guide first, then come back. This walkthrough was run on:

• Apple Silicon Mac (arm64), macOS 26.5.2
• conda 25.5.1 with the fast libmamba solver

We also pass --override-channels -c conda-forge on every command. On recent conda releases the bundled defaults channel is gated behind a Terms-of-Service prompt; overriding channels so only conda-forge is consulted sidesteps that gate entirely.

TL;DR: the install that actually works

If you just want a working Vina on Apple Silicon, run this and skip to Verify:

# Native arm64 AutoDock Vina 1.2.7 from conda-forge — no Rosetta needed
conda create -n bu-vina --override-channels -c conda-forge python=3.11 vina=1.2.7
conda activate bu-vina
vina --version

That conda-forge vina 1.2.7 package has a native osx-arm64 build and bundles both the CLI executables and the Python vina module. The rest of this post explains what goes wrong if you reach for bioconda instead, and why.

The wrong turn: bioconda autodock-vina on Apple Silicon

The package most tutorials point you at is autodock-vina on bioconda. Here is what happens when you ask for it natively on an arm64 Mac:

conda create -n bu-vina --override-channels -c conda-forge -c bioconda autodock-vina

Channels:
 - conda-forge
 - bioconda
Platform: osx-arm64
Collecting package metadata (repodata.json): done
Solving environment: failed

PackagesNotFoundError: The following packages are not available from current channels:

  - autodock-vina

Current channels:

  - https://conda.anaconda.org/conda-forge
  - https://conda.anaconda.org/bioconda

No arm64 build exists. The bioconda autodock-vina package is the legacy 1.1.2 release last built in 2016, and it only ships linux-64 and osx-64 binaries. So far, so honest — the solver refused to lie to us.

Forcing it under Rosetta (and why that is a trap)

The usual escape hatch when a package lacks an arm64 build is to install the Intel (osx-64) build and let Rosetta 2 translate it. We can force that with CONDA_SUBDIR=osx-64:

CONDA_SUBDIR=osx-64 conda create -n bu-vina --override-channels -c conda-forge -c bioconda autodock-vina

This time the solve succeeds:

Platform: osx-64
Solving environment: done

## Package Plan ##

  environment location: /opt/homebrew/Caskroom/miniconda/base/envs/bu-vina

The following NEW packages will be INSTALLED:

  autodock-vina      bioconda/osx-64::autodock-vina-1.1.2-2

Preparing transaction: done
Verifying transaction: done
Executing transaction: done

It installed. Feels like a win. It is not. Try to run it:

conda run -n bu-vina vina --version

/opt/homebrew/Caskroom/miniconda/base/envs/bu-vina/bin/vina: Bad CPU type in executable
ERROR conda.cli.main_run:execute(127): `conda run vina --version` failed. (See above for error)

Bad CPU type in executable. Rosetta translates 64-bit Intel code, but it will not run 32-bit code at all. Let's ask macOS what that binary actually is:

file /opt/homebrew/Caskroom/miniconda/base/envs/bu-vina/bin/vina

/opt/homebrew/Caskroom/miniconda/base/envs/bu-vina/bin/vina: Mach-O universal binary with 2 architectures: [i386:
- Mach-O executable i386] [ppc_7400:
- Mach-O executable ppc_7400]

There it is in black and white: the 2016-era binary is an ancient fat file containing a 32-bit i386 slice and a PowerPC slice. There is no 64-bit code anywhere in it. Rosetta 2 cannot help, and no amount of channel juggling will change what is inside that package. This is a dead end on Apple Silicon.

The right fix: native arm64 vina from conda-forge

The maintained package is simply vina on conda-forge (version 1.2.7). It has a native osx-arm64 build and includes the CLI and the Python bindings. Tear down the broken env and make a clean one:

conda remove -n bu-vina --all
conda create -n bu-vina --override-channels -c conda-forge python=3.11 vina=1.2.7
conda activate bu-vina

Pinning vina=1.2.7 and python=3.11 keeps the environment reproducible; drop the pins if you just want the newest available. Because this is a genuine arm64 build, there is no CONDA_SUBDIR override and no Rosetta anywhere in this command.

Apple Silicon / architecture note

This is worth stating plainly so you never get bitten again:

• conda-forge::vina 1.2.7 provides native builds for osx-arm64, osx-64, linux-64, and more. Install natively on any M1/M2/M3/M4 Mac. Use this.
• bioconda::autodock-vina 1.1.2 provides only linux-64 and osx-64, and the macOS binary is 32-bit i386/ppc that cannot run on Apple Silicon even under Rosetta. Avoid on arm64.

For essentially every user, the conda-forge 1.2.7 package is the correct choice. The only reason to touch the legacy bioconda build is if some downstream script depends on the exact 1.1.2 CLI behavior, and even then you would need an Intel Mac or a Linux box to run it.

Verify the install

Confirm what conda placed in the env, then run the tool itself:

conda list -n bu-vina vina
vina --version

The version check returns:

AutoDock Vina v1.2.7

That single line is the whole payoff: a real, native binary reporting its version instead of Bad CPU type in executable. Explore the interface next:

vina --help
vina_split --help

Python bindings smoke test

The conda-forge package also installs the vina Python module. A quick engine-load test exercises the real compiled code without needing any receptor or ligand files:

from vina import Vina
v = Vina(sf_name="vina")
print("Vina engine + scoring function loaded OK")

A real docking run additionally needs a receptor .pdbqt, a ligand .pdbqt, and a search box. That workflow (preparing structures, defining the box, reading the scores) is covered in our companion guide, Molecular Docking with AutoDock Vina.

Common errors and fixes

Managing the environment

Update Vina later, or capture the env so a collaborator can rebuild it exactly:

# Update within the env (stays on conda-forge)
conda update -n bu-vina --override-channels -c conda-forge vina

# Export a reproducible environment file
conda env export -n bu-vina > vina-env.yml

# Remove the env entirely when you are done
conda remove -n bu-vina --all

The exported vina-env.yml records the exact package builds, so anyone on any supported architecture can recreate a matching environment with conda env create -f vina-env.yml.

Next steps

• Put Vina to work: Molecular Docking with AutoDock Vina: A Practical Guide walks through receptor and ligand prep, the search box, and reading binding affinities.
• Need to build or convert ligands from SMILES first? See our RDKit install guide and visualize your poses with PyMOL.