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.