Update 2023-01-25 This article is woefully outdated. Tom J Nowell, VVV project lead, has a great comment below which at this point is far more valuable than this article. The official documentation at VaryingVagrantVagrants.org is another great place to get started.
Update 2018-04-17 I am no longer using this setup for local development. Instead I am using Local by Flywheel, which I find to be a more polished experience.
I’ve made the jump from MAMP to Varying Vagrant Vagrants (VVV) on my Mac and I wanted to document the process. Specifically, I want to address the changes I made so I can load the websites from other machines on my network. I’ve got all the gory details below, you can see the modifications I made in:
- My VVV Customfile that augments the Vagrant file
Requirements
- Git
- VirtualBox
- Vagrant
- vagrant-hostsupdater – by running
vagrant plugin install vagrant-hostsupdater
after vagrant is installed - vagrant-triggers – by running
vagrant plugin install vagrant-triggers
after vagrant is installed
Quick Start
Make sure you have the requirements listed above, then use the following lines on the command line.
$ git clone https://github.com/bradp/vv ~/vv
$ git clone https://github.com/Varying-Vagrant-Vagrants/VVV.git ~/vagrant-local
$ cd ~/vagrant-local
$ curl -O https://gist.githubusercontent.com/salcode/da45f09ca0c319a108db/raw/Customfile
$ vagrant up
Alternate Long Version with Explanation
From your home directory run git clone https://github.com/Varying-Vagrant-Vagrants/VVV.git ~/vagrant-local
(this installs the project in ~/vagrant-local, which is the default installation location – use this location, it makes thing easier)
The official VVV first vagrant up instructions are worth reading on this topic.
Default IP Address 192.168.50.4
By default, VVV runs on IP address 192.168.50.4, which is only available on your machine. I’m coming from MAMP, where I could use my machine’s Local IP address from other devices on my network (e.g. my iPhone), which allowed me to test the site on these other devices. The ability to test on other devices is critical to the work I do.
VVV on Local IP Address
We can modify the network settings in the Vagrantfile, in the root of vagrant-local, by uncommenting the line
config.vm.network "forwarded_port", guest: 80, host: 8080
and adding the line
config.vm.network "forwarded_port", guest: 443, host: 8443
Rather than modify our Vagrantfile (and thus complicating future updates), we’re going to place this in Customfile which overrides settings in Vagrantfile. See my full VVV Custom File below.
This allows our guest machine (the vagrant machine running within our host machine) to run on our local IP address on port 8080. You can use find your local IP address instructions to determine your local IP address, mine is 10.0.1.6. Now I can load the vagrant machine from http://localhost/:8080, http://127.0.0.1/:8080, or http://10.0.1.6/:8080).
There remain two problems.
1. We want to run on port 80 (not port 8080) however vagrant will not allow us to use a host port less than 1025.
2. We need nginx to respond with the correct website, when we connect from another machine on the network.
VVV on Local IP Address Port 80
Port 80 is the default port for websites. We want to run on that port, which we can do with port forwarding on our host machine (remember our host machine is already listening on port 8080).
Update 20141105: I’ve moved my notes to a separate post on Mac pfctl Port Forwarding.
VVV on Local IP Address Port 443
Added 20150331: Port 443 is the default port for websites over https. We want to run on that port, which we can do with port forwarding on our host machine (our host machine is already listening on port 8443 by default).
These port forwarding rules are added to our VVV Custom File. Assuming you have vagrant-triggers installed, the port forwarding rules will be automatically applied on vagrant up (and automatically removed on vagrant suspend, halt, destroy).
My Vagrant Customfile
# you can put this file in place by | |
# navigating to your VVV directory (e.g. `cd ~/vagrant-local`) | |
# and running | |
# curl -O https://gist.githubusercontent.com/salcode/da45f09ca0c319a108db/raw/Customfile | |
# set port forwarding from host 8080 to guest 80 | |
# set port forwarding from host 8443 to guest 443 | |
config.vm.network "forwarded_port", guest: 80, host: 8080 | |
config.vm.network "forwarded_port", guest: 443, host: 8443 | |
if defined? VagrantPlugins::Triggers | |
# port forwarding setup and removal for running on your host primary IP address | |
config.trigger.after [:up, :reload, :provision], :stdout => true do | |
system('echo " | |
rdr pass inet proto tcp from any to any port 80 -> 127.0.0.1 port 8080 | |
rdr pass inet proto tcp from any to any port 443 -> 127.0.0.1 port 8443 | |
" | sudo pfctl -ef - >/dev/null 2>&1; echo "Add Port Forwarding (80 => 8080)\nAdd Port Forwarding (443 => 8443)"') | |
end | |
config.trigger.after [:halt, :suspend, :destroy], :stdout => true do | |
system('sudo pfctl -F all -f /etc/pf.conf >/dev/null 2>&1; echo "Removing Port Forwarding (80 => 8080)\nRemove Port Forwarding (443 => 8443)"') | |
end | |
end |
Nginx Wildcard Rules and xip.io
xip.io is an amazing free service that takes a URL and resolves it to the IP address that appears in the URL. For example, test.10.0.1.6.xip.io, example.10.0.1.6.xip.io, and salferrarello.10.0.1.6.xip.io all resolve to 10.0.1.6.
To make VVV resolve websites based on the xip.io URLs the nginx-config had to be modified. These changes have been accepted in VVV core and you can view the changes to make xip.io URLs work on the default VVV sites.
Changing site_url on the Fly
The problem with changing the url of the website every time you get a new local IP (e.g. you move to a new network) is you need to go update your site_url and home_url. I’ve found the Dynamic Hostname plugin that solves this issue.
Nginx Wildcard Rules and xip.io for future sites
You can setup new sites in VVV by hand but Brad Parbs has created an excellent tool called VV which automates VVV site setup, which includes support for xip.io rules.
Using this tool if you setup a new site called, testsite and it is available at testsite.dev, it will also be accessible via xip.io. For example, if you IP address is 10.0.1.6, testsite will be available at testsite.10.0.1.6.xip.io.
Default VVV Installs New Addresses
After these modifications, the default VVV installs will continue to be available at their original URLs but they’ll also be available at new xip.io URLs.
For example: If you IP address is 10.0.1.6,
- http://vvv.dev/ is also at http://10.0.1.6/
- http://local.wordpress.dev/ is also at http://local.wordpress.10.0.1.6.xip.io/
- http://local.wordpress-trunk.dev/ is also at http://local.wordpress-trunk.10.0.1.6.xip.io/
- http://src.wordpress-develop.dev/ is also at http://src.wordpress-develop.10.0.1.6.xip.io/
- http://build.wordpress-develop.dev/ is also at http://build.wordpress-develop.10.0.1.6.xip.io/
photo credit: Profound Whatever via photopin cc
“I’m coming from MAMP, where I could use my machine’s Local IP address from other devices on my network (e.g. my iPhone), which allowed me to test the site on these other devices.”
OK, this was the only reason I was unhappy with MAMP so far. Good to know.
This comment is confusing to me. Did you mean to say, “… this was the only reason I was unhappy with VVV so far.”? Or are you saying, you were unhappy with MAM because it allows you to use your machine’s Local IP address from other devices on your network?
Great solution! I was wondering how to deal with multiple sites in a single VVV virtual machine. Have you tried it?
Fernando, yes I do run multiple sites within VVV. I have slightly over 30 sites at this point in my VVV install.
I use VVV Site Wizard to setup new sites. At the top of this page, I have a link to a modified version of VVV Site Wizard I use that adds support for xip.io URLs.Update 2015-08-17: I use VV to setup new sites. It supports xip.io URLs.
do not use the vv tool with modern VVV, it will not work with v2+ and could even be destructive and break things.
Modern VVV uses
config/config.yml
to set up sitesCheers for the tips Sal.
Cannot get this darn thing to work though 🙁
Using your modified version of VVV Site Wizard (with Dynamic Hostname in place), try accessing my site on my tablet (for testing), and getting ‘no page available’.
I am using the following as the URL on my mobile device –
mysite.dev.192.168.0.5.xip.io
Any ideas?
As a first step, I’d try to get the URL working on you local machine then try your mobile device.
Try http://mysite.192.168.0.5.xip.io/
(this is without the “dev”) on your local machine.
If that works, then I’d try your mobile device.
@Sal Ferrarello YES that removes the problem (for me). I am able to visit my tangolausanne.dev with tangolausanne.dev.192.168.0.42.xip.io
and the default wordpress installation with local.wordpress.192.168.0.42.xip.io
thanks for the solution!
Also… It seems this provides faster throughput than if I use ngrok, although grok has the advantage of allowing remote users to reach the site within vvv (tangolausanne.dev) whereas xip.io only works for devices on the local network,.. and where ‘vagrant share’ doesn’t allow devices to reach those sites at all (only the nginx default site).
Thanks a ton Sal for this post, I followed the steps and now able to access my VVV environments from remote machine. (I still have to try the site wizard)
Btw, one quick addition which may be common sense to you but took me few minutes to figure out. So, after port forwarding, one can access the main vvv.dev URL on remote machine by typing http://ip_address_of_host and can access local.wordpress.dev environment via http://local.wordpress.ip_address_of_host.xip.io/ (I was confused on the 2nd as new to xip.io)
Thanks for the kind words and feedback Arun. I’ve added a new section “Default VVV Installs New Addresses”, which I hope will help clarify this for future readers. Thanks for your help.
This configuration uses old syntax for the “rdr” command, which can no longer be abbreviated to just “r”.
rdr pass inet proto tcp from any to any port 80 -> 127.0.0.1 port 8080
Works instead.
Hi Woody,
Thanks for taking the time to post your comment. I apologize but I don’t fully understand your note. I believe the line you have posted is the same as the line from the post. I was unable to spot where I’m using “r” as an abbreviation. My knowledge of rdr is not strong and I’m interested in improving my work with it. Thanks.
In copying/editing the file, I accidentally stripped the “rd” from the “rdr” command. My mistake!
Thanks for this script!
I’ve made more than my fair of copy/paste errors and they’re never any fun. I’m glad to hear you got it sorted.
I can access url with to http://local.wordpress.10.0.1.6.xip.io/ with my IP, without any problem, but I can not access it from ipad, smatphone. It just load.
1. I’d double-check your local IP address. While it is possible it is 10.0.1.6, which is the same number I use in this example, it seems an unlikely coincidence. See my post on Finding Your Local IP Address
2. Once you’re certain about your local IP address, I’d visit that directly (e.g. http://10.0.1.6/). You should see the VVV dashboard page that lists Home, Repository, phpMyAdmin, etc. I’d check this both on your Mac and then on your other devices.
You are completely wrong.you didn’t mention about setting network publicaly available, you should add this into custom config.I may be mistaken but I think you have an error in this post. You didn’t mention about setting network publicly available. I believe this setting is needed in the custom config.
I’m finding this process rather frustrating.
You had an error in your last comment, I hope you’re okay that I corrected and re-worded it for you.
You’re right, I’m not setting
config.vm.network “public_network”
in my configuration. There are two major ways to access your VVV sites from another machine, Port Forwarding and Public Network. Jeremy Felt does a great job discussing both of them in his post Various Networking Configurations in VVV.I prefer the Port Forwarding setup, which I outline above. If you’d prefer to go the Public Network route, as you mentioned in your last comment, Jeremy Pry has a nice write up on
How to View a Locally Developed Website on Other Devices. Additionally, initially I had a tough time grasping how the Public Network setup worked but Jeremy Pry was particularly helpful in this GitHub Issue thread on Getting the VVV public_network setting to work.
I prefer the Port Forwarding setup because with the Public Network method I find the process of finding the IP address assigned to Vagrant cumbersome (but I’m working on improving that process in this VVV issue Create new page to display public_network IP address and PR).
I would also consider whether VVV is the best tool for you. I know a number of developers who have made the jump to VVV but then returned to MAMP, DesktopServer, or whatever WordPress Development Environment they used previously. If most of your work is on the front-end or theming, VVV may not be the best choice.
Finally, I understand the frustration that can come with initially setting up VVV. I struggled with it myself, which is why I wrote this post. I hope others find this helpful but even if they don’t it has proven itself as an invaluable reference to me when setting up others with VVV.
Best of luck.
I’m still struggling to make it work. From smartphone and tablet browsers my [local_ip] opens vvv.dev but any domain like http://local.wordpress.[local_ip].xip.io/ gives me ERR_NAME_NOT_RESOLVED … I’ve already triple checked every setting (
Hi Nico,
I’d double-check the following URLs on your machine running VVV.
Final question, what is your local_ip?
Great post! This is the only post I’ve found that I could actually get to work, for accessing a vvv site from a device.
Thank you very much for this post. I require this same setup, and I eventually figured it all out prior to finding your site. I wish I would have saw your post before, it would have saved me some time! But its nice to have it all simply explained in 1 place, I will use it as a reference for our other devs.
One thing I am still trying to get straight is how can I expose all my sites to the web, via something like Ngrok? Is there any easy solution? I think I had it working a while back when I was messing around but I had to use a reverse proxy and Ngrok running on my host with header re-write I believe, also I was running into a re-direct loop with wordpress and magento sites, they would only work if you went to site.com/index, loop would happen if you left off the index.
Is there a simpler way to get this done? It doesn’t have to be Ngrok, we also have sub domains available. But I wanted to avoid creating and forwarding a domain for each site/vvv box.
Hi Matt,
In my workflow, I don’t make my local install accessible from outside my network. However, I have played with Local by Flywheel, which has an included HTTP/HTTPS Tunnel Add-on. In my test, it worked quite well.
I’m guessing you can get the same behavior from VVV but I think it will take some work. One particular challenge will be getting nginx to recognize the ngrok URL as belonging to the correct WordPress install.
If you figure a re-usable way to do this, I’d love to hear about it. Best of luck.
Hello! I’m Tom VVV project lead
Things have changed a little since this was written and should be much easier now:
–
vv
went away, it doesn’t work with VVV v2+, you can useconfig.yml
to set up sites now– VVV includes code to handle xip.io already, just add it to the hosts section of the site you’re using, reprovision, and it will take care of the rest. No messing about with Nginx or modifying scripts
– We dont use hostsupdater or triggers anymore, infact vagrant-triggers no longer works. You only need a single plugin, vagrant-goodhosts, and we’ll prompt you to install it if you haven’t already
– we switched everything from .dev to .test as Google bought the .dev TLD registry
– the default IP address changed! VirtualBox changed stuff and we had to move it
Importantly though, there are better ways to do this that are safer, such as ngrok and other tunnel systems, emulators, and staging servers. VVV is optimised for local development, with predictable logins, dev tools, and easy to inspect internals. These are terrible for production sites though which need to be hardened for security, so exposing a VVV instance to the local network outside your computer carries risks! This is why a customfile is necessary for xip.io access