I worked on the Cloud Foundry buildpacks team for a while, so I have seen the good and the bad of the buildpacks approach. But actually using Docker in anger ha

I worked on the Cloud Foundry buildpacks team for a while, so I have seen the good and the bad of the buildpacks approach. But actually using Docker in anger has made me appreciate buildpacks more than I used to. Docker is step back in some respects, analogous to how lower-level languages are step back in some respects from higher-level languages. As for your questions: 1. A buildpack is meant by design to be an opinionated builder for a particular stack, not a totally pluripotent environment. If you need total control, you can have it by using Docker and sending those images to run on CF. The binaries you see being pulled in are either specifically built by Heroku for Heroku or by Cloud Foundry for Cloud Foundry. They're not random links plucked out of a Google search. It's not as though the Debian team aren't building binaries too. 2. The set of packages for Cloud Foundry in the "stack"[1] or rootfs is set by the buildpacks team, based on balancing the needs of various buildpacks consumers. Heroku do something similar. It's ad hoc insofar as any extremely consumed library is ad hoc. The concept of buildpacks is that you, the developer, don't have to care about what is installed. You throw code over the wall and it launches. For operators, the attraction is that there is a single known base environment and that it can be upgraded easily when CVEs are announced. In theory a Docker container can be whittled down to the minimum dependencies needed to run the software, but it requires tedious and often difficult-to-understand effort, so very few people do it. And indeed the whole reason to go through that effort is to make smaller images. When you have a single reference image, that argument is largely moot. [1] https://github.com/cloudfoundry/stacks https://github.com/cloudfoundry/stacks