schickling/dockerfiles builds small multi-arch images straight to Docker Hub

One directory per image, published under a single Hub namespace

The repository describes itself as a "Collection of lightweight and ready-to-use docker images", and the primary language is Shell, which tells you most of the design. There is no library, no plugin API and no runtime configuration. What you get is a set of image definitions, each in its own directory, each pushed to the `schickling` namespace on Docker Hub, whose homepage is the account page for that namespace.

The catalogue is the README list. It includes Beanstalkd and its Beanstalkd-Console admin console, Hugin and Panorama tools, a Jekyll working environment, a full texlive distribution in the Latex image, an extra small Mailcatcher, Mysql and Postgres S3 backup images that support periodic backups, an nginx image with environment variable support through envtpl, a minimal NodeJS and NPM image, a lightweight Octave development environment, a ready to use OpenCV image, a Redis management tool in Redis-Commander, a lightweight nightly Rust build including Cargo and GDB, a Swagger UI image with API_URL and API_KEY injection, a lightweight wrapper around s3cmd, and an nginx image for thumbor with CORS support.

Two directories in the tree are worth noting because the README list does not mention them: `postgres-restore-s3/`, which sits next to the backup images, and `scala-sbt-docker/`. The top-level entries also include a `Makefile`, a `LICENSE`, and a `README.md`.

The images are described with size as a selling point, in words like "lightweight", "minimal" and "extra small", and one entry gives a figure: the Swagger UI image is listed at 45 MB.

The Makefile builds with buildx and pushes immediately

The build mechanism is a single Makefile with one macro per image, and it is worth reading closely because it decides two things for you: the architecture list and the tag.

	docker buildx build \
		--push \
		--platform linux/arm64,linux/amd64 \
		-t "schickling/$1:$(if $2,$2,$(TAG))" \
		./$1

Two things are baked in. The build is multi-architecture by default, covering linux/arm64 and linux/amd64, which covers the common case of an arm64 laptop or CI runner alongside x86 servers. And there is no separate publish step, since `--push` is part of the same command that builds, so a `make` target does not leave a local image behind, it sends the result to the registry.

The tag comes from a three-step fallback at the top of the Makefile.

TAG := $(GITHUB_REF)
ifeq ($(TAG),)
	TAG := $(shell git symbolic-ref --short -q HEAD)
endif
ifeq ($(TAG),)
	TAG := $(shell git rev-parse --short --verify HEAD)
endif

So in CI the tag is the ref that triggered the build, locally it is the current branch name, and in a detached head it is the short commit hash. The consequence for a consumer is that tags are not stable names such as version numbers. There are no GitHub releases in this repository, and the repository has no version scheme of its own, so what you can rely on for reproducibility is a specific tag that was pushed on a specific commit.

Why install.sh scripts instead of Dockerfile commands

The README carries a FAQ entry that answers the most common question about this style of repository, and it answers it in one sentence: "Why do you use `install.sh` scripts instead of putting the commands in the `Dockerfile`?" The answer given is that structuring an image this way keeps it much smaller.

That is the whole design rationale, and it has consequences worth spelling out. When a Dockerfile carries the commands directly, every RUN layer stays in the image history and the layer itself remains, so a package installed and then cleaned up still costs space in that layer. Splitting the work into a script that runs inside a single layer lets the intermediate state be discarded in the same step. For images that are mostly a small utility, such as the s3cmd wrapper or the Mailcatcher, that difference decides whether the image is a few tens of megabytes or several times that.

The trade-off is opacity. The install scripts are the interesting part of each directory and they are not described in the top-level README, so the exact base image, the package list and the runtime user of any given image have to be read from that directory. The `Dockerfile` and `install.sh` in the directory you care about are the reference, not this README.

Building and pushing a single image

The Makefile exposes one target per image, each of which calls the shared macro. The Beanstalkd target is representative.

beanstalkd: ## Build beanstalkd image
	$(call docker_build_and_push,beanstalkd)

Running that target builds the `beanstalkd` directory and pushes it to Docker Hub as `schickling/beanstalkd` with the computed tag. The `all` target chains every image in the collection, from beanstalkd through to thumbor-nginx-cors, and the `help` target prints the list of targets using the comments attached to each one, which is why every target carries a trailing description comment.

