Vagrant¶
Note
Upstream has slowed: the last stable release is 2.4.9 of August 2025, though the repository is still committed to. Note also that Vagrant is distributed under the Business Source License from 2.4.3 onwards, which some distributions treat as non-free.
- ID
vagrant- Home page
- Upstream stars
27,202
- Last release
2026-06-01
- Last commit
2026-08-03
- Version requirement
>= 2.4
- Platforms
🐧 Linux · 🍎 macOS · 🪟 Windows
- Operations
installed·outdated·search·install·upgrade·upgrade_all·remove·cleanup- purl types
pkg:vagrant- CLI name
vagrant- Forced environment
VAGRANT_CHECKPOINT_DISABLE=1- Issues and PRs
- Source
Vagrant’s box manager, covering the base images it fetches from its registry.
Vagrant orchestrates virtual machines, which is not package management. Two
of its subcommand trees are: vagrant box, covering versioned base images
pulled from a registry, and vagrant plugin, covering Vagrant’s own
extensions. Only one can be the inventory, and boxes are it. They carry the
whole operation set, where plugins offer neither an outdated nor a search
of any kind, and a plugin is a RubyGem installed into a private gem home
rather than something with a registry of its own.
A package is a box, identified by the bare name the listing prints, which
may be a registry name like ubuntu/jammy64, a purely local name, or a
full URL. The provider and the architecture are deliberately dropped from
the identifier.
Note
That last point is what makes this a class rather than a definition. Vagrant lists one row per (name, provider, version) triple, so a box installed in three versions appears three times, and the same is true of the outdated report. mpm keys a package on its id alone, so both listings are reduced here to one entry per name, keeping the newest version installed.
Caution
Every box command reads the registry under ~/.vagrant.d and needs no
Vagrantfile, with two exceptions that are avoided rather than handled:
vagrant box outdated inspects only the boxes the current directory’s
Vagrantfile declares unless --global is passed, and vagrant box update
is scoped the same way unless --box names one. Both forced flags are
therefore load-bearing: without them the answer would depend on where mpm
happened to be invoked, and would fail outright outside a Vagrant project.
One piece of ambient state cannot be escaped: Vagrant evaluates the
Vagrantfile’s trigger configuration on every subcommand, so a malformed
Vagrantfile in the working directory breaks even box list. Only the
version probe is immune.
Note
No upgrade --all: Vagrant has no command that updates every installed box,
box update addressing either one named box or the current project’s. mpm
backfills it from outdated plus the per-box upgrade instead.
No sync either, there being no command that refreshes box metadata without
also downloading, and the machine-readable output mode is unusable for
boxes: it emits four lines per box with an empty target column, so nothing
correlates them back into a record.
Documentation: Vagrant boxes.
What mpm adds to vagrant¶
Through mpm, vagrant gains:
a one-command
upgrade --allthat refreshes every outdated package in a single run--exactand--extendedsearch, to narrow to exact names or match descriptions
Bigger still, mpm reaches across every manager at once: mpm installed and mpm outdated cover vagrant alongside every 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 vagrant commands, in mpm¶
You already know vagrant: 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 |
|
|
Install a package |
|
|
Upgrade one package |
|
|
Upgrade everything |
— |
|
Remove a package |
|
|
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 |
|---|---|---|
|
✓ |
|
|
✓ |
|
|
||
|
✓ |
exact and extended search backfilled by |
|
✓ |
|
|
✓ |
|
|
✓ |
|
|
✓ |
|
|
||
|
✓ |
|
|
Selecting and configuring vagrant¶
Deselect vagrant for a single run with --no-vagrant, or persist the choice in your configuration:
[mpm]
vagrant = false
The arguments and environment variables listed in the box atop this page are forced on every vagrant call, so runs stay quiet, non-interactive and reproducible: the defaults you would set in CI anyway.
Keep it enabled but tune how mpm drives it with a per-manager override:
[mpm.managers.vagrant]
timeout = 900
mpm config-template vagrant prints every overridable attribute as a ready-to-paste block.
Recipes¶
A few jobs you would otherwise script around vagrant, one mpm command each:
Snapshot and clone a machine:
mpm --vagrant dump vagrant.toml, thenmpm restore vagrant.tomlon the next one.Export a compliance SBOM:
mpm --vagrant 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.
See privilege escalation for the full policy.
Cooldown¶
State of Vagrant’s release-age gating, from the cooldown support table:
Status: ❌ None
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: Vagrant Cloud boxes
Retraction: Author deletion: a box version is published by its own author to the public registry and can be withdrawn there, the version disappearing from the metadata Vagrant reads while any copy already downloaded stays in the local box store
Publish date: ✅ the registry records a creation date per box version, though
mpmreads no release-age gate from it
With --cooldown set, mpm skips this manager’s install and upgrade operations rather than run them unguarded (fail-closed); --allow-unsupported-managers opts back in.
Version probe¶
The version is probed by running:
$ vagrant --version
Vagrant 2.4.9
and extracted with:
r"^Vagrant[ \t]+(?P<version>\S+)$"
Reference traces¶
Raw native outputs captured in the manager source: the reference mpm’s parsers were written against. If you know Vagrant well and a transcript below looks wrong, or a newer release changed its output format, report it.
$ vagrant box list
linuxmint-21.3-cinnamon-64bit (hyperv, 0)
mintv1 (hyperv, 0)
wolvverine/LinuxMintCinnamon (hyperv, 1.1, (amd64))
$ vagrant box outdated --global
* 'ubuntu/jammy64' for 'virtualbox' is outdated! Current: 20231012.0.0. Latest: 20240126.0.0
* 'ubuntu/jammy64' for 'virtualbox' is outdated! Current: 20230914.0.0. Latest: 20240126.0.0
* 'ubuntu/jammy64' for 'virtualbox' is outdated! Current: 20230616.0.0. Latest: 20240126.0.0
Feed any of these through mpm and the raw output becomes one uniform table, the same shape for every manager: filter it, project columns, or export it (mpm --vagrant installed --output json, or csv, toml, yaml), each package carrying a purl and a version comparable across managers.
Changelog¶
7.7.0.dev0(unreleased)Add Vagrant’s box manager with
installed,outdated,search,install,upgrade,removeandcleanupsupport. Boxes are the packages rather than plugins, which offer neither anoutdatednor a search. Both listings report one row per version and provider, so they are reduced to one package per box name.outdatedand the per-box upgrade force the flags that scope them to the machine, since both otherwise answer for the current directory’s Vagrantfile.