Agreed. While cool at first glance, this feature is virtually useless to me, because if I want to do things properly, I need to make sound deployment system, an

Agreed. While cool at first glance, this feature is virtually useless to me, because if I want to do things properly, I need to make sound deployment system, and by no means pushing upstream stuff from your local machine is sound. And in fact it doesn't matter how many developers on your project can make releases, they never ever should do this that way. It is an obvious must that you have to be able to answer the question "what runs in production right now", anytime. There's one way to do that: deployment starts from your git/svn/whatever-vcs repository, not from some untracked code on any developer machine. That is very, very preferable even if there's only one almighty developer (you) on the project, and total must if you have a couple more developers with different access rights — like, it's quite possible you don't want every developer to know password to the DB (or some payment system, or something even more scary) on production, which you'll store in some configs outside of VCS. Or maybe there're simply some tweaks on production system which are not possible to reproduce on development/staging. So you'll have to run some more custom actions on every deployment and, again, in centralized fashion, not just from some developers vagrant instance. Using vagrant this way is essentially the same as encouraging everyone to SSH to prod instances themselves.