cache-to: type=gha and restore them with cache-from: type=gha. No special runner label or setting is needed.
Configure your workflow
First connect your repository to Celesto. For a repository with aDockerfile at its root, save this workflow as .github/workflows/docker-cache.yml:
.github/workflows/docker-cache.yml
mode=maxsaves the layers from every build stage, not only the final image.scopenames the cache. Give each image its own scope so builds don’t overwrite each other’s layers.
cache-from and cache-to with type=gha, you only need to switch runs-on to a Celesto runner. This works when the workflow uses the cache address the runner provides. Workflows that set their own cache address are an exception. The first Celesto run misses because GitHub keeps its caches in a separate store.
Saved layers count toward the same storage limits as your other caches and follow the same access rules and 7-day expiry. Large layer caches can cause older dependency caches to be removed sooner. A restore can still miss, so compare complete build time with and without the cache.
The public cache acceptance suite includes Docker workflows you can run to check caching in your own repository. It checks that caching works, not how much time it saves.
Verify reuse
Run the workflow successfully, then rerun it with the same Dockerfile and build inputs. Check the build logs for steps markedCACHED, and compare the complete job duration. The first run saves layers for later builds.
For image builds and database services, see Docker builds and services.