Docker’s convenience script installs Docker Engine and its standard command-line components on a supported Linux host with one installer. Use it for a disposable lab, development workstation, or test system—not production—and download the script first so you can inspect and preview its actions before granting it root privileges.
Production guardrail: Docker does not recommend the convenience script for production. For a managed server, configure Docker’s package repository and control package versions and upgrades through the host’s package manager.
Docker convenience script: quick install sequence
curl -fsSL https://get.docker.com -o get-docker.sh
less get-docker.sh
sudo sh ./get-docker.sh --dry-run
sudo sh ./get-docker.shThe default channel is stable. The script currently installs Docker Engine, Docker CLI, containerd, runc, Docker Buildx, and the Docker Compose plugin. Do not shorten this to a direct curl | sudo sh pipeline: keeping the downloaded file gives you an opportunity to inspect and dry-run exactly what will receive elevated privileges.
Should you use the convenience script?
| Scenario | Recommended method | Why |
|---|---|---|
| Disposable lab or short-lived test VM | Convenience script | Fast setup with the latest stable packages |
| Development workstation | Convenience script can be reasonable | Useful when you accept automatic repository and package configuration |
| Production or regulated host | Official package repository | Supports deliberate version selection, change review, and repeatable upgrades |
| Existing Docker installation | Host package manager | The script is not designed to upgrade an existing installation |
| Unsupported distribution or derivative | Distribution-specific Docker instructions | Automatic detection may not map the host to a supported repository |
Before you install Docker Engine
- Use a supported 64-bit Linux distribution and architecture.
- Prefer a new lab or test host with no existing Docker packages or custom repository configuration.
- Confirm that you have
rootorsudoaccess and outbound HTTPS access to Docker’s repositories. - Review proxy, DNS, firewall, and change-control requirements before the installer modifies package sources.
- Understand that published container ports can interact with host firewall rules differently than ordinary host services.
Record the operating system, version, architecture, and whether a Docker command already exists:
. /etc/os-release && printf '%s %s\n' "$ID" "$VERSION_ID"
uname -m
command -v docker || trueIf Docker is already present, stop and determine how it was installed. Re-running the convenience script can reset repository configuration or leave dependencies at unexpected versions.
Step 1: Download and inspect the installer
curl -fsSL https://get.docker.com -o get-docker.shOpen the downloaded file and review it before execution:
less get-docker.shDocker publishes the installer source in the official docker-install repository. Confirm that the local script’s behavior, package sources, and supported distribution logic fit the host you are building.
Step 2: Preview the installation with –dry-run
sudo sh ./get-docker.sh --dry-runThe dry run shows the planned repository and package-manager commands without performing the installation. Review:
- the detected Linux distribution and release;
- the Docker repository and release channel;
- the packages that would be installed;
- whether the commands match your organization’s proxy, repository, and change policies.
A successful dry run is not a production approval. It only confirms what the current script intends to execute on this host.
Step 3: Install Docker
sudo sh ./get-docker.shBy default, the script uses Docker’s stable channel and installs the latest applicable packages. That convenience is also the reason it is a poor production lifecycle method: a future run can select a newer major release than your automation or applications have validated.
Step 4: Verify the service and components
sudo systemctl status docker --no-pager
sudo docker version
sudo docker info
sudo docker run --rm hello-world
docker compose version
docker buildx versionThe checks should show a running Docker daemon, matching client and server information, a successful hello-world container, and available Compose and Buildx plugins. If the service is installed but inactive on a systemd host, review the installer output and the distribution’s Docker instructions before enabling it:
sudo systemctl enable --now dockerUseful convenience-script options
| Option | Purpose |
|---|---|
--dry-run | Print the planned commands without installing Docker |
--version <version> | Request a specific Docker version supported by the current repository |
--channel stable | Use the stable release channel; this is the default |
--channel test | Use a channel that includes prereleases; use only for intentional testing |
--setup-repo | Configure Docker’s package repository without installing the packages |
--no-autostart | Install without automatically starting the daemon when the current script and init system support that behavior |
Options can change as the installer evolves. Review the current script and its --help output before depending on an option in automation.
How to upgrade after using the script
Use the host’s package manager for later Docker upgrades. Docker’s documentation states that there is no advantage to re-running the convenience script and that doing so can cause problems when repositories already exist. For a long-lived host, follow the distribution-specific Docker Engine installation and upgrade instructions and select versions deliberately.
Common installation problems
| Symptom | Likely cause | Next check |
|---|---|---|
The script warns that docker already exists | An installation is already present | Cancel, inventory the packages and repositories, and upgrade with the package manager |
curl cannot download the script | DNS, proxy, certificate, or outbound HTTPS failure | Validate name resolution, time, trusted certificates, proxy settings, and access to Docker domains |
| The distribution is unsupported or misdetected | The host or derivative does not map cleanly to a Docker repository | Use Docker’s distribution-specific installation instructions |
| Cannot connect to the Docker daemon | The service is stopped or the client is using the wrong socket or context | Check systemctl status docker, docker context ls, and the installer output |
Permission denied on /var/run/docker.sock | The current user is not authorized to access the root-owned daemon socket | Use sudo temporarily and review Docker’s non-root or rootless guidance |
| A published container port bypasses expected host filtering | Docker’s packet-filtering and NAT rules interact with the host firewall | Review Docker’s firewall guidance before exposing services |
Security and firewall guardrails
The installer needs root privileges, configures package sources, installs dependencies, and may start a privileged daemon. Treat it like any other administrative change: inspect the artifact, use a controlled source, test in a disposable environment, and record what was installed.
Running Docker commands without sudo by adding a user to the docker group is convenient, but Docker warns that membership grants root-level privileges. Review the official Linux post-installation guidance and consider rootless mode when the security model calls for it.
Docker also creates packet-filtering and NAT rules for bridge networks. In particular, published container traffic can be diverted before ordinary ufw rules apply. Validate the host’s exposure model against Docker’s packet-filtering and firewall documentation.
Use the repository method for production
For production, configure Docker’s official package repository, pin or select approved versions, test upgrades, and let the operating system’s package manager own the lifecycle. The convenience script is best treated as a transparent bootstrap aid for low-risk environments, not as an enterprise patching strategy.
Bottom line
The safe convenience-script workflow is straightforward: confirm the host is appropriate, download the script, inspect it, run --dry-run, install only on a lab or development system, verify the daemon and plugins, and use the package manager for every later upgrade.