docker/docker-install: The get.docker.com Script, Its Limits, and When Not to Use It

What the get.docker.com Script Actually Solves

Installing Docker CE by hand on a fresh Linux machine means adding a package repository, importing a signing key, and picking the right package names for that distribution. The repository docker/docker-install exists to collapse that into one command. The README describes its purpose plainly: "for a convenience for quickly installing the latest Docker-CE releases on the supported linux distros." The audience is anyone who wants Docker available in minutes on a machine they control, not anyone building a repeatable server image. The same sentence that defines the audience also sets the boundary, because the README adds that it "is not recommended to depend on this script for deployment to production systems." That is not a hedge buried in a wiki. It is the project's own framing, and it should shape how you use the tool.

How the Script Is Built and What It Installs

The repository is not a service. It is a shell script plus a small build system. The top level holds install.sh, rootless-install.sh, a Makefile, a scripts/ directory, and a verify-docker-install entry. The Makefile shows how the published artifacts are produced. It defines two channels, test and stable, and builds three files: build/test/install.sh, build/stable/install.sh, and build/stable/rootless-install.sh. Each build target runs sed against install.sh to swap the default channel value, then pipes the result through envsubst with three variables: LOAD_SCRIPT_COMMIT_SHA, LOAD_SCRIPT_STABLE_LATEST, and LOAD_SCRIPT_TEST_LATEST. Those latest-version values come from ./scripts/get-version.sh, and the Makefile errors out if either is empty. The practical consequence is that get.docker.com and test.docker.com serve generated copies of install.sh with the channel and version metadata baked in. The stable channel installs the latest stable Docker CE release; the test channel installs from the test channel. Running sh install.sh from a clone of the repository installs the latest from the stable channel, per the README. Nothing here pins a specific version for you.

Installing Docker with the Script: A First Run

The README gives the canonical invocation for the stable channel. The script is downloaded to a file first, run, and then removed, which keeps a copy of what executed on disk while it runs.

curl -fsSL https://get.docker.com -o get-docker.sh
sh get-docker.sh
rm get-docker.sh

After the script finishes, the docker command should be available on the machine. If you want the test channel instead, the README points at test.docker.com and names the downloaded file test-docker.sh:

curl -fsSL https://test.docker.com -o test-docker.sh
sh test-docker.sh
rm test-docker.sh

For work on the script itself, the README says running it from a source checkout installs the latest from the stable channel:

sh install.sh

If you are changing the script rather than using it, the repository has a lint step. The Makefile runs ShellCheck in a container, with SC1091, SC1117, SC2317, and SC2329 excluded, over the generated files in build/test and build/stable.

make shellcheck

There is also a make test target that runs the generated install scripts inside containers, using ubuntu:22.04 by default and passing the VERSION and CHANNEL variables through. The README does not document a rollback path, so plan for a rebuild if an install goes wrong.

Where the Convenience Script Is the Wrong Tool

The first limitation is stated by the project itself: this is not a production deployment mechanism. If your provisioning pipeline needs a pinned Docker version, a checksum you verified against a release artifact, or a repeatable result six months from now, the script works against you, because it installs the latest release at the moment it runs. The second limitation is platform. Despite the search interest in Docker on macOS and Windows, this repository is a Linux installer. There is no macOS or Windows path in install.sh, and the README points readers to the per-distribution install instructions for anything more thorough. If you are on Docker Desktop, this repository is not the thing you are looking for. The third limitation is distro coverage. The README refers to "the supported linux distros" without listing them in the text; the authoritative list lives in install.sh and in the linked install instructions. Running the script on an unsupported distribution is not a supported path. Finally, the repository is maintained solely by Docker, Inc., so there is no community fork policy to fall back on if you need a behaviour the maintainers will not add.

The Real Alternative: Repository Packages from docs.docker.com

The alternative the README itself names is the manual, per-distribution installation documented at docs.docker.com/engine/install. The difference is not cosmetic. The script resolves the latest version for you and installs it in one pass; the manual path has you configure the Docker repository for your distribution, then install a specific docker-ce package version through your package manager. That gives you a version you can write down, a package manager that can upgrade or remove it, and an audit trail of what was installed. The cost is more steps and a per-distribution procedure instead of one command. For a laptop, the script wins on time. For a fleet, the manual path wins on reproducibility, and it is the path Docker, Inc. directs production users toward in the same README that hosts the script.

Maintenance, Licensing, and What You Are Taking On

The repository is not archived, and the last push was on 2026-09-09, which is recent enough that the project is being touched. That does not change the README's production warning, and it does not turn the script into a versioned release artifact. The repository has no published GitHub releases, so the script's content is effectively whatever is on the default branch at build time, plus the generated files the Makefile produces. Upgrades are therefore implicit: rerun the script and you get the current latest. If you need to know what changed between two runs, the repository's diff.sh and the commit history are where you look. On licensing, docker/docker-install is under the Apache License, Version 2.0, with the full text in LICENSE. The README also carries a legal notice: use and transfer of Docker may be subject to restrictions by the United States and other governments, and the README places responsibility for compliance on you. That is a notice to read, not a legal opinion, and it is separate from the Apache-2.0 grant covering the script itself.

Editorial conclusion

Use docker/docker-install when you need Docker running on a throwaway VM, a CI runner, or a laptop you are about to rebuild, and you accept that the script installs the latest Docker CE release rather than a pinned version. Do not use it as your production provisioning path: the README states it is not recommended to depend on the script for deployment to production systems, and it does not cover Windows or macOS at all. Before you adopt it anywhere, check the supported distro list in the repository's install.sh and read the install instructions at docs.docker.com/engine/install for your distribution, because that is the path Docker, Inc. points production users to.

Frequently asked questions

Official sources

1. docker/docker-install on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README