Varying Vagrant Vagrants logo Varying Vagrant Vagrants

Subscribe with RSS to keep up with the latest changes.

Varying Vagrant Vagrants 2.2.1

May 22, 2018

Hi! Welcome to the release post for Varying Vagrant Vagrants 2.2.1. For help updating, see the documentation on keeping VVV up to date.

Here’s what’s happening…

Vagrant Triggers and Vagrant 2.1

VVV now requires Vagrant 2.1 to run. The Vagrant triggers plugin is also no longer required, as it was merged into Vagrant 2.1.

This does mean that users with the triggers plugin installed will get a warning when using vagrant commands. Read the warning for a parameter that can be added to silence the warning if you still need vagrant triggers for pre-2.1 vagrant environments. Otherwise, uninstall vagrant triggers with the following command:

vagrant plugin uninstall vagrant-triggers

PHP 7.2

VVV now uses PHP 7.2 by default. See here on how to change a sites PHP version.


Testing with https is an important part of development, so we’ve added a new TLS-CA utility, that comes with new installs by default. This installs a certificate authority just for your machine, letting you test https:// addresses locally.

To use this, add the utility, and reprovision. Then, you need to tell your OS or browser to accept the root certificate for the authority. This tells your computer to trust any certificates it generates, without which you’ll get a warning when visiting sites. This can be found in your VVV folder under certificates/ca/ca.crt.

For more information, see our docs here

Custom Site Template Develop and Deprecations

The wordpress-develop repository has been deprecated! This old site template was hardcoded to a single URL, and had other issues. It’s replaced by custom-site-template-develop, which allows for multiple WP core development environments.

Additionally, the src. subdomain is going away due to changes in the WP core development process.


Logs are now in the /var/logs folder, which is mounted on to the logs folder in your install. In particular, the default Nginx log, and the MariaDB logs are now in /var/logs


Is now a separate git repo! And updates independently of VVV on vagrant provision. You can also override the dashboard in vvv-custom.yml via the dashboard options:

  repo: ....
  branch; ...

Project Notes

We’ve added a new contributor team for testers and reviewers, Benjamin Lu and Daniele Scasciafratte. They’ve been very helpful in issues and testing changes. We’ve also added Tom J Nowell as a lead developer.

Varying Vagrant Vagrants 2.1.0

November 08, 2017

Hi! Welcome to the release post for Varying Vagrant Vagrants 2.1.0. For help updating, see the documentation on keeping VVV up to date.

Here’s what’s happening…

A new TLD for default sites

The .test TLD is now used for all default VVV sites instead of .dev.

You may have noticed back in September that Google added their .dev TLD to the HTTPS preload list in Google Chrome. This means that in recent versions of Chrome .dev domains are forced to use HTTPS.

Up until this point, VVV relied heavily on the .dev TLD and moving to a TLD that isn’t owned by anyone is a pretty obvious move. After quite a bit of discussion, we determined that .test was the best of the options laid out in RFC2606.

Because we can’t detect all customizations made to default sites, automatically updating everything isn’t an option. Default sites like will still work at their current URLs and will require a bit of manual effort to move over to src.wordpress-develop.test.

With WP-CLI, it’s pretty straight forward:

  • vagrant ssh
  • cd /srv/www/wordpress-develop/public_html
  • wp search-replace '.dev' '.test' --recurse-objects --network

On new provisions of VVV, this will all be setup automatically. On your own custom sites, you’ll need to adjust accordingly. Embrace the .test domain!

Update: We’ve added more extensive instructions for migrating from .dev to .test here

Thanks to Gary for warning us about this 2.5 years ago. :)

Better and better documentation

Many updates to VVV’s documentation on were made between the release of 2.0.0 and now.

The process to contributing to documentation has changed to use the repository. This clears the workflow for shipping documentation changes to proceed separately from shipping VVV releases.

There has also been a great improvement in the quality and presentation of the documentation. Things look great, are navigable, and you can search!

As a bonus, check out all the excellent work that’s been done on the VVV dashboard at your local http://vvv.test site.

