# docker-library-ghost: the source behind the official Ghost image > docker-library-ghost is the MIT licensed repository that produces the Docker Official Image for Ghost, holding the build templates, the entrypoint and the per-version directories that become the published image. The judgement is that it is a packaging repository rather than a product, which means the useful knowledge for a user is on Docker Hub and the useful knowledge for a contributor is in the official-images library file. **TryGhost/docker-library-ghost** — Docker Official Image packaging for Ghost - Repository: https://github.com/TryGhost/docker-library-ghost - Website: https://hub.docker.com/_/ghost - Stars: 798 · Forks: 317 - Language: Shell - License: MIT - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/tryghost-docker-library-ghost ## A packaging repository, and the documentation lives elsewhere This repository is the Git home of the Docker Official Image for Ghost. The repository description gives it away in three words, Docker Official Image packaging for Ghost, and the README says the same thing in a longer form: this is the Git repo of the Official Image for the ghost image, maintained by the Ghost Foundation. What the repository is not is the documentation. The README redirects in two directions. The full image description, including how to use the image and how to contribute or report issues, is on the Docker Hub page for the ghost image. The source of that description is itself a different repository, docker-library/docs, where it lives in the ghost directory and is generated from the source files there. The README file in this repository is marked as generated by the generate-repo-stub-readme.sh script in that docs repository, which is the clue to the whole arrangement. The readme in the packaging repository is a stub pointing at the places where the real content and the real contribution flow live, and the generated marker explains why it has not been filled in with anything specific. For a reader, that means a search for Ghost container usage will land on Docker Hub and not here. ## Two version series are kept side by side The most informative thing in the repository is its file listing, because the names show how the image is assembled. There is a directory called 6 and another called 6-next, and next to them sit two pairs of templates. Dockerfile.template and Dockerfile-next.template describe how the image is built, and docker-entrypoint.sh and docker-entrypoint-next.sh describe what runs when the container starts. A config-next.json file belongs to the same next series. So the packaging keeps two parallel lines at once: a current version and the version that comes next, each with its own directory, its own build template and its own entrypoint. That is what lets a new Ghost major version be prepared, tested and published without disturbing the line that production deployments are already pulling. The files are templates rather than finished Dockerfiles, which tells you that the concrete files inside the version directories are produced rather than hand edited. The repository is therefore closer to a generator than to a pile of configuration, and a change to how the image is built is a change to a template plus a regeneration step, not an edit to a single file. For someone pinning a tag in production, the practical consequence is that the tag naming decides which of the two lines you get, and the version directories are where you look to see what a given tag actually contains. ## apply-templates.sh, update.sh and versions.json are the pipeline Four file names describe the mechanics of the repository. apply-templates.sh is the script that applies the templates. update.sh is the script that performs an update. versions.sh and versions.json hold version data, in a script and a data file respectively, which is the usual pairing for a list of versions that is both executable and readable by other tools. Two more files sit alongside them. generate-stackbrew-library.sh and generate-stackbrew-library.jq are a shell script and a jq program whose shared name says they produce the Stackbrew library entry, which is the metadata Homebrew uses to offer a cask for the image. The pairing of a script and a jq filter is a common way to turn a Docker image into a package manager entry, and it is how the Ghost image reaches users who install with Homebrew rather than with docker pull. The README does not walk through these scripts line by line, and the repository does not include a document that does. What it does include is the small surface of a packaging repository: a handful of scripts, a handful of templates, two version directories and a licence file. The point for a reader is that the build is reproducible from files in the tree, and that the tree is deliberately thin. ## The real source of truth is the library/ghost file For anyone who wants to change what the image contains, the README points somewhere else entirely. The current source of truth for the ghost image is the library/ghost file in the official-images repository, and that is where the image definition lives. Two more pointers complete the picture. Outstanding pull requests for the image are found by looking at pull requests with the library/ghost label on the official-images repository, which tells you that contribution happens through that repository as well. And the full official images change lifecycle is documented in the docker-library FAQ, under the entry titled An image's source changed in Git, now what. That last entry answers a question every user of this kind of repository eventually asks. Why did a change merge here and the image on Docker Hub did not change? The answer is in the publishing pipeline that the FAQ describes, and the README simply links to it instead of restating it. The pattern is consistent through all of these pointers. The Docker Official Image programme keeps the image definition in one file, the build in a per-image repository like this one, and the human documentation in the docs repository. Nothing about that arrangement is unusual, but it is better to know before you open a pull request here expecting the change to reach a docker pull. ## No GitHub releases, because the artefact is the image The repository has no GitHub releases, and the release list is empty rather than missing. That is a deliberate consequence of the packaging model. The artefact a user consumes is a published image on Docker Hub, identified by a tag, not a source archive attached to a Git tag. The build happens on the infrastructure of the Official Image programme, and the tags that matter are the ones visible in a registry. For a team that wants to track what changed between two versions, the answer is therefore the tag list on the Docker Hub page and the changelog of the image description there, rather than the releases page of this repository. The git history is still there, with the last push on 2026-10-15, and the .github directory suggests the usual automation around pull requests and pushes, but the published surface is the registry. The licence here is MIT, which is the usual choice for a packaging repository and means the templates and scripts can be reused without the copyleft obligations that would apply to the Ghost application itself. That distinction matters if you fork the packaging: you are forking the recipe, and the software the recipe installs carries its own terms. ## What a Ghost deployment should read instead of this repository If your goal is to run Ghost in a container rather than to change the container, the reading order is straightforward and none of it involves this tree. The Docker Hub page for the ghost image carries the full image description and the usage instructions, and it is the place to look for how to pass configuration, how the data directory is handled and which environment variables the image expects. The library/ghost file in the official-images repository tells you what the published image is meant to contain, and the change lifecycle FAQ in the docker-library FAQ explains the delay between a merge and a new image appearing on the registry. Two of those sources are generated, which matters for a reader who wants to understand the process. The image description is generated from the ghost directory of the docker-library/docs repository, and the stub README in this repository is generated as well, so neither is edited directly. What this repository gives you is the part of the pipeline that has no user-facing page: the templates that define the image, the entrypoint that starts it, the version directories that hold the rendered output, and the scripts that move versions forward. If you are running Ghost, read Docker Hub. If you are trying to change what the image contains, this tree and the library/ghost file are where the work happens. ## Conclusion docker-library-ghost suits a team that wants the published Ghost image to be reproducible and reviewable, because the build recipe lives in versioned directories with named templates and a script that applies them, and because the definition of the image itself is a single file in the official-images repository. It is the wrong place to look for Ghost documentation, since the full image description is generated from the docker-library/docs repository and published on Docker Hub, and it is the wrong place to look for release notes, because the repository has no GitHub releases at all. Before you base a deployment on this image, read the library/ghost file in the official-images repository, check which version series the tag you plan to pull points at, and expect the gap between a merged change here and the image appearing on Docker Hub, which the project points at its own FAQ entry for. ## FAQ ### What is the docker-library-ghost repository? It is the Git repository of the Docker Official Image for Ghost, maintained by the Ghost Foundation and licensed under MIT. It holds the build templates, the entrypoint script and the per-version directories used to produce the published image. ### Where is the documentation for the official Ghost Docker image? On the Docker Hub page for the ghost image, which carries the full image description and usage information. That text is generated from the ghost directory of the docker-library/docs repository, and the readme in the packaging repository is a generated stub that points to it. ### How do I change what the official Ghost image contains? The source of truth for the image is the library/ghost file in the official-images repository, and outstanding changes are tracked as pull requests carrying the library/ghost label. The templates and version directories in this repository hold the build recipe. ### Why has a merged change not appeared on Docker Hub yet? The publishing pipeline for official images sits between the source repository and the registry, and the project points at the FAQ entry titled An image's source changed in Git, now what for the full lifecycle description. ## Sources - [Issues](https://github.com/TryGhost/docker-library-ghost/issues) - [License: MIT](https://github.com/TryGhost/docker-library-ghost/blob/master/LICENSE) - [Project website](https://hub.docker.com/_/ghost) - [README](https://github.com/TryGhost/docker-library-ghost/blob/master/README.md) - [TryGhost/docker-library-ghost on GitHub](https://github.com/TryGhost/docker-library-ghost) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tryghost-docker-library-ghost