The macro accepts a second argument for the tag, and the expression `$(if $2,$2,$(TAG))` means the override wins when it is supplied and the computed tag is used otherwise. That is how a specific tag can be pushed without changing the Makefile.

What you should expect after a build is an image on Docker Hub under the `schickling` namespace, tagged with either the branch name, the short commit hash, or the ref name from CI. Locally there is no image to inspect afterwards, because the build pushes rather than loads, which is an unusual enough default that it is worth knowing before you run it on a machine where you did not intend to publish.

The jekyll image is the one exception to the arm64 support

One target breaks the pattern, and the reason is written into the Makefile itself. The Jekyll image carries the comment that it is not compatible with arm architecture, and its build block differs from the shared macro in two ways: it declares only `--platform linux/amd64`, and its tag line has no tag suffix, so the image is pushed as `schickling/$1` with no `$(TAG)` appended.

jekyll: ## Build jekyll image
	docker buildx build \
		--push \
		--platform linux/amd64 \
		-t "schickling/$1" \
		./$1

Two consequences. An arm64 machine running the Jekyll image will not work without emulation, and the image pushed by this target has a bare name, so it is the one image in the collection that is not versioned by the computed tag at all. If your build hosts are arm64, the Jekyll entry in the README is effectively unavailable.

This is also the shape of the project's honest limit. Each image has its own compatibility quirks, and the collection as a whole only guarantees the two-platform build for the images that use the shared macro.

The S3 backup images are a workflow, not just a container

Three entries in the collection belong to backup and restore rather than to running a service: `mysql-backup-s3/`, `postgres-backup-s3/` and `postgres-restore-s3/`, plus a `s3cmd/` directory described as a lightweight wrapper around s3cmd.

The README describes the two backup images as backing up MySQL and PostgresSQL to S3, with periodic backups supported. That phrase matters, because a container that dumps a database once on start is a different tool from one that runs on a schedule. The restore directory, which the README does not list but which exists in the tree, completes the round trip.

The `s3cmd` image is the piece that makes the others possible, since moving data into and out of S3 needs a command line client, and the collection ships one as a standalone image so that a backup or restore job can call it as a sidecar or as a one-off container. The `nginx-envtpl` image plays a similar role for configuration templating, taking environment variables through envtpl so that a single image can be configured at start time rather than baked, and the thumbor-nginx-cors entry is the same nginx base used for a specific service with CORS enabled.

What the README does not document is any of the retention, scheduling or credential configuration for the backup images, so those details come from the image directories themselves.

No releases, tags derived from git, and a MIT licence

Maintenance facts here are simple and worth stating exactly. The repository is not archived, and the last push was on 2026-10-05. The repository has no GitHub releases, and the README still carries a Travis CI build status badge, which points to a build setup that predates the GitHub Actions workflows in the `.github/` directory, and the tree also carries a `.devcontainer/` directory for editing inside a container.

Since there are no releases and the tag is derived from a branch name or a commit hash, there is no upgrade path that says "move to version 2". Upgrading means moving to a different commit, and you verify the result by inspecting the image rather than by reading a changelog.

The licence is MIT, with the text in the `LICENSE` file at the top level, which is the permissive end of the scale and means the image contents can be used and modified in your own projects without asking. That covers the files in this repository, though it says nothing about the licences of the upstream software installed inside the images, which vary by project and are your responsibility to check per image.

The comparison with the official images published by each project is straightforward. Those are maintained by the upstream vendors who know their release cadence and publish tagged versions, while this collection gives you a smaller image, an arm64 build where the shared macro applies, and a maintenance model tied to individual commits rather than to upstream release lines.

Editorial conclusion

Use this collection when you need one of the listed images today, especially the smaller utility images such as mailcatcher, s3cmd, beanstalkd-console or redis-commander, and when a maintained multi-arch build matters more than a vendor image. Skip it when you need a database or framework image with a support contract, or when the amd64-only jekyll image is a problem for your arm64 build hosts. Verify first that the image directory you need exists, that its Dockerfile matches the base image you intend to run, and that the tag naming coming from GITHUB_REF matches what your deployment expects.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. schickling/dockerfiles on GitHub