A screenshot of the new dashboard used in VVV 2.1.0

And more

A full changelog is up that has all of the details for this release. We fixed MailCatcher, made some tweaks to how PHPCS is installed and its configuration, and applied some small adjustments to the VM configuration.

Project notes

Wayyyyyy back in April, we added Tom J Nowell as a VVV committer and he’s been doing a fantastic job of staying on top of things. He’s been a prolific contributor this year, much of the current state of our documentation structure is due to his work, and he made our excellent logo!

Future thoughts

There’s always a lot to think about for the future of VVV, but I’ll note a couple things that are coming up:

  • At some point we’ll want to move to the latest Ubuntu LTS release. This will be a breaking change and require a 3.x.x.
  • We may also take this opportunity to refactor how provisioning is done and instead provide our own base box.
  • Have more ideas? Come on over and participate!

That’s all for 2.1.0. A big thank you to every one of our contributors and thank you for using VVV!

Varying Vagrant Vagrants 2.0.0

March 13, 2017

Hi! Welcome to the release post for Varying Vagrant Vagrants 2.0.0.

A new method for configuring VVV

One of the things that’s been on the VVV wish list for a long time is support for a YAML configuration file. So much gets provisioned by default, it’d be nice to have a bit more control over that.

VVV 2.0.0 introduces a YAML configuration for VVV. A vvv-config.yml file is provided with defaults. This can be copied to a vvv-custom.yml file that lets you adjust VVV to fit your needs.

Part of this feature includes making the default provisioning a bit more module. Pieces have been broken out into a handful of repositories:

  • A new VVV utilities repository controls the utilities installed by default. It’s now possible to manage this list and even add to it with your own utilities repo.
  • A VVV WordPress Develop repository is used to make contributing to WordPress easier.
  • A VVV WordPress Default repository gives you the latest version of WordPress.

A really exciting part of the new configuration is how easy it is to add a site to your configuration. It’s now possible to choose PHP 5.6, 7.0, or 7.1 for your project and the new VVV Custom Site Template repository makes things even easier by providing a flexible base for new projects.

A big thanks to Lorelei Aurora for leading this feature. It’s hard to describe how excellent this improvement is.

The initial documentation for all of this is available, and we’ll continue improving on it over the next few weeks. Please note that this is considered a breaking change, hence the version bump to 2.0.0. More detailed guidance on these changes can be found in the changelog.

A new home for documentation

Part of the process for introducing the new YAML configuration was introducing documentation for it as well. Thanks primarily to Tom J Nowell, the documentation available for VVV has improved significantly in this release.

Docs are included as part of the repository and built into their final form at

Over the next few months, documentation will continue to improve as content is migrated from the wiki on GitHub to the new site. A big item on the roadmap is introducing a translation workflow so that documentation can be available in any language.

And much more

A full changelog is up that has all of the details for this release. Take note of the upgrade from MySQL 5.5 to MariaDB 10.1, the inclusion of the php-memcached package for better object cache support, and the change in how WP-CLI is installed and updated.

Project notes

An important housekeeping item for this release is the introduction of a governance document. This helps explain how the VVV project is managed and what the various roles and responsibilities are.

And finally, as mentioned earlier in the post, Lorelei Aurora stepped in and did great work leading the implementation of the new configuration in this release. She’s following this up with work on the future documentation and translation workflows. I’m excited to formally announce her role as a lead developer for VVV!

That’s all for 2.0.0. Thanks so much to all of our contributors and thank you for using VVV!

Varying Vagrant Vagrants 1.4.0

November 02, 2016

Hi! Welcome to the release post for Varying Vagrant Vagrants 1.4.0.

This release is packed with quite a bit of housekeeping. Let’s get that out of the way and then do a preview of what’s lined up for the future. You can also checkout the full changelog for more details.

First, VVV is now provisioned with PHP 7.0. PHP is on it’s 12th maintenance release after the initial stable 7.0, so there’s not much reason to keep waiting. This is a great way to test your code to make sure it is PHP 7 compatible.

