cedarish

Hi, I'm also a maintainer :) to answer your questions: 1) we expose ceph in the router, so your apps could use it. This will have to be managed by you however as we don't have a user story for plugging apps into backing services asides from `deis config:set`[1]... Yet. 2) Performance is still something we're working on. When you deploy an application using a Heroku buildpack[2], your app is compiled into a container which sits on top of Heroku's cedar stack, which is around 800MB[3]. It's a beefy stack so fleet will take some time deploying that image. This should only occur the first time it's scheduled onto a new host as future images will just use the cache for that image, significantly speeding up deployment times. If you deploy an app using a Dockerfile and it's been optimized correctly (we have an app sitting under 5MB for test purp

A problem with the Heroku/pkgr approach to handling dependencies is that applications using this approach can never fully follow the advice provided under "Dependencies" in the 12-factor guidelines (http://12factor.net/dependencies), because some libraries are always outside the scope of RubyGems, pip, npm, or whatever language-specific package system the app is using. Heroku works around this problem, rather than dealing with it directly, by including a hodgepodge of packages in the Cedar base system. If you have a Heroku account, create an app, run a one-off shell process, and look at all the packages that are installed (e.g. by looking at /var/lib/dpkg/info/*.list). Or look at how Dokku and Flynn approximate this poorly defined base system by looking at https://github.com/progrium/cedarish. I suspect that pkgr will need to do the same.