I added some "magic" Dockerfile comments - this is the one to add in order to not expose anything via HTTP:
NO_HTTP_PROXY
I am not a huge fan of volumes where data is stored on the box - but you can do it the same way I've described on the page.
I think of octohost boxes as app servers - if you have data on it, you should likely have it stored elsewhere. I've used Heroku to store additional data sometimes:
Packer is a tool that helps to build the image that octohost runs on. It installs all of the software needed and prepares the VM it runs on.
Vagrant is a tool that allows you to run different virtual machines on your local development box. It has nothing to do with production at the moment - it's just for running it locally.
The octovagrant box is pretty open - but that's because it's for running things locally. When it's installed on AWS/DO/Rackspace/Linode/etc. it's firewalled from remote people - but still is pretty open internally. I wouldn't let untrusted people push to it at the moment.
Yes - you need all of the cookbooks, but Packer will take care of that for you - you don't have to really worry about that.
If you're just using the AWS AMI that we've already built - then you can really ignore Packer and Chef - just launch the AMI and you're done.
Docker allows you to run processes inside of a container. So you can launch a set of processes from your source code and have it run on its own.
Once it's setup, you merely add a remote git target, push your code to the server and it builds and launches the code that you have pushed. It works like Heroku for simple websites.
Dokku was the inspiration for it. I wanted a simple way to deploy small websites and I really wanted to understand how it all worked together - so I built my own.
One major difference (like already mentioned) is that I wanted to use Dockerfiles rather than Procfiles. I wanted to have full control over how it built and ran - and I didn't want to go through slugbuilder / buildstep at the time.
It may actually be easier on end users to use Heroku buildpacks and abstract some of the magic - but for our uses Dockerfiles were the best fit.
Now, the Tutum team came out with something that even simplifies it even more - and it might be worth looking at:
We're building a backend using Docker that can do just that. It's called octohost and there's lots of information available here: http://www.octohost.io/
http://www.octohost.io/data-stores.html
I added some "magic" Dockerfile comments - this is the one to add in order to not expose anything via HTTP:
NO_HTTP_PROXY
I am not a huge fan of volumes where data is stored on the box - but you can do it the same way I've described on the page.
I think of octohost boxes as app servers - if you have data on it, you should likely have it stored elsewhere. I've used Heroku to store additional data sometimes:
http://blog.froese.org/2014/03/17/using-octohost-with-heroku...
We've also used remote MySQL servers:
https://github.com/octohost/mysql-plugin
There's lots of ways to do it.