NodeJS and NPM are a lot more organized and are positioned in a way to help clarify how we handle things in the future. First, we’ve decided to provide the latest LTS release of NodeJS. At this time, that’s 6.9.x, so that’s what VVV ships with. However, NVM is also installed during provisioning. This provides developers an easy way to switch between versions of NodeJS to work with the varying requirements of different libraries.

The “old” WordPress trunk repository,, is no longer checked out during initial provisioning. VVV was created before WordPress switched to as the canonical source for development, so we’ve maintained that link throughout. At this point, it’s likely more confusing than anything else and adds more time to the provisioning process. If you have a current installation of VVV and make use of the wordpress-trunk directory, you’ll want to manage updates manually with svn up.

Those are the highlights. Much more detail exists in the CHANGELOG.

How about the future?


If I was going to phrase up the next year of VVV, I would say: Slow and steady with more minor releases.

I wrote the above in the VVV 1.3.0 release post back in February. It looks like about half was right—it was slow and steady, but there were no minor releases.

An ideal release schedule still looks to me like once a quarter, so I’m going to try and make that happen in 2017. Let’s target January 9th and April 10th for the next releases and see what happens.


In August, the site was converted to use Jekyll instead of WordPress. This felt slightly strange, because I love WordPress, but it does provide an easily managed GitHub based workflow to our documentation. Over the next year I’d like to see much more organized documentation via the VVV docs repository. Contributions to that are very much more than welcome!

New features

There are a few exciting tickets open right now that should shape VVV into something pretty cool. If all goes well in the next year, we should see the ability to switch PHP versions using PHPBrew, switch MySQL versions with MySQL Sandbox, and have much more control over the sites included with VVV by splitting them out into their own repositories.

That’s everything for 1.4.0. Thanks so much to all of our contributors and thank you for using VVV!

Varying Vagrant Vagrants 1.3.0

February 21, 2016


It’s time for another official release. VVV 1.3.0 has been tested and tagged and is waiting for you to grab it up. To read about all of the great things that make up this release, head over to the full changelog on GitHub.

A handful of highlights

Support for several new providers has been added. While VirtualBox is the most widely supported, we now account for Parallels, VMWare Fusion, VMWare Workstation, and Hyper-V in the default Vagrantfile. This is especially useful if you’re already using one of those to manage other virtual machines.

MailCatcher is now included as part of provisioning. An inbox view is available at to show you all of the mail sent by the virtual machine. This has been super helpful in troubleshooting issues with emails sent by core and plugins.

The WordPress core SVN repositories are now set to HTTPS. If these directories were originally provisioned as part of an old VVV configuration, it’s possible that things like svn up will show an error. You can use the svn relocate command to change the repository to the HTTPS URL. See issue 561 for more information. We’ll have a proper FAQ up to handle this at some point.

What's next?

If I was going to phrase up the next year of VVV, I would say: Slow and steady with more minor releases.

A tough thing about marking version numbers on a project like VVV is that all of the various versions of included packages change frequently. We need to do a better job of making it easier to maintain existing packages. I’d like to encourage more people to use the develop branch on GitHub and at the same time release more incremental versions. I’m going to start planning on a release every 3 months. We’ll see how that works and take it from there.

Major things I'd like to see

Update packages on vagrant provision, rather than only installing the first time. This should make vagrant provision a more common part of your daily workflow, used to keep things like PHP, Nginx, and MySQL updated.

Make it easy to remove default configurations. I think the Variable VVV project is an excellent way to add projects to VVV. We need a nice and simple way to turn off the default WordPress local, trunk, and dev environments provided by VVV.

Improved documentation. I’d like to follow the example of projects like WP-CLI, which has excellent documentation available in a nice, browsable format. Our GitHub wiki has a bunch of great information, but we can do better.

And be ready for...

A PHP upgrade. We’re sadly still on PHP 5.5.x and we should at least be on PHP 5.6.x if not PHP 7. Please leave feedback on issue #834 if you have a preference.

