{"id":13400481,"url":"https://github.com/docker-library/official-images","last_synced_at":"2025-09-09T20:21:02.426Z","repository":{"id":11255494,"uuid":"13655949","full_name":"docker-library/official-images","owner":"docker-library","description":"Primary source of truth for the Docker \"Official Images\" program","archived":false,"fork":false,"pushed_at":"2025-05-02T16:26:27.000Z","size":29660,"stargazers_count":6659,"open_issues_count":56,"forks_count":2406,"subscribers_count":266,"default_branch":"master","last_synced_at":"2025-05-05T14:09:33.825Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"https://hub.docker.com/u/library","language":"Shell","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/docker-library.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":"CODE-OF-CONDUCT.md","threat_model":null,"audit":null,"citation":null,"codeowners":".github/CODEOWNERS","security":"SECURITY.md","support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2013-10-17T17:27:12.000Z","updated_at":"2025-05-05T06:57:12.000Z","dependencies_parsed_at":"2023-01-16T21:01:12.799Z","dependency_job_id":"305d0ae4-e46a-486a-b4b5-95ccf1684a88","html_url":"https://github.com/docker-library/official-images","commit_stats":{"total_commits":18288,"total_committers":887,"mean_commits":20.61781285231116,"dds":0.8250765529308837,"last_synced_commit":"6b4803e65a2c56f15b91f8a11bd90f0bcb756c1c"},"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/docker-library%2Fofficial-images","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/docker-library%2Fofficial-images/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/docker-library%2Fofficial-images/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/docker-library%2Fofficial-images/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/docker-library","download_url":"https://codeload.github.com/docker-library/official-images/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":253773920,"owners_count":21962195,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-07-30T19:00:52.490Z","updated_at":"2025-05-12T16:09:21.318Z","avatar_url":"https://github.com/docker-library.png","language":"Shell","funding_links":[],"categories":["Shell","others","Useful Images","Shell (473)","docker ##"],"sub_categories":["[@trekhleb/javascript-algorithms](/javascript/@trekhleb/javascript-algorithms/)"],"readme":"# Docker Official Images\n\n## Table of Contents\n\n\u003c!-- AUTOGENERATED TOC --\u003e\n\n1.\t[Docker Official Images](#docker-official-images)\n\t1.\t[Table of Contents](#table-of-contents)\n\t2.\t[What are \"Official Images\"?](#what-are-official-images)\n\t3.\t[Architectures other than amd64?](#architectures-other-than-amd64)\n\t4.\t[More FAQs?](#more-faqs)\n\t5.\t[Contributing to the standard library](#contributing-to-the-standard-library)\n\t\t1.\t[Review Guidelines](#review-guidelines)\n\t\t\t1.\t[Maintainership](#maintainership)\n\t\t\t2.\t[Repeatability](#repeatability)\n\t\t\t3.\t[Consistency](#consistency)\n\t\t\t4.\t[Clarity](#clarity)\n\t\t\t5.\t[init](#init)\n\t\t\t6.\t[Cacheability](#cacheability)\n\t\t\t7.\t[Security](#security)\n\t\t\t\t1.\t[Image Build](#image-build)\n\t\t\t\t2.\t[Runtime Configuration](#runtime-configuration)\n\t\t\t\t3.\t[Security Releases](#security-releases)\n\t\t\t8.\t[Multiple Architectures](#multiple-architectures)\n\t\t2.\t[Commitment](#commitment)\n\t6.\t[Library definition files](#library-definition-files)\n\t\t1.\t[Filenames](#filenames)\n\t\t2.\t[Tags and aliases](#tags-and-aliases)\n\t\t3.\t[Instruction format](#instruction-format)\n\t\t4.\t[Creating a new repository](#creating-a-new-repository)\n\t\t5.\t[Adding a new tag in an existing repository (that you're the maintainer of)](#adding-a-new-tag-in-an-existing-repository-that-youre-the-maintainer-of)\n\t\t6.\t[Change to a tag in an existing repository (that you're the maintainer of)](#change-to-a-tag-in-an-existing-repository-that-youre-the-maintainer-of)\n\t7.\t[Bashbrew](#bashbrew)\n\n\u003c!-- AUTOGENERATED TOC --\u003e\n\n## What are \"Official Images\"?\n\nThe Docker Official Images are curated images [hosted on Docker Hub](https://hub.docker.com/u/library). The main tenets are:\n\n- Focus on [Free](https://www.debian.org/social_contract#guidelines) and [Open-Source](https://opensource.org/) Software\n\n- Support [multiple architectures](#architectures-other-than-amd64)\n\n- Exemplify [`Dockerfile` best practices](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/)\n\n- [Actively rebuild](#library-definition-files) for updates and security fixes\n\n- Adhere to upstream recommendations\n\n- Add minimal quality-of-life behavior for the container environment where fit\n\nSee [Docker's documentation](https://docs.docker.com/docker-hub/official_repos/) for a good high-level overview of the program.\n\nIn essence we strive to heed upstream's recommendations on how they intend for their software to be consumed. Many images are maintained in collaboration with the relevant upstream project if not maintained directly by them. Additionally we aim to exemplify the best practices for Dockerfiles to serve as a reference when making or deriving your own images from them.\n\n(If you are a representative of an upstream for which there exists an image and you would like to get involved, please see the [Maintainership](#maintainership) section below!)\n\n## Architectures other than amd64?\n\nSome images have been ported for other architectures, and many of these are officially supported (to various degrees).\n\n-\tArchitectures officially supported by Docker, Inc. for running Docker: (see [download.docker.com](https://download.docker.com/linux/))\n\t-\tARMv6 32-bit (`arm32v6`): https://hub.docker.com/u/arm32v6/\n\t-\tARMv7 32-bit (`arm32v7`): https://hub.docker.com/u/arm32v7/\n\t-\tARMv8 64-bit (`arm64v8`): https://hub.docker.com/u/arm64v8/\n\t-\tLinux x86-64 (`amd64`): https://hub.docker.com/u/amd64/\n\t-\tWindows x86-64 (`windows-amd64`): https://hub.docker.com/u/winamd64/\n-\tOther architectures built by official images: (but *not* officially supported by Docker, Inc.)\n\t-\tARMv5 32-bit (`arm32v5`): https://hub.docker.com/u/arm32v5/\n\t-\tIBM POWER8 (`ppc64le`): https://hub.docker.com/u/ppc64le/\n\t-\tIBM z Systems (`s390x`): https://hub.docker.com/u/s390x/\n\t-\tMIPS64 LE (`mips64le`): https://hub.docker.com/u/mips64le/\n\t-\tRISC-V 64-bit (`riscv64`): https://hub.docker.com/u/riscv64/\n\t-\tx86/i686 (`i386`): https://hub.docker.com/u/i386/\n\nAs of 2017-09-12, these other architectures are included under the non-prefixed images via [\"manifest lists\"](https://docs.docker.com/registry/spec/manifest-v2-2/#manifest-list) (also known as [\"indexes\" in the OCI image specification](https://github.com/opencontainers/image-spec/blob/v1.0.0/image-index.md)), such that, for example, `docker run hello-world` should run as-is on all supported platforms.\n\nIf you're curious about how these are built, head over to https://doi-janky.infosiftr.net/job/multiarch/ to see the build scaffolding.\n\nSee the [multi-arch section](#multiple-architectures) below for recommendations in adding more architectures to an official image.\n\n## More FAQs?\n\nYes! We have [a dedicated FAQ repository](https://github.com/docker-library/faq) where we try to collect other common questions (both about the program and about our practices).\n\n## Contributing to the standard library\n\nThank you for your interest in the Docker official images project! We strive to make these instructions as simple and straightforward as possible, but if you find yourself lost, don't hesitate to seek us out on [Libera.Chat IRC](https://libera.chat) in channel `#docker-library` or by creating a GitHub issue here.\n\nBe sure to familiarize yourself with [Official Repositories on Docker Hub](https://docs.docker.com/docker-hub/official_repos/) and the [Best practices for writing Dockerfiles](https://docs.docker.com/articles/dockerfile_best-practices/) in the Docker documentation. These will be the foundation of the review process performed by the official images maintainers. If you'd like the review process to go more smoothly, please ensure that your `Dockerfile`s adhere to all the points mentioned there, as well as [below](README.md#review-guidelines), before submitting a pull request.\n\nAlso, the Hub descriptions for these images are currently stored separately in the [`docker-library/docs` repository](https://github.com/docker-library/docs), whose [`README.md` file](https://github.com/docker-library/docs/blob/master/README.md) explains more about how it's structured and how to contribute to it. Please be prepared to submit a PR there as well, pending acceptance of your image here.\n\n### Review Guidelines\n\nBecause the official images are intended to be learning tools for those new to Docker as well as the base images for advanced users to build their production releases, we review each proposed `Dockerfile` to ensure that it meets a minimum standard for quality and maintainability. While some of that standard is hard to define (due to subjectivity), as much as possible is defined here, while also adhering to the \"Best Practices\" where appropriate.\n\nA checklist which may be used by the maintainers during review can be found in [`NEW-IMAGE-CHECKLIST.md`](NEW-IMAGE-CHECKLIST.md).\n\n#### Maintainership\n\nVersion bumps and security fixes should be attended to in a timely manner.\n\nIf you do not represent upstream and upstream becomes interested in maintaining the image, steps should be taken to ensure a smooth transition of image maintainership over to upstream.\n\nFor upstreams interested in taking over maintainership of an existing repository, the first step is to get involved in the existing repository. Making comments on issues, proposing changes, and making yourself known within the \"image community\" (even if that \"community\" is just the current maintainer) are all important places to start to ensure that the transition is unsurprising to existing contributors and users.\n\nWhen taking over an existing repository, please ensure that the entire Git history of the original repository is kept in the new upstream-maintained repository to make sure the review process isn't stalled during the transition. This is most easily accomplished by forking the new from the existing repository, but can also be accomplished by fetching the commits directly from the original and pushing them into the new repo (ie, `git fetch https://github.com/jsmith/example.git master`, `git rebase FETCH_HEAD`, `git push -f`). On GitHub, an alternative is to move ownership of the git repository. This can be accomplished without giving either group admin access to the other owner's repository:\n\n-\tcreate temporary intermediary organization\n\t-\t[docker-library-transitioner](https://github.com/docker-library-transitioner) is available for this purpose if you would like our help\n-\tgive old and new owners admin access to intermediary organization\n-\told owner transfers repo ownership to intermediary organization\n-\tnew owner transfers repo ownership to its new home\n\t-\trecommend that old owner does not fork new repo back into the old organization to ensure that GitHub redirects will just work\n\n#### Repeatability\n\nRebuilding the same `Dockerfile` should result in the same version of the image being packaged, even if the second build happens several versions later, or the build should fail outright, such that an inadvertent rebuild of a `Dockerfile` tagged as `0.1.0` doesn't end up containing `0.2.3`. For example, if using `apt` to install the main program for the image, be sure to pin it to a specific version (ex: `... apt-get install -y my-package=0.1.0 ...`). For dependent packages installed by `apt` there is not usually a need to pin them to a version.\n\nNo official images can be derived from, or depend on, non-official images (allowing the non-image [`scratch`](https://hub.docker.com/_/scratch/) and the intentionally limited exceptions pinned in [`.external-pins`](.external-pins) -- see also [`.external-pins/list.sh`](.external-pins/list.sh)).\n\n#### Consistency\n\nAll official images should provide a consistent interface. A beginning user should be able to `docker run official-image bash` (or `sh`) without needing to learn about `--entrypoint`. It is also nice for advanced users to take advantage of entrypoint, so that they can `docker run official-image --arg1 --arg2` without having to specify the binary to execute.\n\n1.\tIf the startup process does not need arguments, just use `CMD`:\n\n\t```Dockerfile\n\tCMD [\"irb\"]\n\t```\n\n2.\tIf there is initialization that needs to be done on start, like creating the initial database, use an `ENTRYPOINT` along with `CMD`:\n\n\t```Dockerfile\n\tENTRYPOINT [\"/docker-entrypoint.sh\"]\n\tCMD [\"postgres\"]\n\t```\n\n\t1.\tEnsure that `docker run official-image bash` (or `sh`) works too. The easiest way is to check for the expected command and if it is something else, just `exec \"$@\"` (run whatever was passed, properly keeping the arguments escaped).\n\n\t\t```sh\n\t\t#!/bin/sh\n\t\tset -e\n\n\t\t# this if will check if the first argument is a flag\n\t\t# but only works if all arguments require a hyphenated flag\n\t\t# -v; -SL; -f arg; etc will work, but not arg1 arg2\n\t\tif [ \"$#\" -eq 0 ] || [ \"${1#-}\" != \"$1\" ]; then\n\t\t    set -- mongod \"$@\"\n\t\tfi\n\n\t\t# check for the expected command\n\t\tif [ \"$1\" = 'mongod' ]; then\n\t\t    # init db stuff....\n\t\t    # use gosu (or su-exec) to drop to a non-root user\n\t\t    exec gosu mongod \"$@\"\n\t\tfi\n\n\t\t# else default to run whatever the user wanted like \"bash\" or \"sh\"\n\t\texec \"$@\"\n\t\t```\n\n3.\tIf the image only contains the main executable and its linked libraries (ie no shell) then it is fine to use the executable as the `ENTRYPOINT`, since that is the only thing that can run:\n\n\t```Dockerfile\n\tENTRYPOINT [\"fully-static-binary\"]\n\tCMD [\"--help\"]\n\t```\n\n\tThe most common indicator of whether this is appropriate is that the image `Dockerfile` starts with [`scratch`](https://registry.hub.docker.com/_/scratch/) (`FROM scratch`).\n\n#### Clarity\n\nTry to make the `Dockerfile` easy to understand/read. It may be tempting, for the sake of brevity, to put complicated initialization details into a standalone script and merely add a `RUN` command in the `Dockerfile`. However, this causes the resulting `Dockerfile` to be overly opaque, and such `Dockerfile`s are unlikely to pass review. Instead, it is recommended to put all the commands for initialization into the `Dockerfile` as appropriate `RUN` or `ENV` command combinations. To find good examples, look at the current official images.\n\nSome examples at the time of writing:\n\n-\t[php](https://github.com/docker-library/php/blob/b4aeb948e2e240c732d78890ff03285b16e8edda/5.6/Dockerfile)\n-\t[python](https://github.com/docker-library/python/blob/3e5826ad0c6e29f07f6dc7ff8f30b4c54385d1bb/3.4/Dockerfile)\n-\t[ruby:2.2](https://github.com/docker-library/ruby/blob/e34b201a0f0b49818fc8373f6a9148e13d546bdf/2.2/Dockerfile)\n\n#### init\n\nFollowing the Docker guidelines it is highly recommended that the resulting image be just one concern per container; predominantly this means just one process per container, so there is no need for a full init system. There are two situations where an init-like process would be helpful for the container. The first being signal handling. If the process launched does not handle `SIGTERM` by exiting, it will not be killed since it is PID 1 in the container (see \"NOTE\" at the end of the [Foreground section](https://docs.docker.com/engine/reference/run/#foreground) in the docker docs). The second situation would be zombie reaping. If the process spawns child processes and does not properly reap them it will lead to a full process table, which can prevent the whole system from spawning any new processes. For both of these concerns we recommend [tini](https://github.com/krallin/tini). It is incredibly small, has minimal external dependencies, fills each of these roles, and does only the necessary parts of reaping and signal forwarding.\n\nBe sure to use tini in `CMD` or `ENTRYPOINT` as appropriate.\n\nIt is best to install tini from a distribution-provided package (ex. `apt-get install tini`). If tini is not available in your distribution or is too old, here is a snippet of a `Dockerfile` to add in tini:\n\n```Dockerfile\n# Install tini for signal processing and zombie killing\nENV TINI_VERSION v0.18.0\nENV TINI_SIGN_KEY 595E85A6B1B4779EA4DAAEC70B588DFF0527A9B7\nRUN set -eux; \\\n  wget -O /usr/local/bin/tini \"https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini\"; \\\n  wget -O /usr/local/bin/tini.asc \"https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini.asc\"; \\\n  export GNUPGHOME=\"$(mktemp -d)\"; \\\n  gpg --batch --keyserver keyserver.ubuntu.com --recv-keys \"$TINI_SIGN_KEY\"; \\\n  gpg --batch --verify /usr/local/bin/tini.asc /usr/local/bin/tini; \\\n  command -v gpgconf \u0026\u0026 gpgconf --kill all || :; \\\n  rm -r \"$GNUPGHOME\" /usr/local/bin/tini.asc; \\\n  chmod +x /usr/local/bin/tini; \\\n  tini --version\n```\n\n#### Cacheability\n\nThis is one place that experience ends up trumping documentation for the path to enlightenment, but the following tips might help:\n\n-\tAvoid `COPY`/`ADD` whenever possible, but when necessary, be as specific as possible (ie, `COPY one-file.sh /somewhere/` instead of `COPY . /somewhere`).\n\n\tThe reason for this is that the cache for `COPY` instructions considers file `mtime` changes to be a cache bust, which can make the cache behavior of `COPY` unpredictable sometimes, especially when `.git` is part of what needs to be `COPY`ed (for example).\n\n-\tEnsure that lines which are less likely to change come before lines that are more likely to change (with the caveat that each line should generate an image that still runs successfully without assumptions of later lines).\n\n\tFor example, the line that contains the software version number (`ENV MYSOFTWARE_VERSION 4.2`) should come after a line that sets up the APT repository `.list` file (`RUN echo 'deb http://example.com/mysoftware/debian some-suite main' \u003e /etc/apt/sources.list.d/mysoftware.list`).\n\n#### Security\n\n##### Image Build\n\nThe `Dockerfile` should be written to help mitigate interception attacks during build. Our requirements focus on three main objectives: verifying the source, verifying author, and verifying the content; these are respectively accomplished by the following: using https where possible; importing PGP keys with the full fingerprint in the `Dockerfile` to check signatures; embedding checksums directly in the `Dockerfile`. All three should be used when possible. Just https and embedded checksum can be used when no signature is published. As a last resort, just an embedded checksum is acceptable if the site doesn't have https available and no signature.\n\nThe purpose in recommending the use of https for downloading needed artifacts is that it ensures that the download is from a trusted source which also happens to make interception much more difficult.\n\nThe purpose in recommending PGP signature verification is to ensure that only an authorized user published the given artifact. When importing PGP keys, please use the [the `keys.openpgp.org` service](https://keys.openpgp.org/about) when possible (preferring `keyserver.ubuntu.com` otherwise). See also the FAQ section on [keys and verification](https://github.com/docker-library/faq/#openpgp--gnupg-keys-and-verification).\n\nThe purpose in recommending checksum verification is to verify that the artifact is as expected. This ensures that when remote content changes, the Dockerfile also will change and provide a natural `docker build` cache bust. As a bonus, this also prevents accidentally downloading newer-than-expected artifacts on poorly versioned files.\n\nBelow are some examples:\n\n-\t**Preferred**: *download over https, PGP key full fingerprint import and `asc` verification, embedded checksum verified.*\n\n\t```Dockerfile\n\tENV PYTHON_DOWNLOAD_SHA512 (sha512-value-here)\n\tRUN set -eux; \\\n\t    curl -fL \"https://www.python.org/ftp/python/$PYTHON_VERSION/Python-$PYTHON_VERSION.tar.xz\" -o python.tar.xz; \\\n\t    curl -fL \"https://www.python.org/ftp/python/$PYTHON_VERSION/Python-$PYTHON_VERSION.tar.xz.asc\" -o python.tar.xz.asc; \\\n\t    export GNUPGHOME=\"$(mktemp -d)\"; \\\n\t# gpg: key F73C700D: public key \"Larry Hastings \u003clarry@hastings.org\u003e\" imported\n\t    gpg --batch --keyserver keyserver.ubuntu.com --recv-keys 97FC712E4C024BBEA48A61ED3A5CA953F73C700D; \\\n\t    gpg --batch --verify python.tar.xz.asc python.tar.xz; \\\n\t    rm -r \"$GNUPGHOME\" python.tar.xz.asc; \\\n\t    echo \"$PYTHON_DOWNLOAD_SHA512 *python.tar.xz\" | sha512sum --strict --check; \\\n\t    # install\n\t```\n\n-\t**Alternate**: *full key fingerprint imported to apt which will check signatures and checksums when packages are downloaded and installed.*\n\n\t```Dockerfile\n\tRUN set -eux; \\\n\t    key='A4A9406876FCBD3C456770C88C718D3B5072E1F5'; \\\n\t    export GNUPGHOME=\"$(mktemp -d)\"; \\\n\t    gpg --batch --keyserver keyserver.ubuntu.com --recv-keys \"$key\"; \\\n\t    gpg --batch --armor --export \"$key\" \u003e /etc/apt/trusted.gpg.d/mysql.gpg.asc; \\\n\t    gpgconf --kill all; \\\n\t    rm -rf \"$GNUPGHOME\"; \\\n\t    apt-key list \u003e /dev/null\n\n\tRUN set -eux; \\\n\t    echo \"deb http://repo.mysql.com/apt/debian/ bookworm mysql-${MYSQL_MAJOR}\" \u003e /etc/apt/sources.list.d/mysql.list; \\\n\t    apt-get update; \\\n\t    apt-get install -y mysql-community-client=\"${MYSQL_VERSION}\" mysql-community-server-core=\"${MYSQL_VERSION}\"; \\\n\t    rm -rf /var/lib/apt/lists/*; \\\n\t    # ...\n\t```\n\n\t(As a side note, `rm -rf /var/lib/apt/lists/*` is *roughly* the opposite of `apt-get update` -- it ensures that the layer doesn't include the extra ~8MB of APT package list data, and enforces [appropriate `apt-get update` usage](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#apt-get).)\n\n-\t**Less Secure Alternate**: *embed the checksum into the `Dockerfile`.*\n\n\t```Dockerfile\n\tENV RUBY_DOWNLOAD_SHA256 (sha256-value-here)\n\tRUN set -eux; \\\n\t    curl -fL -o ruby.tar.gz \"https://cache.ruby-lang.org/pub/ruby/$RUBY_MAJOR/ruby-$RUBY_VERSION.tar.gz\"; \\\n\t    echo \"$RUBY_DOWNLOAD_SHA256 *ruby.tar.gz\" | sha256sum --strict --check; \\\n\t    # install\n\t```\n\n\t-\t**Note:** the use of either SHA1 or MD5 should be considered a \"checksum of last resort\" as both are considered generally unsafe:\n\n\t\t-\t[\"Single-block collision for MD5\" from 2012](https://marc-stevens.nl/research/md5-1block-collision/)\n\t\t-\t[\"Announcing the first SHA1 collision\" from 2017](https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html)\n\n-\t**Unacceptable**: *download the file over http(s) with no verification.*\n\n\t```Dockerfile\n\tRUN curl -fL \"https://julialang.s3.amazonaws.com/bin/linux/x64/${JULIA_VERSION%[.-]*}/julia-${JULIA_VERSION}-linux-x86_64.tar.gz\" | tar ... \\\n\t    # install\n\t```\n\n##### Runtime Configuration\n\nBy default, Docker containers are executed with reduced privileges: whitelisted Linux capabilities, Control Groups, and a default Seccomp profile (1.10+ w/ host support). Software running in a container may require additional privileges in order to function correctly, and there are a number of command line options to customize container execution. See [`docker run` Reference](https://docs.docker.com/engine/reference/run/) and [Seccomp for Docker](https://docs.docker.com/engine/security/seccomp/) for reference.\n\nOfficial Repositories that require additional privileges should specify the minimal set of command line options for the software to function, and may still be rejected if this introduces significant portability or security issues. In general, `--privileged` is not allowed, but a combination of `--cap-add` and `--device` options may be acceptable. Additionally, `--volume` can be tricky as there are many host filesystem locations that introduce portability/security issues (e.g. X11 socket).\n\n##### Security Releases\n\nFor image updates which constitute a security fix, there are a few things we recommend to help ensure your update is merged, built, and released as quickly as possible:\n\n1.\t[Send an email to `doi@docker.com`](mailto:doi@docker.com) a few (business) days in advance to give us a heads up and a timing estimate (so we can schedule time for the incoming update appropriately).\n2.\tInclude `[security]` in the title of your pull request (for example, `[security] Update FooBar to 1.2.5, 1.3.7, 2.0.1`).\n3.\tKeep the pull request free of changes that are unrelated to the security fix -- we'll still be doing review of the update, but it will be expedited so this will help us help you.\n4.\tBe active and responsive to comments on the pull request after it's opened (as usual, but even more so if the timing of the release is of importance).\n\n#### Multiple Architectures\n\nEach repo can specify multiple architectures for any and all tags. If no architecture is specified, images are built in Linux on `amd64` (aka x86-64). To specify more or different architectures, use the `Architectures` field (comma-delimited list, whitespace is trimmed). Valid architectures are found in [Bashbrew's `oci-platform.go` file](https://github.com/docker-library/bashbrew/blob/v0.1.2/architecture/oci-platform.go#L14-L27):\n\n-\t`amd64`\n-\t`arm32v6`\n-\t`arm32v7`\n-\t`arm64v8`\n-\t`i386`\n-\t`mips64le`\n-\t`ppc64le`\n-\t`riscv64`\n-\t`s390x`\n-\t`windows-amd64`\n\nThe `Architectures` of any given tag must be a strict subset of the `Architectures` of the tag it is `FROM`.\n\nImages must have a single `Dockerfile` per entry in the library file that can be used for multiple architectures. This means that each supported architecture will have the same `FROM` line (e.g. `FROM debian:bookworm`). See [`golang`](https://github.com/docker-library/official-images/blob/master/library/golang), [`docker`](https://github.com/docker-library/official-images/blob/master/library/docker), [`haproxy`](https://github.com/docker-library/official-images/blob/master/library/haproxy), and [`php`](https://github.com/docker-library/official-images/blob/master/library/php) for examples of library files using one `Dockerfile` per entry and see their respective git repos for example `Dockerfile`s.\n\nIf different parts of the Dockerfile only happen in one architecture or another, use control flow (e.g.`if`/`case`) along with `dpkg --print-architecture` or `apk -print-arch` to detect the userspace architecture. Only use `uname` for architecture detection when more accurate tools cannot be installed. See [golang](https://github.com/docker-library/golang/blob/72bc141d781ae54ef20f71aa1105449cb6c2edc4/1.20/bookworm/Dockerfile#L26-L63) for an example where some architectures require building binaries from the upstream source packages and some merely download the binary release.\n\nFor base images like `debian` it will be necessary to have a different `Dockerfile` and build context in order to `ADD` architecture specific binaries and this is a valid exception to the above. Since these images use the same `Tags`, they need to be in the same entry. Use the architecture specific fields for `GitRepo`, `GitFetch`, `GitCommit`, and `Directory`, which are the architecture concatenated with hyphen (`-`) and the field (e.g. `arm32v7-GitCommit`). Any architecture that does not have an architecture-specific field will use the default field (e.g. no `arm32v7-Directory` means `Directory` will be used for `arm32v7`). See the [`debian`](https://github.com/docker-library/official-images/blob/master/library/debian) or [`ubuntu`](https://github.com/docker-library/official-images/blob/master/library/ubuntu) files in the library for examples. The following is an example for [`hello-world`](https://github.com/docker-library/official-images/blob/master/library/hello-world):\n\n```\nMaintainers: Tianon Gravi \u003cadmwiggin@gmail.com\u003e (@tianon),\n             Joseph Ferguson \u003cyosifkit@gmail.com\u003e (@yosifkit)\nGitRepo: https://github.com/docker-library/hello-world.git\nGitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87\n\nTags: latest\nArchitectures: amd64, arm32v5, arm32v7, arm64v8, ppc64le, s390x\n# all the same commit; easy for us to generate this way since they could be different\namd64-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87\namd64-Directory: amd64/hello-world\narm32v5-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87\narm32v5-Directory: arm32v5/hello-world\narm32v7-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87\narm32v7-Directory: arm32v7/hello-world\narm64v8-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87\narm64v8-Directory: arm64v8/hello-world\nppc64le-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87\nppc64le-Directory: ppc64le/hello-world\ns390x-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87\ns390x-Directory: s390x/hello-world\n\nTags: nanoserver\nArchitectures: windows-amd64\n# if there is only one architecture, you can use the unprefixed fields\nDirectory: amd64/hello-world/nanoserver\n# or use the prefixed versions\nwindows-amd64-GitCommit: 7d0ee592e4ed60e2da9d59331e16ecdcadc1ed87\nConstraints: nanoserver\n```\n\nSee the [instruction format section](#instruction-format) for more information on the format of the library file.\n\n### Commitment\n\nProposing a new official image should not be undertaken lightly. We expect and require a commitment to maintain your image (including and especially timely updates as appropriate, as noted above).\n\n## Library definition files\n\nThe library definition files are plain text files found in the [`library/` directory of the `official-images` repository](https://github.com/docker-library/official-images/tree/master/library). Each library file controls the current \"supported\" set of image tags that appear on the Docker Hub description. Tags that are removed from a library file do not get removed from the Docker Hub, so that old versions can continue to be available for use, but are not maintained by upstream or the maintainer of the official image. Tags in the library file are only built through an update to that library file or as a result of its base image being updated (ie, an image `FROM debian:bookworm` would be rebuilt when `debian:bookworm` is built). Only what is in the library file will be rebuilt when a base has updates.\n\nGiven this policy, it is worth clarifying a few cases: backfilled versions, release candidates, and continuous integration builds. When a new repository is proposed, it is common to include some older unsupported versions in the initial pull request with the agreement to remove them right after acceptance. Don't confuse this with a comprehensive historical archive which is not the intention. Another common case where the term \"supported\" is stretched a bit is with release candidates. A release candidate is really just a naming convention for what are expected to be shorter-lived releases, so they are totally acceptable and encouraged. Unlike a release candidate, continuous integration builds which have a fully automated release cycle based on code commits or a regular schedule are not appropriate.\n\nIt is highly recommended that you browse some of the existing `library/` file contents (and history to get a feel for how they change over time) before creating a new one to become familiar with the prevailing conventions and further help streamline the review process (so that we can focus on content instead of esoteric formatting or tag usage/naming).\n\n### Filenames\n\nThe filename of a definition file will determine the name of the image repository it creates on the Docker Hub. For example, the `library/ubuntu` file will create tags in the `ubuntu` repository.\n\n### Tags and aliases\n\nThe tags of a repository should reflect upstream's versions or variations. For example, Ubuntu 14.04 is also known as Ubuntu Trusty Tahr, but often as simply Ubuntu Trusty (especially in usage), so `ubuntu:14.04` (version number) and `ubuntu:trusty` (version name) are appropriate aliases for the same image contents. In Docker, the `latest` tag is a special case, but it's a bit of a misnomer; `latest` really is the \"default\" tag. When one does `docker run xyz`, Docker interprets that to mean `docker run xyz:latest`. Given that background, no other tag ever contains the string `latest`, since it's not something users are expected or encouraged to actually type out (ie, `xyz:latest` should really be used as simply `xyz`). Put another way, having an alias for the \"highest 2.2-series release of XYZ\" should be `xyz:2.2`, not `xyz:2.2-latest`. Similarly, if there is an Alpine variant of `xyz:latest`, it should be aliased as `xyz:alpine`, not `xyz:alpine-latest` or `xyz:latest-alpine`.\n\nIt is strongly encouraged that version number tags be given aliases which make it easy for the user to stay on the \"most recent\" release of a particular series. For example, given currently supported XYZ Software versions of 2.3.7 and 2.2.4, suggested aliases would be `Tags: 2.3.7, 2.3, 2, latest` and `Tags: 2.2.4, 2.2`, respectively. In this example, the user can use `xyz:2.2` to easily use the most recent patch release of the 2.2 series, or `xyz:2` if less granularity is needed (Python is a good example of where that's most obviously useful -- `python:2` and `python:3` are very different, and can be thought of as the `latest` tag for each of the major release tracks of Python).\n\nAs described above, `latest` is really \"default\", so the image that it is an alias for should reflect which version or variation of the software users should use if they do not know or do not care which version they use. Using Ubuntu as an example, `ubuntu:latest` points to the most recent LTS release, given that it is what the majority of users should be using if they know they want Ubuntu but do not know or care which version (especially considering it will be the most \"stable\" and well-supported release at any given time).\n\n### Instruction format\n\nThe manifest file format is officially based on [RFC 2822](https://www.ietf.org/rfc/rfc2822.txt), and as such should be familiar to folks who are already familiar with the \"headers\" of many popular internet protocols/formats such as HTTP or email.\n\nThe primary additions are inspired by the way Debian commonly uses 2822 -- namely, lines starting with `#` are ignored and \"entries\" are separated by a blank line.\n\nThe first entry is the \"global\" metadata for the image. The only required field in the global entry is `Maintainers`, whose value is comma-separated in the format of `Name \u003cemail\u003e (@github)` or `Name (@github)`. Any field specified in the global entry will be the default for the rest of the entries and can be overridden in an individual entry.\n\n\t# this is a comment and will be ignored\n\tMaintainers: John Smith \u003cjsmith@example.com\u003e (@example-jsmith),\n\t             Anne Smith \u003casmith@example.com\u003e (@example-asmith)\n\tGitRepo: https://github.com/example/docker-example.git\n\tGitCommit: deadbeefdeadbeefdeadbeefdeadbeefdeadbeef\n\t\n\t# this is also a comment, and will also be ignored\n\t\n\tTags: 1.2.3, 1.2, 1, latest\n\tDirectory: 1\n\t\n\tTags: 2.0-rc1, 2.0-rc, 2-rc, rc\n\tGitRepo: https://github.com/example/docker-example-rc.git\n\tGitFetch: refs/heads/2.0-pre-release\n\tGitCommit: beefdeadbeefdeadbeefdeadbeefdeadbeefdead\n\tDirectory: 2\n\tFile: Dockerfile-to-use\n\nBashbrew will fetch code out of the Git repository (`GitRepo`) at the commit specified (`GitCommit`). If the commit referenced is not available by fetching `master` of the associated `GitRepo`, it becomes necessary to supply a value for `GitFetch` in order to tell Bashbrew what ref to fetch in order to get the commit necessary.\n\nThe built image will be tagged as `\u003cmanifest-filename\u003e:\u003ctag\u003e` (ie, `library/golang` with a `Tags` value of `1.6, 1, latest` will create tags of `golang:1.6`, `golang:1`, and `golang:latest`).\n\nOptionally, if `Directory` is present, Bashbrew will look for the `Dockerfile` inside the specified subdirectory instead of at the root (and `Directory` will be used as the [\"context\" for the build](https://docs.docker.com/reference/builder/) instead of the top-level of the repository). If `File` is present, the specified filename instead of `Dockerfile` will be used.\n\nSee the [multi-arch section](#multiple-architectures) for details on how to specify a different `GitRepo`, `GitFetch`, `GitCommit`, or `Directory` for a specific architecture.\n\n### Creating a new repository\n\n-\tCreate a new file in the `library/` folder. Its name will be the name of your repository on the Hub.\n-\tAdd your tag definitions using the appropriate syntax (see above).\n-\tCreate a pull request adding the file from your forked repository to this one. Please be sure to add details as to what your repository does.\n\n### Adding a new tag in an existing repository (that you're the maintainer of)\n\n-\tAdd your tag definition using the instruction format documented above.\n-\tCreate a pull request from your Git repository to this one. Please be sure to add details about what's new, if possible.\n\n### Change to a tag in an existing repository (that you're the maintainer of)\n\n-\tUpdate the relevant tag definition using the instruction format documented above.\n-\tCreate a pull request from your Git repository to this one. Please be sure to add details about what's changed, if possible.\n\n## Bashbrew\n\nBashbrew (`bashbrew`) is a tool for cloning, building, tagging, and pushing the Docker official images. See [the Bashbrew `README`](https://github.com/docker-library/bashbrew#readme) for more information.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdocker-library%2Fofficial-images","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fdocker-library%2Fofficial-images","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdocker-library%2Fofficial-images/lists"}