[code]smithWe are currently rolling out Docker container caching to all organizations, enabled by default.
Overview
Many GitHub Actions workflows use service containers to run databases, caches, and other dependencies alongside jobs. Every run, these containers get pulled from a registry and extracted before the job can start. With Docker container caching, the images your workflows use are kept warm across runs. When your workflow starts, the images are already on the runner, so the pull and extraction steps become a no-op. Container caching is not limited to GitHub Actions service containers. Any image pulled during a job — whether throughdocker pull, docker run, docker compose, or any other Docker command — is automatically cached and available on subsequent runs.
How it works
Docker container caching uses sticky disks to persist Docker’s image store across workflow runs. Each organization gets one cache disk per region and architecture (x64 and ARM), shared across all of its repositories. This org-level sharing means a common image only needs to be pulled once, and every workflow in your organization benefits from it. When a job starts, the runner mounts your organization’s cache disk as Docker’s local image store, so cached images are immediately available — no pull, no extraction. When the job finishes, any newly pulled images are merged back into the shared cache so future jobs can use them. Tagged images, digest-pinned images (image@sha256:...), and images pulled by Docker Compose are all cached.
Concurrent jobs can safely share the cache: each job works against its own copy-on-write view of the disk, and updates are merged so one job never removes images another job needs.
Impact
The “Initialize containers” step in GitHub Actions is where service containers are pulled and started. With container caching, this step drops from minutes to seconds. The biggest wins come from large or uncommon images, where registry pull and extraction time dominates. Once the cache is warm, pull time drops to near zero.Availability
Docker container caching is available in all Blacksmith regions: US West, EU West, and EU Central. We are gradually enabling container caching for all organizations.Pricing
Docker container caching is free. Unlike other sticky disk products, you are not billed for the storage used by the container cache. Other sticky disk usage — such as Docker layer caching and custom sticky disks — is billed as before; see our pricing page.FAQ
What is the eviction policy?
What is the eviction policy?
Cached images are automatically evicted after 8 days of inactivity. Each time a workflow uses a cached image, its “last used” timestamp resets. As long as your workflows use an image at least once within 8 days, it stays cached. Weekly workflows, releases, and maintenance jobs stay warm.
Do I need to change my workflows?
Do I need to change my workflows?
No. Container caching is fully transparent — there are no workflow changes, labels, or actions required. Jobs that don’t use containers are unaffected.
What about private images?
What about private images?
Private images work the same way: your job authenticates and pulls as usual on the first run, and the extracted image is cached on your organization’s disk for subsequent runs.