Read the discussion on HN. A full-thread summary is not available yet.
hashicorp
vagrant
Ruby2010–2026
hashicorp / vagrant
vagrant
Vagrant is a tool for building and distributing development environments.
54Distinct people
68Mentions
0Explicit recommenders
27.2KGitHub stars
What to know before exploring
What it is
Vagrant is a tool for building and distributing development environments.
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 8:27:21 AM UTC.
Mentions over time
HN mentions by year68 dated mentions
Observed mentions: 2010-03-08 20:07:21 UTC to 2026-09-08 09:04:35 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2010 | 2010-01-01 00:00:00 UTC | 2011-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2011 | 2011-01-01 00:00:00 UTC | 2012-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2012 | 2012-01-01 00:00:00 UTC | 2013-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2013 | 2013-01-01 00:00:00 UTC | 2014-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 8 | 0 | 8 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 8 | 3 | 5 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 5 | 1 | 4 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 10 | 2 | 8 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 2 | 2 | 0 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 5 | 1 | 4 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 3 | 2 | 1 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 9 | 1 | 8 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 1 | 0 | 1 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
Vagrant
ImportantHCP Vagrant is in the process of being deprecated and limited features will be available from the community edition effective November 2, 2026. Click here for more information.
This change is only for HCP Vagrant and does not apply to Vagrant CLI.
Website: https://www.vagrantup.com/
Source: https://github.com/hashicorp/vagrant
HashiCorp Discuss: https://discuss.hashicorp.com/c/vagrant/24
Vagrant is a tool for building and distributing development environments.
Development environments managed by Vagrant can run on local virtualized
platforms such as VirtualBox or VMware, in the cloud via AWS or OpenStack,
or in containers such as with Docker or raw LXC.
Vagrant provides the framework and configuration format to create and
manage complete portable development environments. These development
environments can live on your computer or in the cloud, and are portable
between Windows, Mac OS X, and Linux.
Quick Start
Package dependencies: Vagrant requires bsdtar and curl to be available on
your system PATH to run successfully.
For the quick-start, we'll bring up a development machine on
VirtualBox because it is free and works
on all major platforms. Vagrant can, however, work with almost any
system such as OpenStack, VMware, Docker, etc.
First, make sure your development machine has
VirtualBox
installed. After this,
download and install the appropriate Vagrant package for your OS.
To build your first virtual environment:
vagrant init hashicorp/bionic64
vagrant up
Note: The above vagrant up command will also trigger Vagrant to download the
bionic64 box via the specified URL. Vagrant only does this if it detects that
the box doesn't already exist on your system.
Getting Started Guide
To learn how to build a fully functional development environment, follow the
getting started guide.
Installing from Source
If you want the bleeding edge version of Vagrant, we try to keep main pretty stable
and you're welcome to give it a shot. Please review the installation page here.
Contributing to Vagrant
Please take time to read the HashiCorp Community Guidelines and the Vagrant Contributing Guide.
Then you're good to go!
Read the full README on GitHubWhat Hacker News says
10 sourcesA couple more for the list:
11. Shared folders get setup before provision scripts are run
12. You can detect provision has already run (https://github.com/hashicorp/vagrant/issues/936#issuecomment...) using:
if File.exist?(".vagrant/machines/YOUR_BOX_ID/virtualbox/action_provision")
13. Vagrantfile configs are actually Ruby scripts, so you could do things like storing your box configs in JSON (like I did in https://github.com/wildpeaks/boilerplate-vagrant-xenial64 ) instead of hardcoding them in the Vagrantfile.
14. Virtualbox needs Hyper-V disabled whereas Docker for Windows requires Hyper-V enabled.
In Things I Wish I'd Known Before Using VagrantFYI this will break the current version of Vagrant if you use the VirtualBox provider (which is default): https://github.com/hashicorp/vagrant/issues/9080
In Oracle VM VirtualBox 5.2 Is Now AvailableThe repo has updates from just a few days ago, and IIRC, v2 just came out at the beginning of last month.
So I'd say no to "Is it dead?" Is it dated? Well I stopped using it once I found Docker (years ago), but can't say much for others. I'd be using it if I targeted other hosting platforms than Linux.
https://github.com/hashicorp/vagrant
In Ask HN: Is Vagrant dead or dated? Do people still use it?One of my guys ran into https://github.com/hashicorp/vagrant/issues/8788 - it was hellish trying to figure out what was happening.
In MacOS High SierraIn the change log, I’m happy to see “improved the resilience of some Virtualbox commands.” At Airbnb, we used to use Vagrant with Virtualbox and the Chef provisioner to create our dev environments, but we migrated totally away from Vagrant after struggling with Virtualbox bugs, and strangeness with Vagrant’s internal state and locking.
Seems like this issue is finally addressed: https://github.com/mitchellh/vagrant/issues/8468
Vagrant is a fantastic tool because of its flexibility, but that flexibility comes at cost: there are sometimes bugs and performance issues where the different Vagrant components don’t quite mesh perfectly.
In Vagrant 2.0Just from the version number I thought there'd be a few major changes, but really it just seems like another point release that happens to increment the major version number. (Which is totally fine by me. I rely on Vagrant a lot and I'm glad the new version doesn't introduce breaking changes). Change log is here: https://github.com/mitchellh/vagrant/blob/v2.0.0/CHANGELOG.m...
In Vagrant 2.0Any discussion about this should be anchored with an answer to the questions I asked earlier: What functionality do you think systemd should not have that it has today? What is a better way of achieving the benefits provided by that functionality?
Let's talk about logging. The systemd journal is designed to capture and log the output of all programs. Some programs do not integrate with syslog: they write to stdout/stderr instead. As a system administrator, I desire a way to capture the logs of everything I run on a system, including programs that do not integrate with syslog (e.g., ad hoc shell scripts and applications).
Who is in the best position to capture program stdout/stderr? The process supervisor. Systemd does that with its journal facility, and other supervisors work similarly. Personally, I value having a uniform method for capt
Read the rest
uring program logs from all processes on a machine, and that's what systemd offers me. Syslog by itself does not achieve this goal.
How do you recommend capturing and logging program output, if not by having the supervisor do it? (And why is that approach preferable?)
The journal is an integrated part of the systemd toolkit, and that's a good thing because it enables useful capabilities like capturing stdout and good user experiences like `systemctl status`. But you don't have to interact with it. If you prefer the syslog toolchain instead, then redirect the journal to syslog via ForwardToSyslog=yes in journald.conf. The journal still adds value with this approach because it captures logs that syslog can't (and without kludges like `logrotate` and `logger`).
You can see more log lines with e.g. `systemctl status -n50`. If you want to see everything, invoke `journalctl -u service-name`.
I view the systemd journal as a logging facade, a complement to facilities like syslog, not an alternative to it. As Russ said in my quote above, "systemd is agnostic to the underlying syslog implementation."
I'm not sure I grasp your point about dbus. I have not seen anyone make the argument that dbus should be part of a zombie reaper or process supervisor. However, IPC is a useful and sensible way for processes on the system to communicate with their process supervisor, which is why both systemd and upstart integrate with dbus. I've read that it is possible to use systemd without dbus [1] (there are apparently Debian configurations that work this way), though I haven't deeply looked into it.
If you want to launch supervised processes with clean environments, namespaces, and cgroups, then it is necessary for a system process to be the one that forks. Communicating that request between processes necessitates IPC. As the most widely adopted IPC system for Linux, dbus was an appropriate choice for systemd and upstart to integrate with. Again, going back to our anchors: Is there another IPC framework you think systemd should have integrated with instead? Or if not by using IPC, how do you think service management commands (e.g., restart a service) should be communicated to the system?
[1] E.g. https://github.com/mitchellh/vagrant/issues/7973 https://github.com/aelsabbahy/goss/issues/101
Vagrant Adds Support for Windows Subsystem for Linux
2 points · Open discussion- FLAVOR: [Ubuntu Server, Ubuntu Cloud]
- HEADLINE: Follow standards and respond to bug requests.
- DESCRIPTION: The cloud team is responsible for making machines available to cloud users, including making vagrant boxes. The problem is this team refuses to follow standards. For example, vagrant boxes should have the main user named "vagrant" but instead forces the user to be named "ubuntu"- and there's been a ticket open about this that's been open for a year now[1]. There have also been network bugs[2] that have been ignored for almost as long.
This is a big deal for people who use vagrant for testing. We essentially can't use the Canonical provided boxes, and this issue having been ignored for so long is not confidence inspiring.
1. https://bugs.launchpad.net/cloud-images/+bug/1569237
2. https://github.com/mitchellh/vagrant/issues/7288
In Ask HN: What do you want to see in Ubuntu 17.10?