Vagrant 1.7 comes with a new command:
is a single command to create a development environment for any application,
vagrant push is a single command to deploy any application.
The goal of Vagrant is to give developers a single workflow to develop
applications effectively. "vagrant up" creates a development environment for any application and "vagrant share" enables collaboration for any application. Deploying was the next logical step for Vagrant, now possible with "vagrant push".
Like every other component of Vagrant, push can be configured using multiple
strategies. "vagrant push" can deploy via FTP, Heroku, Atlas, or by executing any local script. Other strategies can be added via plugins and more will be added to core as time goes on.
Read on to learn more.
We've prepared a short video showing Vagrant Push in action.
Push to Deploy
Vagrantfile, and it is immediately available to every developer. Push configuration is simple and easy to understand:
config.push.define "ftp" do |push| push.host = "ftp.company.com" push.username = "username" push.password = "mypassword" end
And then to push the application to the FTP or SFTP server:
$ vagrant push ...
The "ftp" in the configuration above defines the strategy Vagrant will
use to push. Below, we cover strategies in more detail.
define multiple pushes, perhaps one to staging and one to production, for example. To learn more about multiple push definitions, read the complete documentation.
A Single Command
The biggest benefit of Vagrant Push is being able to define a single command
to deploy any application. Whether the deploy process is complex or
is just a simple push to Heroku, developers only need to know that any
application within their organizations can be deployed with
For complicated deploys, the benefit is obvious. For simpler deploys, such
as a push to Heroku, Vagrant Push is still useful. Besides not having to know that Heroku is being used under the hood, Vagrant Push will automatically configure your Git remote so the push works. Prior to this, you'd at least have to know the Heroku application name and configure your local repository to be able to push to it.
Of course, not all applications stay that simple, and if your application
outgrows Heroku, then the deploy process doesn't change with Vagrant:
vagrant push to deploy any application.
Like providers, provisioners, and other features in Vagrant, pushes can
be configured with multiple strategies. Vagrant 1.7 ships with four strategies:
to Atlas, a commercial product from HashiCorp.
via FTP or SFTP to a remote server. This is great for static sites, PHP, etc.
Git repository to Heroku, and configure the Git remote for you if it doesn't already exist.
Executes a local script on the system using a shell, deferring deployment logic to the user. This is for custom behavior or more complicated interactions with systems.
In addition to these built-in strategies, new strategies can be
built just like any other Vagrant plugin.
This allows 3rd parties to extend the capabilities of
vagrant push, and
will surely result in future versions of Vagrant shipping with more push
To learn all the details about Vagrant Push, please read the
This is a historic day for Vagrant. Vagrant 0.1 came out and defined
"vagrant up" to build a development environment for any application. Vagrant 1.1 made it possible to have development environments on top of any provider (VMware, Docker, etc.). Vagrant 1.5 introduced the "share" command to collaborate. And now, Vagrant 1.7 completes the development process with "push" to deploy.
The mission of Vagrant has been the same since day one: development
environments made easy. This mission spans any language choice, any provider choice, and likewise any choice of how to deploy these applications. Push continues this mission by adding a necessary feature to the development workflow.
With Vagrant 1.7 available, we'll be blogging about more of the features
as well as creeping towards a 2.0!