docker/docker-install: The Official Docker Installation Script for Linux

What the Script Does and Its Intended Scope

The docker/docker-install repository contains the shell scripts served at two URLs: `get.docker.com` for the stable channel and `test.docker.com` for the test channel. The README states clearly that the script is "a convenience for quickly installing the latest Docker-CE releases on the supported linux distros" and that it "is not recommended to depend on this script for deployment to production systems."

That warning is important. The script does not pin a specific Docker version, does not configure TLS for the Docker daemon, does not set up log rotation, and does not configure any system hardening. It automates the package-manager steps that would otherwise be done manually: adding the Docker apt or rpm repository, importing the signing key, and running the install command for the detected distribution.

The primary audience is a developer who wants Docker running on a fresh Linux VM or cloud instance in under two minutes, or someone following a tutorial that says "install Docker." For anything that will run in production, Docker's own documentation (`docs.docker.com/engine/install/`) provides distribution-specific procedures with more control.

The repository is solely maintained by Docker, Inc., as the README states.

Stable vs. Test Channel: Two URLs, Two Scripts

The repository hosts scripts for two channels. The stable channel script is served at `get.docker.com`. The test channel script is served at `test.docker.com`. Both scripts live in the repository and are built from the same `install.sh` source using the `Makefile`, which substitutes the channel name into a `DEFAULT_CHANNEL_VALUE` variable during the build.

The stable channel installs the latest stable Docker CE release. The test channel installs pre-release builds. The README also mentions `sh install.sh` run directly from the source repository as a way to install from the stable channel.

The Makefile records two version variables, `STABLE_LATEST` and `TEST_LATEST`, fetched from the `scripts/get-version.sh` helper at build time. These are embedded into the built scripts as `LOAD_SCRIPT_STABLE_LATEST` and `LOAD_SCRIPT_TEST_LATEST`. The built scripts are placed under `build/stable/` and `build/test/` respectively.

If you want to install a specific version of Docker CE rather than the latest, this script is not the right tool. The distro-specific instructions on the Docker documentation site describe how to list available versions and pin one.

Running the Install Script

The README documents three equivalent ways to run the stable install:

From `get.docker.com`:

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

From `test.docker.com` (test channel builds):

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

Direct from the source repository:

sh install.sh

The `curl -fsSL` flags mean: `-f` fail silently on server errors, `-s` suppress progress output, `-S` show errors even with `-s`, and `-L` follow redirects. The script is downloaded first and then run, rather than piped directly to `sh`. This is good practice: it lets you inspect the script before executing it as root.

The script detects the Linux distribution and version, selects the appropriate package manager (apt-get for Debian/Ubuntu, rpm for RHEL/CentOS families), adds the Docker repository, and installs `docker-ce`, `docker-ce-cli`, `containerd.io`, and related packages.

To verify the script's syntax and logic before running on a target system, the `Makefile` provides a `shellcheck` target:

make shellcheck

This runs `koalaman/shellcheck` in Docker against the built scripts, checking for common shell scripting issues. The Makefile excludes specific ShellCheck codes: SC1091, SC1117, SC2317, and SC2329.

Supported Distributions and rootless Mode

The repository also contains `rootless-install.sh`, built alongside `install.sh` by the same Makefile rule. Rootless mode allows Docker to run containers without requiring root privileges. The README does not describe the rootless script's use in detail, but its presence in the build pipeline means it is served alongside the standard script.

The repository's testing target runs the script against `ubuntu:22.04` by default (`TEST_IMAGE?=ubuntu:22.04` in the Makefile), but the Makefile accepts a `TEST_IMAGE` variable to test against other distributions. Supported distributions include Debian, Ubuntu, and various RHEL-based distros; the precise list is defined in the `install.sh` source, which detects the OS via `/etc/os-release` and similar files.

For distributions not covered by the script, the Docker documentation site provides instructions for manual installation. Attempting to run the script on an unsupported distribution will result in an error from the detection logic.

Why Not to Use This Script for Production

The README's production warning comes from several concrete gaps that the script does not address.

First, the script always installs the latest available version. Reproducible infrastructure requires pinned versions. An automated provisioner running this script today and again in three months might install different Docker versions, introducing behavioral differences.

Second, the script does not configure the Docker daemon beyond defaults. Production environments often need custom daemon options: specific storage drivers, log drivers with rotation settings, TLS configuration for remote socket access, or resource limits. The README links to `docs.docker.com/engine/security/https/` as the reference for protecting the daemon socket with SSL.

Third, the legal notice in the README references US export controls. Docker's use and transfer may be subject to US government restrictions. The README includes a pointer to the Bureau of Industry and Security (`bis.doc.gov`) for details. This applies to the Docker software itself, not just this install script, but it is worth noting for deployments outside the US.

An alternative for production use is Ansible's community.docker collection, which wraps the same package installation steps in idempotent, version-controlled playbooks. Another option is using cloud-specific packages like the official Docker packages in AWS Linux's Amazon Linux Extras. Both provide better version control than the convenience script.

Repository Structure and Maintenance

The repository's top-level entries are: `install.sh` (the main script), `rootless-install.sh`, a `Makefile` for building and testing, a `scripts/` directory with helper scripts, a `diff.sh` for comparing builds, and a `verify-docker-install` file.

The repository has no GitHub releases. Changes are tracked by commits to the master branch. The last push was on 2026-09-09. Docker, Inc. maintains it as the authoritative source for the scripts behind `get.docker.com`.

The license is Apache License, Version 2.0. Security issues should be reported privately to `[email protected]` rather than as public GitHub issues, as the README instructs. Docker has historically acknowledged and thanked security reporters and notes the possibility of future bounty programs.

Editorial conclusion

The docker/docker-install script is the right tool for quickly setting up Docker CE on a Linux machine for development or experimentation. The README explicitly warns against using it for production deployments, recommending the distribution-specific instructions at `docs.docker.com/engine/install/` instead. If you are provisioning servers in a repeatable way, use the full package manager path documented for your distro. The script is Apache-2.0-licensed and maintained by Docker, Inc., with the last push on 2026-09-09.

Frequently asked questions

Official sources

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