GitHub Puts Actions Workflow Dependency Lockfiles in Public Preview, With a gh actions-lock Extension and a Require Lockfile Policy
GitHub's October 14 changelog says Actions workflow dependency lockfiles are in public preview; the pre-1.0 gh actions-lock extension writes .github/workflows/actions.lock.
Overview
GitHub says workflow dependency lockfiles for GitHub Actions are now in public preview. In a changelog entry dated October 14, 2026, GitHub states that the feature is available on “GitHub Enterprise Cloud, GitHub Enterprise Cloud with data residency, Team, and Free plans.” The entry also carries an editor’s note, dated the same day, saying it “Updated which plans have access to this public preview.” The changelog does not say what the earlier plan list was.
What GitHub Describes
The changelog gives its motivation: “Tags and branches can move after you review a workflow, so a later run might execute different code.” A lockfile is meant to let a workflow keep tag or branch references while running the commits that were recorded when the lockfile was generated, according to the same entry. GitHub also cautions that “Locking does not determine whether the dependency itself is safe, so review dependencies before locking them.”
The tooling is a GitHub CLI extension, gh actions-lock. Per the changelog, it can generate .github/workflows/actions.lock “with reviewable commits for actions and their transitive dependencies, as well as reusable workflow dependencies.” The changelog lists four capabilities:
- Pinning dependencies in the lockfile.
- Adopting locking gradually: workflows are onboarded individually, and “Once onboarded, a workflow must have lockfile entries for its dependencies, and GitHub Actions runs the recorded commits.”
- Keeping runs consistent even if a tag or branch moves.
- Checking for stale lockfiles, which the changelog describes as verifying the lockfile is up to date “without modifying files, including in a CI check.”
A “Require lockfile” policy is “also available in public preview,” and the changelog says enterprise, organization and repository administrators can use it to require workflows to use lockfiles at those levels.
Dependabot and the Docs Page
Per the changelog, when Dependabot opens a version update for an action in an already-onboarded workflow, it also regenerates the matching lockfile entry in the same pull request. The entry says this works “without additional configuration.”
GitHub’s documentation page on workflow dependency lockfiles adds detail the changelog omits. It says the lockfile “should never be edited by hand” and that the locked commit “must exist within a branch of the source repository.” In the docs’ example file, each dependency records a ref, a commit, an owner_id and a repo_id; the docs say GitHub Actions uses the two numeric IDs to confirm at run time that the repository behind the name is still the one that was locked. The example file shows version: 'v0.0.2'.
The docs also state the coverage rules. A lockfile covers workflows in its own repository and extends to transitive dependencies, “except for dependencies of reusable workflow calls”; a reusable workflow is covered by the lockfile of the repository where it is defined. This differs in emphasis from the changelog’s wording that the generated lockfile includes “reusable workflow dependencies,” and the two pages do not explain how the statements fit together.
The docs also address commit SHA pinning. They say GitHub “has historically recommended pinning third-party actions to a full-length commit SHA in your workflow files,” and that for repositories adopting a lockfile, SHA pinning within workflow files “is no longer necessary.” The stated reason is that the lockfile supports transitive dependencies, makes workflow files easier to read and records the source repository’s identity.
Preview Caveats in the Repository
The README of the github/gh-actions-lock repository, read on October 15, 2026, is more cautious than the changelog. It says the project “is pre-1.0 and under active development” and that the “lockfile format, command flags, and behavior may change without notice between releases.” It states that “GitHub Enterprise Server (GHES) is not supported,” and that support is “best-effort and community-based.” The docs page likewise labels the feature “in public preview and subject to change.”
The README lists commands beyond the changelog’s summary. gh actions-lock --verify checks without writing, while --verify-local runs offline and, in the README’s words, only checks “that every ref has a lockfile entry, not that the entries are trustworthy.” It adds that pins to branches or partial versions such as main or v4 “are not advanced when upstream moves,” and that --relock re-resolves refs that have legitimately moved.
The README’s limitations section says workflows in the lockfile “cannot use local-path actions,” calling this “a short-term gap.” Elsewhere the same README says same-repository ./ composite action references are converted to $/ references on fix runs, and that $/ references need no lockfile entry. The README does not reconcile the two statements.
What the Sources Do Not Say
- None of the three pages states a general-availability date or pricing for the feature.
- The changelog does not say whether the Require lockfile policy is off by default or how it interacts with existing workflows. The pages read do not state a default.
- The pages do not report any adoption figures or independent testing; every claim here is GitHub’s own description of its feature.
- The changelog thanks Andrew Nesbitt, François Proulx, Jesse Houwing and William Woodruff for collaboration “over the past year”; it does not describe what each contributed.