chef/bento: Packer templates for minimal Vagrant base boxes

What problem chef/bento solves, and for whom

Building a Vagrant base box by hand means installing an OS from an ISO, stripping it down, installing the VirtualBox or VMware guest additions, creating a vagrant user with the standard insecure keypair, and then packaging the result. Every one of those steps has to be repeated for each distribution and each architecture, and the result drifts the moment someone rebuilds it differently. Bento exists to make that repeatable. It encapsulates Packer templates for building Vagrant base boxes, and the README states that a subset of those templates are built and published to the bento org on Vagrant Cloud, where they serve as the default boxes for kitchen-vagrant.

The audience is narrow and specific. You need bento if you maintain Test Kitchen suites and want the base box to be a known quantity rather than whatever the cloud last published. You need it if you build for an architecture the published boxes do not cover. You do not need it if you just want a VM to poke at: the README's own quick path is to add a published box and move on. The templates cover a wide spread of targets, including Amazon Linux, CentOS, FreeBSD, macOS, Oracle, Red Hat, Ubuntu, Windows, and providers spanning VirtualBox, VMware Fusion, VMware Workstation, Parallels, UTM, qemu and Hyper-V.

How the template and variable split works

The repository separates the build definition from the target-specific values. Everything under packer_templates/ describes the build itself, and os_pkrvars/ holds one .pkrvars.hcl file per distribution, release and CPU architecture, such as os_pkrvars/debian/debian-13-x86_64.pkrvars.hcl or os_pkrvars/almalinux/almalinux-10-x86_64.pkrvars.hcl. That split is why a single command can target a different OS by swapping one argument. The variable file carries the ISO URL and the facts that differ between distributions; the template carries the provisioning logic that does not.

On top of Packer sits a Ruby gem with a bento executable. The build subcommand wraps packer build, and the list subcommand reports the builds available for the workstation's CPU architecture. That list is filtered by a do_not_build: section in builds.yml, with entries matched by regex, which is how the project keeps templates in the tree that are not built on a given machine. The README notes that specifying a template explicitly overrides that filter, so the exclusion list is a default, not a hard block. The build, test and upload subcommands form a pipeline: build writes boxes and a metadata file into builds/build_complete, test runs a test-kitchen configuration and sorts results into builds/testing_passed or builds/testing_failed, and upload reads each <box_name>._metadata.json file to generate the vagrant cloud publish command, taking descriptions, version, provider and checksums from that metadata. The metadata file is the thread that runs through the whole pipeline.

Installing bento and building your first box

The README gives the gem install path as a short sequence: set up a Ruby environment, clone the repository, change into it, build the gemspec, and install the resulting gem. Nothing is published to a public gem index in these instructions, so you are installing from the checkout you just built.

cd <path/to>/bento
gem build bento.gemspec
gem install bento-*.gem

After that, the README's example builds a Debian box from a variable file in os_pkrvars. Run it from the repository root: the README warns that the output directory is relative to the working directory of the command, and that running from the bento root places build working files under bento/builds/build_complete/(build_name) by default.

bento build os_pkrvars/debian/debian-13-x86_64.pkrvars.hcl

If you prefer to skip the gem entirely, the README also documents driving Packer directly. Two commands are needed, because the template directory has to be initialised before it can be built. This example restricts the build to the VirtualBox provider.

cd <path/to>/bento
packer init -upgrade ./packer_templates
packer build -only=virtualbox-iso.vm -var-file=os_pkrvars/ubuntu/ubuntu-24.04-x86_64.pkrvars.hcl ./packer_templates

On success the README says box files land in builds/build_complete at the repository root. Requirements are Packer 1.7.0 or later, Vagrant 2.4.0 or later, and at least one supported virtualization provider installed. Two caveats from the README are worth repeating before you start: Vagrant 2.4.0+ is required for the new CPU architecture support, and VirtualBox 7.1.6+ is required for arm64 support.

The provider support is not uniform, and the README says so

