Run More Stuff in Docker

This page summarizes the projects mentioned and recommended in the original post on

Our great sponsors
  • Scout APM - Less time debugging, more time building
  • SonarQube - Static code analysis for 29 languages.
  • SaaSHub - Software Alternatives and Reviews
  • dockerfiles

    Various Dockerfiles I use on the desktop and on servers.

    The blog post links to Jessie Frazelle's GitHub repo [0]. Note that Jessie also has a blog post detailing her setup [1] from back in 2015.



  • bocker

    Docker implemented in around 100 lines of bash

    I appreciate the sentiment, but I wouldn't be able to put up with the slow container boot time for regular use. The author mentions this at the bottom. He claims 1sec delay. Last month I benchmarked it on new-ish hardware at 560ms, or 290ms if you disable namespaces (and so disable isolation).

    I wanted to also benchmark bocker[1] (docker written in bash) for a baseline comparison, but it no longer runs and I threw in the towel after ~30 mins of tinkering.

    Anyways, if you run something like `curl | jq | grep | less` you could be waiting a fair bit for all those containers to start. Package managers are pretty good these days. I think I can trust it to install `jq` properly.


  • Scout APM

    Less time debugging, more time building. Scout APM allows you to find and fix performance issues with no hassle. Now with error monitoring and external services monitoring, Scout is a developer's best friend when it comes to application development.

  • community

    Community content for the Cloud Native Buildpacks (CNB) project (by buildpacks)

    Many comments here point out how difficult it is to manage a separate dependency stack for each container when you use Dockerfiles to build them. This problem is just as difficult, time-intensive, and security-critical for microservice apps running on K8s as it is for CLI tools and graphical apps.

    Worth pointing out that there is an incubating CNCF project that tries to solve this problem by forgoing Dockerfiles entirely: Cloud Native Buildpacks (

    CNB defines safe seams between OCI image layers so that can be replaced out of order, directly on any Docker registry (only JSON requests), and en-mass. This means you can, e.g., instantly update all of your OS packages for your 1000+ containers without running any builds, as long as you use an LTS distribution with strong ABI promises (e.g., Ubuntu 20.04). Most major cloud vendors have quietly adopted it, especially for function builds:

    You might recognize "buildpacks" from Heroku, and in fact the project was started several years ago in the CNCF by the folks who maintained the Heroku and Cloud Foundry buildpacks in the pre-Dockerfile era.

    [Disclaimer: I'm one of the founders of the project, on the VMware (formerly Cloud Foundry) side.]

  • diun

    Receive notifications when an image is updated on a Docker registry

    I'm running a similar setup, whereby I run most applications (even the browser I'm using to type this reply) in docker or podman containers, opportunely created.

    Judging from the Git repo containing my dockerfiles, I've been doing so since ~mid June 2018.

    I've since automated:

    * checking new versions of Git repos, alpine versions, and short crawlers for tools (i.e. I run "perl" and a bunch of stuff happens and eventually some dockerfiles might get updated)

    * auto-committing any change made from the above step (i.e. ./ with a meaningful message based on the directory the dockerfile resides, as well as which environment variable containing the version changed

    * I use running on my dokku server to keep up with base images updates (i.e. I get an email in the morning stating alpine:3.12 has been updated or debian:buster-slim or whatever); when a base image changes I have to manually "dp alpine:3.12" to "docker pull" and "podman pull" it; after that, I "make base-images" and my local base images (each coming with a short line to enable a local apt-cache-ng proxy) to also get updated; then a simple "make" makes all of them (docker build -t .... and podman build -t ...)

    * Quite a lot of (mostly small) bash scripts to run those images.

    As an example, the Dockerfile I use to build hadolint:

    FROM local/mfontani/base:latest AS fetcher

  • hadolint

    Dockerfile linter, validate inline bash, written in Haskell

  • whalebrew

    Homebrew, but with Docker images

    Just want link to Whalebrew, which achieves a lot of what this article mentions but IMO is more user-friendly.

  • distroless

    🥑 Language focused docker images, minus the operating system.

    In many cases you don't need 500mb of base image.

    Minimal "distrofull" images are in the 50mb range. But often you don't really need a real distribution inside your docker image.

    See But distroless is not about one specific tool or base image, it's a paradigm that addresses precisely what you say (without throwing away the whale with the bathwater)

  • SonarQube

    Static code analysis for 29 languages.. Your projects are multi-language. So is SonarQube analysis. Find Bugs, Vulnerabilities, Security Hotspots, and Code Smells so you can release quality code every time. Get started analyzing your projects today for free.


    On the GitHub repo where you can ask for more packages to be installed:

    And in this pair or articles for specific languages


  • podman

    Podman: A tool for managing OCI containers and pods.

  • Sandboxie

    Sandboxie - Open Source

    It’s not clear to me what your requirements are, but take a look at Sandboxie for Windows. [1]


  • macondo

    generic, polyglot commands platform (by casidiablo)

    This reminded me of a proof of concept thing that facilitates this kind of work.

    I don't even know what it is I built, but it has been useful in some contexts.

    It basically allows you to easily wrap and distribute scripts (or more complex apps) that have specific dependencies that might not always be installed in the host. It does so by wrapping the script in a docker image.

    It also automates the annoying part of docker: mounting local paths for apps that need to interact with the host's file system.

    I need to write a blog post on this if anything to gather feedback. I'm still not 100% sold on the idea and there are some edge cases. Still, a fun experiment.

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts