Gabriel Monroy here, creator of the Deis project. I'll be answering questions here and on Twitter (@gabrtv). I want to give a big shout out to the Docker crew for their support.

I should also mention the release notes (which explain what's next) can be found here: http://deis.io/deis-0-0-5-public-beta/

Hi Gabriel, how will this compare to the other Docker-PaaS projects going on? (Flynn, Dokku). I see the inclusion of Chef as a major feature?

Well firstly, I believe we're the first distributed Docker-based PaaS to be released. We are using Buildstep for Heroku Buildpack integration, which is part of Dokku. And we've been talking with the Flynn crew about how we can create more reusable components for the Docker PaaS community.

Our use of Chef is reflective of a larger design decision to work with DevOps tools that are already in widespread use.

Speaking on behalf of the Docker project, I am very glad that the two first PaaS projects built on Docker happen to be led by Jeff, Daniel and Jonathan (for Flynn) and Gabriel's crew (for Deis). They are all active and helpful Docker contributor who "get" the importance of interoperability between Docker projects. They have pledged to play nice with each other by focusing on reusable components which will benefit the entire Docker community.

So for that, thank you! I hope more people follow your example and remember open-source is not a zero-sum game.

How do you plan to support private-cloud deployments? In particular, I'd like to deploy this on bare-metal servers, using containers (presumably via Docker) but not VMs.

Deis was designed with private cloud in mind. The only trick with bare-metal is that we need a provisioning API so the controller can scale nodes up and down. Check out our EC2 provider plugin to see the 5 Celery tasks you'd need to implement to get Deis working on bare metal: https://github.com/opdemand/deis/blob/master/celerytasks/ec2...

Does Deis implement zero downtime deploys and safeguards against failed deploys? I can't see anything on the site on how this is handled.

We follow the twelve factor build/release/run model (see Concepts in our docs), so most deploy issues are caught during the build stage which occurs in the foreground of a git push. The run stage is a simple Chef run which pulls from a databag.

We don't currently support zero downtime deploys, though we should soon by using a combination of Nginx no-downtime reload and stale container "garbage collection".

Awesome work, this project looks great. Do you plan to add support for Amazon's ELB to serve as proxy?

It's certainly possible to implement ELB as a proxy. We'd be open to a pull request for that.

However our focus on private cloud means we must use Nodes/Instances/VMs for every component. This is how we decouple the PaaS from the underlying cloud provider.

This is really exciting, I've been waiting for someone to combine all of the various deployment technologies like this for a while.

However... If I set up my servers manually, or even through chef, I have pretty intimate knowledge of how my apps are being deployed. I know the various pipes data goes through, software versions, what services are running, etc. In other words, I have a pretty reasonable mental model of my deployment architecture. This is especially helpful when troubleshooting. However while the magic of Deis looks like a godsend, I am very caution about upgrading my technical debt from "managing my app servers, load balancer, and db servers" to "managing a PaaS that I happen to run my app on". I'm not trying to do ops for a Heroku clone, I'm just looking for an easier way to streamline my deployment process. What happens when I run "git push deis master" on a new release and everything breaks? The last thing I want to be doing is searching through the Deis github repo for error strings while my site is down.

Can anyone from the project assuage my fears? I realize this is kind of an open ended question, but a little assurance can go a long way.

Related: What are the planned price ranges for support on this?

I understand the concern about potential black box on the deployment side. Few points 1) this is an open-source project with a relatively small code-base and few moving parts 2) Chef does most of the heavy lifting on the deployment side using Databags and traditional Chef runs and 3) the build/release/run workflow is described here: http://docs.deis.io/en/latest/gettingstarted/concepts/#build...

With regard to support, OpDemand (creator/maintainer of Deis) will be launching paid support and professional services once the project stabilizes. Price points are not set yet. How would you like to see it priced?

Cheaply :)

Thanks for the response, I'll delve into the docs more. What would be really cool would be a snapshot/description of a sample deployment I could look through. A fake ssh session demo in the browser that I can poke around in would be pretty awesome. Reverse engineering chef cookbooks from github isn't exactly an easy way to learn about what a product does.

More specifically as per support pricing, I'd love site licensing as opposed to a per-deployment or per-server setup.

Just a thought: what would fit my needs almost perfectly is some sort of tiered email/forum/ticket based support option, which is upgradeable to phone/dedicated support when I'm doing deployments

shameless plug:

Open-source Heroku-esque PaaS which uses Go, Git, LXC, and HAProxy.

ShipBuilder is a freely available open-source project which aims to make it fast and easy to deploy arbitrary web-applications.

Get total control over all aspects of your staging and production environments.

More info:

http://shipbuilder.io/

https://github.com/sendhub/shipbuilder

Why not docker? and do u use cgroups etc? in any case, would be great to here about it..

is there a public paas deis server where i can deploy some test apps? or do u or does anyone plan a commercial heroku or dotcloud clone?

Deis is designed for running your own PaaS. You can use public or private clouds, but we still require you run your own controller.

If you're looking for a public PaaS solution, we recommend you take a look at dotCloud or Heroku.

With regard to a commercial offering, OpDemand (the company behind Deis) plans on offering paid support and professional services for Deis deployments once the project reaches stability.

ProTip: If you are building anything that you expect users to run themselves, copy/steal FoundationDB's AWS CloudFormation setup. One click and a couple form fields to setup, one click to tear down.

Edit: http://foundationdb.com/documentation/beta1/getting-started-...

Many of the companies interested in using Deis want a private cloud deployment, so we have intentionally avoided tying ourselves exclusively to AWS/EC2. That said, we can certainly make the installation process a bit easier in future releases. CloudFormation could be part of that.

I some other company starts a Deis based public PaaS, what would your attitude be? Could they get OpDemand's paid support?

Absolutely. We will be outlining our paid support options soon.

So how does this compare to flynn.io?

I'm not involved in Flynn nor Deis, but since Flynn is not available yet (and no source is visible at this point), I would be surprised if anyone could tell :-)

Startup idea:

1) crawl HN for links about X with comments like "How does this compare to Y"

2) present it as a knowledge base of technologies with comparison tables

i like this is more "private cloud" oriented and "not a whole os" i think thats a better move than attempting to "capture market" like quite a few other projects.

Now for unshare() to become more secure... ;-)

operate PaaS and use a PaaS is very different...

I wouldn't use Deis because of its tight integration with Chef. (I abandoned Chef in favor of Ansible) But for Chef users, it looks like a great project, and am glad to see an expanding community of Docker-based tools.

Yes, I was very sad when I read that I needed a running Chef Server to begin using Deis.