What are the drawbacks of Vagrant?

Vagrant's drawbacks, heavier resource use than containers, slower startup, and more setup work for multi-VM projects, are real but rarely enough on their own to rule it out. What has changed more is momentum: HashiCorp's development attention has shifted toward its other infrastructure tools, and Vagrant's release cadence has slowed as Docker and Dev Containers became the default way most teams build reproducible dev environments.

When do these drawbacks matter less?

VM overhead stops being a real cost when the project already needs a full VM, for kernel-level testing, multi-machine network simulation, or matching an on-prem OS that a container can't reproduce exactly. On a single capable dev machine, or when only one or two VMs run at a time, the extra CPU and RAM use is usually tolerable. A team with a working Vagrantfile and no active pain point has little reason to migrate it just because newer tooling exists.

When do they matter more?

The cost adds up on shared CI runners, older laptops, or projects where many contributors spin up environments in parallel, since each VM's boot time and memory footprint multiply across the team. It also matters more for teams that want editor-native tooling or container-based CI pipelines, where Docker or Dev Containers fit more directly, and for any new project with no existing Vagrant setup to protect.

What's the practical takeaway?

A working Vagrant setup doesn't need to be replaced just because the tooling around it has moved on, but a brand-new project has less reason to start with it today than it would have a few years ago. Most teams still maintaining Vagrant are adapting pieces of it toward Docker Compose or Dev Containers rather than expanding it further.