The requirements list flags qemu and Hyper-V with a footnote stating that support for these providers is considered experimental and that corresponding Vagrant Cloud images may or may not exist. That is an unusually direct admission, and it should shape how you read the rest of the provider list. VirtualBox, VMware Fusion, VMware Workstation and Parallels Desktop Pro are listed without that footnote; qemu and Hyper-V are not in the same category. If your target is Hyper-V on Windows, treat bento as a starting point you will have to debug, not a supported path.

Windows on KVM/qemu has an extra manual step that the README documents in its own section. You must download the virtio-win ISO and place it in builds/iso/ before the build will have the paravirtualized drivers it needs. The README gives the command to do this, which creates the directory and fetches the image into it. Miss that step and the Windows build has no driver source to install from.

There is also a scale limit worth naming. The README's default for the --only option lists parallels-iso.vm, virtualbox-iso.vm and vmware-iso.vm, which tells you what the maintainers expect a normal workstation to run. Building for every provider at once is possible, and the README shows a command that does it, but it means several hypervisors and several multi-gigabyte ISOs on one machine at the same time. The --single flag exists to disable parallel builds, which is the escape hatch when that concurrency is the problem.

Alternatives: packer directly, or a different box source

The most honest alternative is Packer without bento. The README documents that path itself, with packer init and packer build against ./packer_templates. The difference is what you give up: the Ruby wrapper's build, list, test and upload subcommands, the builds.yml filter that keeps unsuitable templates out of the default list, and the metadata file that carries version, provider and checksum data into the publish step. If you already have your own build orchestration and only want the HCL templates, driving Packer directly is fewer moving parts. If you want the pipeline, the gem is the point.

The other alternative is not building at all. Vagrant Cloud hosts published bento boxes, and the README's first example is a single command to add one. The trade-off is control. A published box is whatever the project last built and pushed, on the project's schedule, for the architectures it chose. Building locally gets you the ISO URL you picked (the README shows overriding iso_url with a -var flag for a mirror), the provider you actually run, and a box you can rebuild when a CVE lands rather than when someone else rebuilds it. That is the whole argument for the local build path, and it is also the reason the tool exists at all.

Maintenance, licensing and what a rebuild costs you

The repository is not archived, and the last push was on 2026-08-08. Releases are infrequent: v5.1.0 on 2026-06-08, v.5.0.1 on 2025-11-21, and v5.0.0 on 2025-10-27. That cadence fits the project's shape. Base box templates change when a distribution release changes, not on a weekly rhythm, so a quiet release history is not by itself a warning sign. What it does mean is that a new distribution release may sit unaddressed for a while, and you should check whether an os_pkrvars file exists for your target before assuming support.

Bento is licensed under Apache-2.0. The templates reference third-party ISO images and hypervisor guest additions that carry their own licences, and the macOS and Windows targets in particular involve vendor terms that Apache-2.0 says nothing about. That is a question for whoever handles licensing at your organisation, not something the repository answers.

The upgrade cost is mostly environmental rather than code. The README pins minimums: Packer 1.7.0, Vagrant 2.4.0, VirtualBox 7.1.6 for arm64. Moving past those floors can change what the templates produce, so a rebuild after a hypervisor upgrade is worth doing deliberately rather than incidentally. The rebuild itself is not cheap in wall-clock terms: it downloads a full ISO and installs an operating system. Budget for that per target and per architecture, and note that the README recommends running packer build from the bento root so the output lands in a predictable place.

Editorial conclusion

Adopt bento if you need to rebuild a Vagrant base box from a documented ISO URL on your own hardware and are willing to install Packer, Vagrant, Ruby and at least one hypervisor. Skip it if you only want to run an existing box: the README's own example, vagrant box add bento/ubuntu-18.04, is the shorter path. Before committing, verify which os_pkrvars file matches your target architecture and confirm the provider you intend to use is not marked experimental.

Frequently asked questions

Official sources

1. chef/bento on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases