I've worked on Cloud Foundry buildpacks. Something that does a better job at assembling OCI images than Dockerfiles is still welcome. Buildpacks have the advan

I've worked on Cloud Foundry buildpacks. Something that does a better job at assembling OCI images than Dockerfiles is still welcome. Buildpacks have the advantage that the developer doesn't need to care about anything below their own direct dependencies. The runtime and OS are kept up to date by the platform, so you're relieved of the broadest angles of attack. It's not a panacea. Just as with Dockerfiles, you have other upstream dependencies (Ruby gems, NPM modules, JARs etc) that need to be tracked and updated. Some of that can be delegated to the buildpack (ie, setting version range specifiers like '^1.1.2' or '1.1.*'), but that introduces some uncertainty about what is actually running in production. Deis I believe did what we originally did in Cloud Foundry, which is to use Heroku's buildpack code. We ran soft forks for several years, adding only enough to allow execution in disconnected environments. The Buildpacks team have since adopted a hard fork policy and have been replacing Heroku code with a uniform codebase called libbuildpack[0]. The new ones pass the same test suite we run and should work for Deis. [0] https://github.com/cloudfoundry/libbuildpack https://github.com/cloudfoundry/libbuildpack