Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Thanks for the quick reply!

> Instead of spinning up a VM on your local machine it spins up a new droplet in your Digital Ocean account (droplet is DO's term for a virtual server). >Vagrant integration with AWS or DO is simply to have the server spin up there rather than locally.

Every droplet costs money, why would you want to create new droplets for development, when you can spin up a VM locally? What are the advantages of spinning up remote server instances over local ones?



The remote one is for production, not development. (Well, thats how I'm using them anyway).

In my workflow I have two boxes in my Vagrant profile, one for development (local VBox VM) and one for production (DO droplet). Using Chef for provisioning, I can configure and test provisioning locally, then roll it out in production with minimal effort.

Its a really nice workflow! Although all this Docker business lately looks like it might make for an even better one.


What's the overhead of Vagrant for production purposes? Maybe I'm too old school for all of this, but I still don't understand what docker is or what it does.


There is no overhead for vagrant, it is just something that provisions/sets up your server with chef/puppet/whatever

once the server is up, it is exactly the same as if you did it by hand


Other people can see and work with a remote development server. If you're pair programming or having a consultant or friend help you debug something tricky, you can set up screen sessions with just an ssh login instead of having to set up and configure another tool that the other person might not be familiar with. If you're working from home, or with a distributed team that can't all be on the same network, with a remote server you don't have to monkey with letting someone else into your network.

Droplets only cost money when they're instantiated/on. At the end of the day, you nuke the server and can deploy it again in the morning if you need to.


Instead of having one or 2 machines that simulate a much smaller production environment by connecting out to digital ocean or aws you can spin up a full sized copy of your production infrastructure.

This is nice as it allows you to do performance testing as well as stability and provisioning tests and your normal unit\functional\whatever tests.

While you wouldn't want to do it for every commit (unless you had your own infrastructure with space(though you could still do a partial test and profile)) it would be nice to test every merge to master.


For fractions of a cent an hour, Its just as comfortable not to be tying up my local resources.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: