This is exactly what needs to exist. I recently set up Ghost, Owncloud, and Gitlab on a personal server (odroid U3) that sits under my couch at home, and it's really rewarding to own the hardware which is my "cloud". However, it should be easier, and possible for anyone. Good for you guys.
I've been using dokku[0] for a while now and love how easy it is to just push random stuff up to a new subdomain. The other day I pushed up a doxygen html of an code base I was working with. I have my blog, portfolio site, random apps I use for myself, a cloud storage app etc.
It is definitely one more tool to learn, but it is pretty much a light wrapper around docker so it ended up being a great gradual introduction to the concepts and configurations of working with docker as well.
Be sure to install either the persistent storage[1] plugin or the docker options plugin[2] so that your apps can just use the file system on the server to make things a lot simpler.
Incidentally, running containers is probably a great way to "install" the ghost libc vulnerability[1] (assuming you're basing off of base-images made before the bug was patched, and you haven't updated your containers/images).
I'm not sure neither vagrant nor docker have this really fixed -- that is: easily patching the base system/image (and still be confident that the app keeps running).
Is there an easy way to update a container based off of a (possibly few generations remote) base-image? Eg: You've pulled down a bare-bones, official CoreOS/Ubuntu/Debian/RedHat image from docker -- set it up for your use-case (say made a base image with your own CA-cert bundled, wired it up for kerberos/ldap/AD, maybe set up a trusted ssh-server ca-cert) -- then made a handful of images based off that: db, cache, and web-app.
Is there an easy way to patch the base image and all descendants? I assume all state should be in other volumes, so maybe this is easier than I think?
At any rate, it is something to keep in mind -- that grabbing images are great, but updates are still needed!
As other mention, the ghost refereed to by gp, is a blogging platform.
Bad news: Sandstorm packages do not have any particular separation between "base system" and "app"; your app package is simply one big archive of the entire userspace filesystem needed. This is something we might conceivably do in the future, but for now we like the simplicity.
Good news: Once the app maintainer publishes an updated package, it is trivial to update your local app instances in-place. Much like installing apps on Android, the system just swaps out the old package for the new one without touching the user data. We are confident enough in the robustness of this that we plan to implement auto-updating of apps, again like Android (though you'll be able to turn it off if you prefer).
Curious news: With Sandstorm, it often (not always, but often) doesn't matter if an app has vulnerabilities. Each app instance is initially only accessible by its owner, and only accessible to others if the owner explicitly shares with them. Often, the people you are collaborating with aren't threats -- they're your friends.
Apps that public a public web site -- like Ghost (the blog platform, not the glibc vulnerability :) ) -- actually do so strictly as static content. Sandstorm serves the content for them, without executing any of the app's code.
Admittedly, this starts to break down if you want to have a public web site in which users can make persistent changes -- say, post comments.
Of course, if someone does compromise one of your app instances, it's only that instance. The rest of your server remains safe, since each app is in an isolated container.
None of this is to say that patching exploits doesn't matter, but security is not about absolutes, it's about risk management. It's significantly less likely that a bug in a Sandstorm app will lead to real damage.
