Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.blacksmith.sh/llms.txt

Use this file to discover all available pages before exploring further.

​
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, Blacksmith pre-hydrates commonly used containers onto the runners. When your workflow starts, the containers are already there, so the pull and extraction steps become a no-op. Container caching is not limited to GitHub Actions service containers. Any container pulled during a job — whether through docker 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 container images across workflow runs. The first time a container is pulled and extracted, it gets stored on a sticky disk for your repository. On subsequent runs, the container is already on the runner.

​
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.

​
Availability

Docker container caching is available to organizations with runners in US West and EU West. It is not available in EU Central.
You can enable Container Caching for your organization by filing a support issue from the Blacksmith dashboard.

​
Monitoring usage

You can see storage usage for your Docker container sticky disk under the Storage > Sticky Disks tab in the Blacksmith dashboard.

​
Pricing

Docker container caching is powered by Sticky Disks. You are billed for the sticky disk storage used by the cache at $0.50/GB/mo. For details, see our pricing page.

​
FAQ

Docker container caches are stored on a single sticky disk at the organization level and are automatically evicted after 7 days of inactivity. Each time a workflow uses a cached container, the “last used” timestamp resets. As long as your workflows use the cached containers at least once within 7 days, they stay available.