Self-hosted service
vimagick/dockerfiles avatar
vimagick/dockerfiles

vimagick/dockerfiles: A Curated Collection of Docker Recipes Across 15 Categories

:whale: A curated list of delicious docker recipes 🇺🇦🇮🇱 (Let's Fight Against Dictatorship)

3,209 stars781 forksDockerfileLicense varies

At a glance

What is it?
vimagick/dockerfiles is a long-running community-maintained repository of Dockerfiles organized into 15 categories, from big data and IoT to security, proxy, VPN, and media tools. It is a starting point for engineers who want working Docker configurations for services that are tedious to containerize from scratch.
Who is it for?
vimagick/dockerfiles is most useful as a reference and starting point, not a finished distribution. Engineers who need a working Docker setup for an obscure or tricky service save time by reading these recipes before building their own.
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 last received commits 5 days ago.
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 26, 2026, and from our analysis. They are not legal advice.

Editorial analysis

What vimagick/dockerfiles Is and Who It Serves

vimagick/dockerfiles is a curated collection of Dockerfiles and Docker Compose configurations for containerizing a wide variety of services. The README describes it as "a collection of delicious docker recipes," emphasizing its role as a source of ready-made, working configurations rather than a distribution of finished Docker images.

The repository is useful to engineers and operators who need to containerize a service that does not have an obvious official image, requires specific build-time configuration, needs to run on ARM hardware, or involves tools that are technically complex to set up from a blank base image. Categories include Big Data, IoT, Automation, Machine Learning, Monitor, Daemon, Media, Web, Security, Proxy, VPN, DNS, and a 3rd-party section listing compose references for well-known services.

The built Docker images are published on Docker Hub under the username easypi, referenced in the README as https://hub.docker.com/u/easypi/.

How the Repository Is Organized

Each service gets its own top-level directory named after the service. For example, the top-level entries include airflow/, mosquitto/, nginx/, ffmpeg/, tor/, and dozens more. Each directory contains the Dockerfile and, in many cases, a Docker Compose file and supporting configuration files for that service.

To get the collection, clone the repository from the URL listed in the README:

bash
git clone https://github.com/vimagick/dockerfiles

Navigate into the directory for the service you want, read the Dockerfile and any README in that subdirectory, then build or adapt it for your use. The root README serves as an index: every completed recipe has a checkmark, entries still on the Todo list have an empty checkbox, and deprecated or abandoned entries are marked with a skull symbol.

The 3rd-party section at the end of the index does not contain original Dockerfiles; instead it lists Docker Compose references for well-known projects such as GitLab CE, CouchDB, Elasticsearch, and Ghost, linking to their official images while providing a single curated index.

Categories and Notable Service Coverage

The Big Data category includes airflow, kafka-arm, kestra, luigi, nifi, and prestodb and prestosql variants. The IoT section covers mosquitto, node-red, flashmq, and tile38-arm. Monitor includes the complete metrics stack: collectd, graphite, influxdb, logstash, statsd, telegraf, and vnstat.

The Proxy section is one of the most detailed, covering over 30 services: dante, haproxy-arm, ngrok, privoxy, shadowsocks (and shadowsocks-libev), squid, stunnel, tor, and more. The VPN section lists dsvpn, n2n, ocserv, openconnect, openvpn-arm, strongswan, tinc, wireguard, and others.

The Security section includes penetration testing and monitoring tools: aircrack-ng, amass, clamav, hydra, kismet, maltrail, routersploit, snort, and wafw00f. The Media section is similarly broad: ffmpeg, ffmpeg-arm, icecast, mpd, murmur, paddle-ocr, piper, tesseract, and yt-dlp.

The Todo list in the README documents what the maintainer has not yet completed, including caddy, gitbook, and postfix. This makes the repository's gaps explicit rather than leaving engineers to discover them by absence.

ARM Support as a Practical Pattern

A significant portion of the recipes exist in ARM variants, identified by the -arm suffix in the directory and image names. The Big Data section has kafka-arm and superset-arm. The Daemon section has alpine-arm, nullmailer-arm, redis-arm, samba-arm, and swarm-arm. The Proxy section has fteproxy-arm, haproxy-arm, privoxy-arm, and stunnel-arm. The VPN section has openconnect-arm, openvpn-arm, pptp-arm, tinc-arm, and more.

This ARM coverage addresses a real gap in many software vendors' own Docker Hub publishing, where ARM images are often missing or published late. An operator running Docker on Raspberry Pi hardware, an ARM-based server, or Apple Silicon in a container environment will find that ARM-specific recipes save significant build and debugging time compared to attempting a standard x86 image on ARM.

Not every service has an ARM variant, and where one is missing, the standard recipe may or may not cross-compile depending on the base image and the software's own ARM support.

Deprecated Entries and What the Maintenance History Shows

The README uses a skull symbol to mark entries that have been abandoned or replaced. Deprecated entries visible in the excerpt include youtube-dl (replaced by yt-dlp), youtube-worker, and discuz. This is a useful signal: the maintainer updates the index to reflect dead software rather than leaving misleading checkmarks.

Some entries carry a bug symbol (beetle icon), indicating known issues. The daemon section marks webkit, moodle, and tmail as buggy; the proxy section marks nothing explicitly; the monitor section marks urlwatch. These signals are qualitative flags, not full changelogs, but they help triage which recipes to audit before use.

The last push to the repository was on 2026-09-26, confirming recent activity. The repository has no GitHub releases and no explicit license stated in the repository metadata.

vimagick/dockerfiles vs Official Docker Hub Images

Official Docker Hub images, designated by the "Official Image" label on Docker Hub, are maintained by software vendors or by Docker, audited against security standards, published with multi-architecture manifests, and updated on a regular patching schedule. They represent the production-grade baseline for services like nginx, postgres, redis, and python.

vimagick/dockerfiles occupies a different role. Its recipes cover services that either do not have official images, exist only as bare images without compose configurations, or have ARM gaps that the official images have not addressed. The trade-off is coverage versus maintenance: a community recipe may lag behind security patches or break when the upstream software updates its installation process.

For services where an official or vendor-maintained image exists, the official image is the safer choice for production. vimagick/dockerfiles is most useful for the services and configurations that fall outside that coverage, or as a reference for understanding how a particular service is containerized.

Editorial conclusion

vimagick/dockerfiles is most useful as a reference and starting point, not a finished distribution. Engineers who need a working Docker setup for an obscure or tricky service save time by reading these recipes before building their own. Those who need production-grade images with SLA support, regular CVE patches, and signed manifests should use official Docker Hub images published by the software vendors. Before deploying any recipe from this repository, verify the Dockerfile against the current upstream version of the software and check whether a vendor-maintained image now exists for that service. The repository has no stated license.

Frequently asked questions

What is the vimagick/dockerfiles repository?

It is a curated collection of Dockerfiles and Docker Compose configurations for over 200 services, organized into 15 categories including big data, IoT, security, proxy, VPN, media, and web tools. Each service has its own directory in the repository with a working Dockerfile and often a compose file.

Does vimagick/dockerfiles include ARM-compatible images?

Yes. Many services have ARM-specific variants, identified by the -arm suffix in the directory name. This covers tools like mosquitto, redis, samba, openvpn, tinc, strongswan, haproxy, and others. Not every service has an ARM variant, and gaps are present where the upstream software lacks ARM support.

What license does vimagick/dockerfiles use?

The repository does not specify a license in its metadata. Before using or distributing any Dockerfiles from this collection in a commercial product, verify the license terms with the repository maintainer, as the absence of a stated license means no explicit permissions are granted.

Official sources

  1. Issues
  2. Project website
  3. README
  4. vimagick/dockerfiles on GitHub
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/vimagick-dockerfiles.svg)](https://hysenlabs.com/projects/vimagick-dockerfiles)