mamba: a C++ reimplementation of the conda package manager, and when micromamba fits better

What mamba replaces inside a conda workflow

mamba is not a new package format or a new channel ecosystem. It is a reimplementation of the conda package manager in C++, and the README is explicit that it uses the same command line parser, package installation and deinstallation code, and transaction verification routines as conda. The substitution happens in two places: fetching repository data and package files, and resolving the dependency graph. The first is multi-threaded; the second is delegated to libsolv, which the README describes as a state of the art solver used by the RPM package manager of Red Hat, Fedora and OpenSUSE.

The intended audience is anyone who already lives in conda environments and has felt the solver pause. Because the CLI surface is shared, the migration cost is close to zero for ordinary commands: the argument parsing is conda's. The project is part of the conda-forge ecosystem, alongside quetz, a conda package server. If your team maintains environments with hundreds of pinned packages, the solver swap is the part that matters; if your environments are small, the parallel download is the part you will notice.

The two binaries: mamba and micromamba

The repository ships two front ends with different deployment shapes. mamba links against libmamba and is meant to sit in an environment where other software also uses libmamba or libmambapy. micromamba is the statically linked build, distributed as a standalone executable with no dependencies, which the README positions for CI/CD pipelines and containerized environments.

The README gives explicit selection criteria rather than leaving it to taste. Prefer mamba when libmambapy or libmamba is used by other software in the same environment, when regular updates to libraries are required (the README calls out security in particular), and when the goal is reducing disk space usage for dependencies. Prefer micromamba when you need a single self-contained executable, when a miniforge distribution is not present, or when minimal runtime matters. That last pair is the real dividing line: mamba participates in a shared library world, micromamba refuses to.

The cost of micromamba's static linking is that you do not get library updates through the environment's package manager; you replace the binary. That is a deliberate trade, not an oversight, and it is the reason the two binaries coexist instead of one replacing the other.

Installing mamba and running a first solve

The README does not inline installation commands. It points to the mamba installation guide and the micromamba installation guide in the documentation at mamba.readthedocs.io. Follow those pages for your platform; the repository itself documents the developer environment separately.

Once a binary is on your PATH, the first useful check is a solve against a real channel. This is the example the README gives for installing a conda-lock lockfile with micromamba, and the constraint is that the lockfile name must end in -lock.yml or -lock.yaml:

micromamba create -n my-env -f conda-lock.yml

You should see micromamba resolve the locked dependency set and download the packages, without conda-lock itself being installed. The README states that micromamba can install lock files generated by conda-lock this way.

For CI, the README points at setup-micromamba, a replacement for setup-miniconda. It reports that micromamba takes around 1 s to install, and it caches both package downloads and entire conda environments. Those are the project's own numbers, not independent measurements.

Where mamba diverges from conda, and where it does not

The README states that mamba and micromamba are generally a drop-in replacement for conda, then names one concrete divergence: they normalize MatchSpec strings to the simplest form, while conda uses a more verbose form. The visible consequence is that conda env export and mamba env export can produce slightly different output.

That is a small sentence with an outsized operational meaning. Any tooling that parses exported environment files, diffs them in review, or stores them as artifacts is comparing two different textual representations. The packages may resolve identically while the YAML does not. If your workflow treats environment files as opaque inputs to conda, you will not care. If you diff them, you will.

Everything else in the shared surface is inherited, including its limits. mamba does not add a new solver policy, a new channel protocol or a new package format. It also does not remove conda's constraints; it makes the parts around them faster.

repoquery and the API stability position

Two features sit on top of stock conda. The first is repoquery: mamba repoquery and micromamba repoquery query repositories and package dependencies efficiently. The README sends readers to the repoquery documentation for details rather than describing the output, so treat the command as an entry point and read the docs for the query semantics.

The second is the stability policy, and this is where the project is unusually candid. Mamba follows semantic versioning, but the README says the maintainers are not aware of consumers of the C++ API, so they give themselves room for improvements. The guarantees are then spelled out per artifact. For libmamba, PATCH releases are API and ABI backward compatible; MINOR releases are API compatible only for declarations in mamba/api, and can break API elsewhere and ABI anywhere; MAJOR releases make no guarantees. For libmambapy, API backward compatibility holds as long as you did not use private declarations, such as names starting with an underscore.

If you are building against libmambapy, that policy is workable: pin to a MINOR line and re-test on upgrade. If you are building against libmamba and relying on declarations outside mamba/api, the README is telling you that a MINOR bump can require code changes. Plan for that rather than discovering it.

Alternatives and the difference in approach

The honest alternative is conda itself. mamba exists because conda is written in Python and uses its own solver; mamba keeps conda's interface and transaction logic but moves the solver to libsolv and the downloads to multiple threads. Choosing between them is not a choice between two packaging philosophies, it is a choice about where the time goes. If conda's solve and download times are acceptable in your environments, staying on conda removes the export-format divergence and the libmamba stability questions entirely.

There is a second comparison inside the project: mamba against micromamba. That one is about deployment topology rather than performance. mamba shares libraries with the rest of the environment and receives security updates through it. micromamba is one file, which is why the README recommends it for CI and containers, and why it is a poor fit when other software in the same environment expects libmamba or libmambapy to be present and updatable.

A third path is conda-lock, which appears in the README as the producer of the lock files micromamba can consume. That is not a competitor so much as a companion: conda-lock resolves and freezes, micromamba installs the result without needing conda-lock installed.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-21. The most recent release in the list is 2.9.0, published on 2026-08-07, preceded by two release candidates in the same cycle (2.9.0.rc0 on 2026-07-31 and 2.9.0.rc1 on 2026-08-05). That cadence, with candidates before the final tag, is what the release list shows.

The licence is BSD-3-Clause, stated in the repository metadata and carried in the LICENSE file at the top level. That is a permissive licence, but this is not legal advice; if you redistribute mamba inside a product, read the LICENSE text and your own obligations.

Upgrade cost depends on which artifact you consume. Users of the command line are shielded by the shared conda CLI. Users of libmamba should expect ABI breaks on MINOR releases and API breaks outside mamba/api, and users of libmambapy should expect compatibility to hold unless they touched underscore-prefixed names. The README notes that future versions may give stronger guarantees, which is a statement about intent, not a commitment you can pin a build to.

Editorial conclusion

Adopt mamba if you already run conda environments and want the same command line with libsolv solving and parallel downloads, and adopt micromamba if you need a single static executable for CI or containers. Do not adopt it expecting a different packaging model: it reuses conda's package installation and transaction verification code, so it inherits conda's constraints. Before rolling it out, verify that your environment does not depend on the verbose MatchSpec form in conda env export output, and check the libmamba and libmambapy stability guarantees against how tightly your code binds to them.

Frequently asked questions

Official sources

1. License: BSD-3-Clause
2. mamba-org/mamba on GitHub
3. Project website
4. README
5. Releases