Documentation structure for LLMs (llms.txt)

CircleCI remote Docker images support policy

Cloud Server v4+

Overview

This document outlines the CircleCI Remote Docker Image release, update, and deprecation policy. This policy applies to all CircleCI remote Docker images built for the remote Docker feature (setup_remote_docker).

Release policy

The CircleCI remote Docker images are based on our Linux VM images with Docker installed. This setup enables the execution of Docker commands within jobs using the Docker executor in a remote environment.

We aim to support the latest three versions of the Docker Engine that are classified as within Security Support status.

Remote Docker images will be updated when a patch version is released upstream. Tags will be redirected to the updated images automatically as described in the Tagging section of this document. We will announce these releases on our Discuss Forum.

Tagging

We support various tags for the remote Docker environment to allow you to choose the type of remote Docker environment you require.

For the latest major version of Docker:

  • default: This image is the current stable image. Jobs will default to this if no tag is specified.

  • edge: This tag is reserved for previews of new releases, which will initially point to this tag. The tag may include incremental updates relative to the current quarterly image release, which may change without notice, and is not recommended for production CI workloads.

For the previous major version of Docker, we support a single tag following the format of dockerXX, for example, docker27 for Docker 27. This tag will point to the latest patch version of the major release, and will be updated if any patch versions are issued upstream. We recommend using the default version.

Critical CVE patches

When critical CVEs are disclosed around the operating system or software stack of this image, we will investigate the impact this has on the image within the CircleCI execution environment. If customers are impacted by these CVEs we will push a patch fix to the released image(s), this image will supersede the original image. These patches will not include major OS updates. Patches will contain only patch OS updates.

Bug reports, issues, and PRs

You can file a support ticket with CircleCI Support for any issues or bugs found with the remote Docker images. Our support team will be able to escalate issues internally to the correct engineering team and provide updates on the issue.

Image lifespan / EOL

Image lifespan will generally follow the support status of Docker Engine by Docker. Once a new major version of Docker is released, we will begin the deprecation process of the oldest version that we support and schedule it to be removed. This allows us to maintain three versions of Docker Engine effectively.

Current Deprecation:

Version Support

Docker 26

docker26 tag is maintained for Docker 26 support

Docker 27

docker27 tag is maintained for Docker 27 support

Docker 28

Set to default and edge tags. docker28 tag is maintained for Docker 28 as default tag as well.

Docker 29

docker29 tag is maintained for Docker 29 support

Example: When Docker 29 is made default:

When we previously attempted to set Docker 29 as the default, we found that some convenience images (cimg images) experienced compatibility issues the Docker 29 daemon. Jobs using these images with Docker 29 would fail. Docker 28 passes all our tests including with those cimg images, so it is the safe choice for an interim default. We are working on updated cimg images that will be compatible with Docker 29, and once those are available we will move the default to Docker 29.

Version Support

Docker 26

Deprecated and removed

Docker 27

docker27 tag kept until next cycle

Docker 28

Moved from default and edge tags to docker28 tag only

Docker 29

Set to default and edge tags. With docker29 tag for pinning Docker version.

When an image is selected for deprecation and removal, we will create an announcement on our Discuss forum and along with additional outreach where possible.

We will also plan brownouts to ensure users are aware of the approaching removal of deprecated images. Generally, we will aim to start an EOL process within 3 months of a new version release

Exceptions

​​At any time, we reserve the right to work outside of the information in this document if the circumstances require. In the event that we are required to make an exception to the policy, we will aim to provide as much notice and clarity as possible. In these cases, an announcement will be posted on our Discuss Forum, along with additional outreach, such as an email notice, where possible.