docker-alpine builds the official alpine image from release metadata

What this repository actually is

The confusion here is worth resolving first, because the name suggests a Dockerfile you would copy and it is not that.

The README describes this as the official Docker image for Alpine Linux. What the repository actually contains reveals the pipeline: a Dockerfile whose entrypoint is a Lua script, a `prepare-branch.sh`, a `tests/` directory, a `docs/` directory and a `.dockerignore`.

The Dockerfile is short enough to read in full:

FROM alpine:3.23
RUN apk add --no-cache lua5.3 lua-filesystem lua-lyaml lua-http
COPY fetch-latest-releases.lua /usr/local/bin
VOLUME /out
ENTRYPOINT [ "/usr/local/bin/fetch-latest-releases.lua" ]

Read it as a generator rather than as the image definition. It starts from an existing alpine image, installs a Lua interpreter with filesystem, YAML and HTTP libraries, copies in `fetch-latest-releases.lua`, and runs it, writing output to a mounted volume. The script's job, by its name, is to fetch the latest Alpine releases and emit the descriptors for the image variants.

So the flow is upstream release to metadata to image variants, and this repository is the step in the middle. Changing what is inside the official alpine image is done upstream in Alpine Linux; changing how the variants are generated is done here.

The size argument, and how dated it is

The README's central claim is size. The image is stated as only 5MB, against much larger alternatives, and a table gives the comparison at a point in time: alpine latest at 5.58MB, ubuntu latest at 64.2MB, debian at 114MB and centos at 202MB.

Two things about that table. The table's main comparison is between Alpine and much larger base images at that point in time; it does not establish current ratios.

Second, and more important for anyone quoting it, the README itself carries a note that all of the example outputs above were last generated or updated on May 3rd 2019. Those specific byte counts, and the v3.9 Alpine package versions in the transcript below them, are seven years old.

The comparison that still carries information is the busybox one. The README notes that images such as `progrium/busybox` get close to a minimal container and package system, but that those particular BusyBox builds piggyback on the OpenWRT package index, which is often lacking and not tailored to generic everyday applications. The demonstration is a package install that fails on one base and succeeds on the other: installing nodejs on the busybox image returns an unknown package error, while the same install on alpine pulls twenty-one packages in a fraction of a second.

That is the real argument. Small is not the point; small plus a usable package index is the point.

The usage pattern the README is pushing

The README frames adoption as stopping one thing and starting another, with a concrete before and after.

The discouraged form is a Dockerfile built on `ubuntu:22.04` that runs `apt-get update`, installs `mysql-client` with a noninteractive frontend, cleans the apt cache and removes `/var/lib/apt`. The README states this took 28 seconds to build and produced a 169 MB image.

The recommended form is the same intent on alpine:

FROM alpine:3.16
RUN apk add --no-cache mysql-client
ENTRYPOINT ["mysql"]

Stated at 4 seconds and 41 MB. Those numbers are from the same 2019 note and the tag is dated, but the shape of the difference is the lesson: build time as well as size.

The README demonstrates `--no-cache` in both package-install examples, but it does not explain the flag's caching behaviour.

The narrower point is about the busybox base. Using `alpine` gets you the small image plus a package index with real packages in it. Using a bare busybox image gets you the small image and an index that cannot install what you need.

What the tooling implies about release cadence

The presence of `fetch-latest-releases.lua` and `prepare-branch.sh` tells you how variants are produced, even though the README does not explain the process.

The Lua script implies a metadata-driven build: something fetches release information, parses YAML, and emits descriptors for the images. The dependencies chosen for it say something about the environment, since `lua-filesystem`, `lua-lyaml` and `lua-http` together are exactly what you need to read a release file, parse a structure and make an HTTP request, and nothing else.

`prepare-branch.sh` suggests that each image variant lives on its own branch or is prepared separately, which is a common pattern for repositories that publish many tags from one source tree.

The `tests/` directory means the generated output is checked rather than assumed. The README does not name a test framework, so the safest reading is that the tests validate the generated image descriptors rather than running the Lua code itself, and that is an inference rather than something the README states.

What none of this changes is the relationship to the base distribution. Alpine Linux itself, its package index and its release security fixes are upstream concerns. This repository automates the reflection of those releases into container images, and the freshness of the image is bounded by the freshness of the Alpine release it was built from.

Status, and what to check before relying on a tag

The licence is MIT, with a LICENSE file at the repository root.

The repository is not archived, and the last push was on 2026-09-17, so the pipeline is receiving work.

There are no GitHub releases, which is consistent with a project whose output is container image tags rather than versioned artefacts. If you need to know which Alpine release a given image tag corresponds to, the answer lives in the image itself and in the Alpine release announcements, not in this repository's release history.

One specific trap is visible in the repository files. The Dockerfile in this repository builds on `alpine:3.23`, while the README's recommended Dockerfile still says `FROM alpine:3.16`. So the documentation is demonstrably behind the build configuration. Anyone copying the usage example verbatim is pinning to an older Alpine series than the one the project's own tooling targets, and should check which series they actually want.

The `docs/` directory is the other place to look, since the README does not cover how variants are named or how long a given tag is supported.

Editorial conclusion

Adopt alpine as a base image when image size matters, since the size argument over an Ubuntu base still holds even though the specific numbers in the README are from 2019. Do not treat this repository as a place to change what is inside the image, because it builds official variants from upstream releases rather than shipping a custom image. Verify first which Alpine release series you target, since the Dockerfile here builds on alpine:3.23 while the README's usage example still shows alpine:3.16, and remember the image is not archived and carries no releases.

Frequently asked questions

Official sources

1. alpinelinux/docker-alpine on GitHub
2. Issues
3. License: MIT
4. README