A switch in default domain names. Our pattern is quickly looking like it will cause more issues with name collisions. Pay attention to issue #583 as we’ll use that to switch to domain.test or domain.localhost instead.

And that’s it. Thanks to all of our amazing contributors and thanks to everyone for using VVV!

Varying Vagrant Vagrants 1.2.0

December 15, 2014

Well hello. We’re finally here.

After a long 9 months of waiting, it’s a happy moment to push a tagged 1.2.0 release of Varying Vagrant Vagrants.

A full list of changes is available in the changelog. Here are some important ones.

First, VVV is now MIT Licensed. This is a big deal and we waited entirely too long as an open source project before choosing one. In fact, you could say we weren’t really an open source project at all until that point. Many many thanks to the near 50 contributors who were there to confirm their previous contributions as MIT so that we could proceed.

If there’s any lesson I learned from this, it’s to start with a license before anything else.

Ok, next. In new instances of VVV 1.2.0, database files are no longer mapped to a persistent local location. The database is entirely contained inside the virtual machine. What does this mean?

  • A full vagrant destroy and the removal of MySQL data from {vvv-dir}/database/data/ is recommended. While not necessary, this will keep a clean workflow in the future.
  • If database files already exist from an earlier version of VVV, data will continue to be mapped locally until removed. This is our attempt at backward compatibility. Anybody currently running VVV 1.1 may not even notice the change.
  • Even when not persistent locally, database data will continue to exist on the virtual machine through vagrant halt and vagrant suspend. This is the same behavior as a production server. You can restart the machine and the data remains.
  • Database data will no longer exist on the virtual machine after vagrant destroy. This is the same as reformatting a production server. At this point, the intention should be to start fresh or to restore from a backup.
  • A db_backup script is provided by default that creates local backups of each database on halt, suspend, and destroy if the vagrant-triggers plugin is installed. This is the current workflow, though we'll be taking steps to reduce the number of backups created in the future as well.

Somewhat more impactful is the change in operating system from Ubunto 12.04 LTS 32bit to 14.04 LTS 64bit. To upgrade from 1.1 to 1.2.0, a full vagrant destroy is likely necessary for best results. As mentioned above, your database data will be remain as it only becomes non-persistent on new instances of VVV and by choice on upgrade.

  • A new box will be downloaded for the base virtual machine. If you'd like to free space on your local machine, remove the old box with vagrant box remove precise32. Running vagrant box list will show you all base VMs on your local machine.
  • With a new operating system comes a new RSA key. If you are connecting via SSH through an application that relies on your machines known_hosts file, you will need to clear the old key for See #365
  • I ran through the process of a 1.1 to 1.2.0 upgrade and left notes in this comment.

And other changes of note:

  • develop_git script is available inside the virtual machine to convert the default SVN WordPress checkouts to Git. With core accepting patches via pull request in the near future, this may be useful to some.
  • We're now tracking Nginx mainline, so expect that to be at the most current version during any provision.

And now the future! We have plenty of open issues and many goals to keep us busy, and I’m always interested in hearing new ideas for how VVV can best be used. Here’s what’s on the front burner.

  • Allow the selection of which sites to make active by default (See #474, #313, #210). It's great that we provide a handful of different WordPress instances by default, but it would sure be nice to disable the ones you don't use or to enable others you'd like to use. It would be really nice to separate some of the default configurations out into their own init scripts, similar to what Christian Foellmann has been working on in the new VVV multisite repository. This will also help out with projects like the WordPress Meta Environment, which really don't need the default sites at all.
  • And in the process of doing the above, provide some sort of configuration file. YAML seems easy, but eyes and ears are wide open for the best approach on this.
  • Now that we've worked out a license, we should work out what versioning really means to us. I would happily move to semantic versioning—hinted at with this release number—though it would be nice to cover thoughts on that. It would also be nice to work out a proper release schedule, so that we aren't all waiting 9 months for the next one. :)

That’s it, go get VVV 1.2.0 and have some fun. Thank you so much to the many, many contributors that have made VVV what it is today. And stop in with any questions, all are welcome!