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.Impact
The “Initialize Containers” step in GitHub Actions is where service containers are pulled and started. With container caching, this step drops from over a minute to about a second. Before: 1m 20s to initialize containers
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.Availability
Docker container caching is in private beta. To enable it for your organization, reach out to [email protected].Monitoring usage
You can see storage usage for your Docker container sticky disk on the Sticky Disks page in the Blacksmith dashboard.Pricing
Docker container caching is powered by sticky disks and charged at $0.50/GB/mo. For details, see our pricing page.FAQ
What is the eviction policy?
What is the eviction policy?
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.