vimagick/dockerfiles: A Dockerfile Cookbook, Not a Distribution
:whale: A curated list of delicious docker recipes 🇺🇦🇮🇱 (Let's Fight Against Dictatorship)
At a glance
- What is it?
- The repository is a curated set of per-service Dockerfile directories plus a README index that marks each entry with status emoji. It is useful as a source of working build recipes and as a map of what the author has already covered, and it is not a maintained product with releases or a support policy.
- Who is it for?
- Adopt vimagick/dockerfiles if you want a starting point for a service the README already lists with a checked box and you are willing to read the Dockerfile and build it yourself. Do not adopt it if you need a supported image with a release cadence, an upgrade path, or a security response process, because none of that is described in the repository.
- Can I use it commercially?
- Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Dockerfile, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What vimagick/dockerfiles actually is
This is a repository of Dockerfile recipes, one directory per service, collected under a single README index. The README describes it as "A collection of delicious docker recipes." Nothing in the material indicates a library, a CLI, a runtime component, or a package you install. The unit of consumption is a directory: you find the service you want in the README list, open that directory, and use the Dockerfile inside it.
The audience is engineers who self-host. The topics attached to the repository are docker, docker-compose, dockerfile and self-hosted, and the categories in the README are the categories that audience thinks in: Big Data, IoT, Automation, Monitor, Daemon, Media, Web, Security, Proxy, VPN, DNS, and so on. Someone running a home server or a small internal stack who needs a mosquitto, a gitea, or a dnsmasq container is the intended reader.
The README also carries a todo list of services not yet done: caddy, postfix, postfixadmin, nagios, hashcat, imagemagick, and others. That list is the clearest statement of scope. The project is additive and open-ended, not bounded by a specification.
The README index is the interface, and its markers are the metadata
There is no manifest, no generated catalog, and no machine-readable index in the material. The README is a nested bullet list of checkboxes. A checked box means the recipe exists. An unchecked box, as in the todo section, means it does not.
Beyond the checkbox, the author annotates entries with short markers. The README uses :+1: on entries such as node-red, mosquitto, nginx, samba, aria2 and tinc. It uses :beetle: on entries such as jenkins-arm, moodle, urlwatch, snort, snort3, webkit and ffserver. It uses :skull: on youtube-dl, youtube-worker and discuz, and it strikes those names through with tildes. It uses :moneybag: on plex and emailengine, and :cn:, :ru:, :octocat:, :camera:, :musical_note:, :tv: and :shopping: on various entries.
The README does not define any of these markers. Based on the pattern, a struck-through name with a skull is a removed or dead recipe, and a beetle suggests a known problem with that recipe, but the repository does not state this. If you are picking a recipe, treat the marker as a prompt to read the directory rather than as a rating. The :moneybag: entries are the ones where the upstream software itself has a commercial dimension, which is a different kind of signal from the beetle.
This is the main usability weakness of the project. A flat list of several hundred entries with undeclared emoji annotations puts the burden on the reader to interpret the author's shorthand.
The architecture is one directory per service, plus published images
The repository layout is implied by the README rather than spelled out: each listed service corresponds to a directory named after it, containing a Dockerfile. Some entries are grouped under a parent, as with the shadowsocks sub-list (shadowsocks, shadowsocks-libev, shadowsocks-arm, shadowsocks-libev-arm) and the confluentinc sub-list (cp-kafka-mqtt, cp-kafka-rest, ksqldb-cli, ksqldb-server).
Many entries have an -arm suffix, and the README points to two separate Docker Hub accounts: vimagick for x86 and easypi for arm. That split is the clearest architectural decision in the project. If you are on an ARM board, you are looking at a different set of directories and a different registry namespace than someone on x86_64. Some services exist only in one variant. kafka-arm, superset-arm, mosquitto, tile38-arm, gogs-arm, hugo-arm and phpmyadmin-arm appear as ARM entries, while the x86 side has its own list.
The third-party section is different in kind. Entries there are named after upstream images or organizations, such as adguard/adguardhome, archivebox/archivebox, codercom/code-server, gitea/gitea, ghost, and drupal. The section header says "sorted by basename." These are recipes for running someone else's image, not Dockerfiles the author wrote from scratch. Mixing the two kinds of entry in one README without a stated distinction is a real ambiguity: a reader cannot tell from the index alone whether a given line means "the author built this image" or "the author documented how to run this image."
Building and running a recipe
The material does not include a build script, a Makefile, a compose file, or a documented command. The workflow implied by the repository is the standard one for a directory containing a Dockerfile: change into the service directory and run a build against it.
git clone https://github.com/vimagick/dockerfiles cd dockerfiles/<service> docker build -t <service> . docker run --rm -it <service>
Those commands are the generic Docker sequence, not something quoted from this README. The README itself gives no run instructions, no environment variable table, and no volume list. That is the largest practical gap in the project. For a service like gitea or mosquitto, the interesting decisions are which ports to publish, which volumes to mount for persistence, and which environment variables the entrypoint reads. The repository does not document any of that centrally; you have to infer it from the Dockerfile and from the upstream project's own documentation.
The README does link to a wiki at github.com/vimagick/dockerfiles/wiki. That is where per-service notes may live, but the supplied material does not include wiki content, so I cannot say what is documented there. If you are evaluating a specific recipe, the wiki link is the first place to look after the Dockerfile itself.
For the third-party entries, the build step may not apply at all. If the recipe is a compose file or a run configuration for an upstream image, the relevant command is docker compose up or docker run against the upstream tag, and the repository's contribution is the surrounding configuration.
Published images and where they come from
The README links to two Docker Hub namespaces: hub.docker.com/u/vimagick for x86 and hub.docker.com/u/easypi for arm. The homepage field for the repository points at the easypi account. That means for many entries there is a prebuilt image you can pull instead of building locally.
What the material does not tell you is how those images are built, when they were last rebuilt, or how they are tagged. There are no releases retrieved for the repository, so there is no release-based versioning to align an image tag against. If you pull a vimagick or easypi image, you are trusting a tag whose provenance is not described in the README.
The README does show a Travis CI badge pointing at travis-ci.org/vimagick/dockerfiles. Travis CI's hosted service for open source projects has been discontinued, so a badge on that domain is more likely to be a historical artifact than a live build signal. I cannot confirm the current build status from the material, and the README does not describe what the CI job does. Treat the badge as unverified.
Where this approach breaks down
The repository has no releases and no changelog. The last push is recent, but recent activity on a repository of several hundred independent recipes does not tell you whether the one recipe you care about was touched. A push could be a new service, a fix to one Dockerfile, or a README edit.
Because each directory is independent, there is no shared base image, no common versioning scheme, and no way to upgrade a group of services together. If you run six of these recipes, you have six unrelated build contexts and six independent update stories. That is the opposite of what a platform team usually wants.
The ARM and x86 split doubles the maintenance surface. A fix applied to nginx does not automatically reach nginx-arm, and the README lists them as separate entries. The same applies to ffmpeg and ffmpeg-arm, dnsmasq and dnsmasq-arm, samba and samba-arm, tinc and tinc-arm, stunnel and stunnel-arm, openconnect and openconnect-arm, pptp and pptp-arm, privoxy and privoxy-arm, and the shadowsocks family. Nothing in the material suggests an automated mechanism keeps the pairs in sync.
The license field for the repository is unknown. That matters more than usual here. A Dockerfile is a build recipe, and the license of the resulting image is the license of the software it installs, not the license of the recipe. If you are redistributing images built from these directories, the operative licenses are the upstream ones, and the material gives you no inventory of them. This is not legal advice; it is a reason to check the upstream license for each service you ship.
How it compares to building your own Dockerfile or using an official image
The obvious alternative for any single service is the upstream project's own official image. Prestodb is listed in the README as "official" and prestosql as "community," which shows the author is already distinguishing between recipes that wrap an upstream image and recipes the author maintains. For a service like postgres, redis, or nginx, the official image is maintained by people whose job is that service, with documented environment variables, documented volumes, and a tag policy.
The difference in approach is ownership. An official image is a product with a release process. A directory in vimagick/dockerfiles is a recipe the author wrote for their own use and published. The recipe may be simpler, may bake in a configuration the author preferred, and may install extra packages the official image omits. That is sometimes exactly what you want: a small image that does one thing your way.
The other alternative is writing the Dockerfile yourself. That takes an hour for a simple service and gives you a file you understand completely, pinned to versions you chose, with a build you control. The repository's value is in the cases where that hour has already been spent and the result is close enough to what you need. For a long-tail service with no official image, such as ipfm, vnstat, flowgger, or rehook, that is a real saving.
A third comparison is a general-purpose image collection such as linuxserver.io, which is not mentioned in this material. The structural difference is that such projects publish images with a documented tag scheme and a support forum, while this repository publishes recipes. I am not asserting anything about linuxserver.io's contents here, only noting the category difference a reader should weigh.
Maintenance cost and what to verify before adopting a recipe
If you build from a directory in this repository, you own that Dockerfile from the moment you copy it. There is no dependency update mechanism, no automated base image rebuild described, and no notification when an upstream version changes. The practical cost is that you will re-read the Dockerfile whenever the service needs a version bump, and you will do that per service.
If you pull from the vimagick or easypi namespaces instead, your cost shifts to tracking someone else's tags. Since the repository has no releases, you cannot map a repository state to an image digest through any documented process. The safest reading of the material is that the images are a convenience and the directories are the source of truth.
The README's todo list is worth checking before you invest in a recipe, because it tells you what the author has not done. caddy, postfix, postfixadmin, nagios, hashcat and imagemagick are all unchecked. If your stack needs one of those, this repository will not help you and you should look elsewhere rather than wait.
Finally, the repository carries a political statement in its description and uses flag emoji and country markers on entries. That is the author's choice and it is visible in the index. It does not affect the Dockerfiles, but a team evaluating the project for internal use should know it is there before someone finds it in a fork.
Editorial conclusion
Adopt vimagick/dockerfiles if you want a starting point for a service the README already lists with a checked box and you are willing to read the Dockerfile and build it yourself. Do not adopt it if you need a supported image with a release cadence, an upgrade path, or a security response process, because none of that is described in the repository. Before you build anything, open the specific directory you care about and check two things: whether a matching image already exists under the vimagick or easypi Docker Hub accounts, and whether the Dockerfile pins a version tag or pulls a moving base such as latest. The README index tells you what exists, not what is current.
Community notes