Micromamba¶
- ID
micromamba- Links
- Upstream stars
⭐ 8,100
- Last commit
2026-09-25
- Version requirement
>= 2
- Platforms
🐧 Linux · 🍎 macOS · 🪟 Windows
- Operations
installed·outdated·search·install·upgrade·upgrade_all·remove·cleanup- purl types
pkg:conda/·pkg:micromamba/- CLI name
micromamba- Issues and PRs
- Source
mamba’s statically linked build, shipped as a single self-contained binary.
The same program as mamba, built the other way: upstream’s
build declares “mamba is a dynamic build of micromamba” and compiles both
executables from one source list. Every operation, parser and forced
argument is therefore inherited unchanged.
Note
The two are separate managers rather than one manager naming both binaries,
because they resolve different root prefixes: mamba takes the conda
installation it ships inside, while micromamba takes ~/micromamba or
its XDG data directory. mpm resolves a manager to the first of its CLI
names found while walking the search path, so a host carrying both would
silently report whichever came first on PATH and hide the other’s
packages entirely.
Note
Their command sets differ by exactly one entry: micromamba adds
self-update, which the dynamic build rejects. It maps to no mpm
operation, so nothing here uses it.
What mpm adds to micromamba¶
Through mpm, micromamba gains --extended search, to match against package descriptions.
Bigger still, mpm reaches across every manager at once: mpm installed and mpm outdated cover micromamba alongside conda, mamba, pixi and any other manager you run in one table, mpm upgrade --all updates them together, and mpm sbom exports the whole machine as one bill of materials.
Every mpm command also gains --dry-run and --plan previews, cross-scheme version comparison and purl identifiers. See manager augmentations for how each one is built.
Your micromamba commands, in mpm¶
You already know micromamba: each operation maps one-to-one onto mpm, in an interface shared by every manager.
To… |
With |
With |
|---|---|---|
List what’s installed |
|
|
List outdated packages |
|
|
Search for a package |
|
|
Install a package |
|
|
Upgrade one package |
|
|
Upgrade everything |
|
|
Remove a package |
|
|
Clear caches |
|
|
Prefix any command above with --dry-run to simulate the underlying manager calls without touching the system: the safe way to watch what mpm would do before trusting it.
Operations¶
Operation |
Supported |
Notes |
|---|---|---|
|
✅ |
|
|
✅ |
|
|
||
|
✅ |
Extended search backfilled by |
|
✅ |
|
|
✅ |
|
|
✅ |
|
|
✅ |
|
|
❌ |
Nothing in the command set refreshes the index on its own; the conda wrapper implements none either, so this is parity rather than a gap. |
|
✅ |
|
|
Configuration¶
Ignore
micromambaon thempmCLI by passing the--no-micromambaoption.Ignore it for every run in your configuration:
[mpm] micromamba = false
Raise the timeout of all
micromambacalls:[mpm.overrides.micromamba] timeout = 900
Run
mpm config-template micromambato print all overridable settings for your configuration file:[mpm.overrides.micromamba] cli_names = [ "micromamba", ] cli_search_path = [] dry_run = false ignore_auto_updates = true plan = false post_args = [] pre_args = [] pre_cmds = [] requirement = ">=2.0.0" stop_on_error = false unmaintained = false version_cli_options = [ "--version", ] version_regexes = [ "^(?P<version>\\d+\\.\\d+\\.\\d+\\S*)$", ]
Recipes¶
A few jobs you would otherwise script around micromamba, one mpm command each:
Snapshot and clone a machine:
mpm --micromamba dump micromamba.toml, thenmpm restore micromamba.tomlon the next one.Export a compliance SBOM:
mpm --micromamba sbom(CycloneDX by default,--spdxfor SPDX).
Privilege escalation¶
mpm runs this manager as the current user and never prepends sudo by default. Flip the policy for its privileged operations with --sudo or the per-manager sudo override.
None of its operations is privileged.
See privilege escalation for the full policy.
Concurrency¶
mpm never runs micromamba at the same time as conda or mamba: they act on one environment prefix and one package cache, and conda honors none of the locks mamba takes on them. Each mutating operation waits for the previous one, even with a higher --jobs, while managers outside this group keep running in parallel.
Only mutations are held back. The read-only queries (installed, outdated, search) take no backend lock and stay fully concurrent.
Cooldown¶
State of Micromamba’s release-age gating, from the cooldown support table:
Status: ❌ Same as mamba (inherits)
A cooldown only pays off where a compromised release can be withdrawn while the clock runs, and can only be emulated where the registry dates its releases. From the retraction table:
Registry: anaconda.org / conda-forge (
pkg:conda)Retraction: Relabel: “we do not allow edits or the deletion of packages on conda-forge” (immutability); a bad artifact is labelled broken and “Users will no longer be able to install them by default” (procedure)
Publish date: ✅
upload_time, with thebrokenlabel carried inlabels(API)
With --cooldown set, mpm skips this manager’s install and upgrade operations rather than run them unguarded (fail-closed); --cooldown best-effort opts back in.
Version check¶
The version is extracted from the output of micromamba --version with:
r"^(?P<version>\d+\.\d+\.\d+\S*)$"
Upstream project¶
Metrics |
|
|---|---|
Activity |
|
Popularity |
|
Metadata |
|
Changelog¶
8.0.0(2026-09-20)Resolve
pkg:alpm,pkg:conda,pkg:deb,pkg:melpa,pkg:pypiandpkg:rpmpURLs to these managers too, alongside the ones already handling each type.Add
mambaandmicromamba, reading the inventory fromlist --jsonand synthesizingoutdatedfrom the dry-run transaction the way thecondawrapper does. Search matches package names exactly.Stop running
conda,mambaandmicromambaconcurrently: they act on one environment prefix and one package cache.Record that each tool’s shipped release-age gate never reaches the commands
mpmdrives, in place of a pending upstream proposal.