GitHub Actions Workflow Lockfiles Reach General Availability, Pinning Exact Commits Behind Readable References

GitHub announced on October 28, 2026 that GitHub Actions workflow dependency lockfiles are generally available. They are offered on GitHub Enterprise Cloud, GitHub Enterprise Cloud with data residency, and the Team and Free plans. A lockfile lets a workflow keep readable tag and branch references while running the exact commits that were locked, even if those references later move. The changelog entry says the general release brings the capabilities introduced in the public preview.

The problem is mutable references. A workflow that says it uses an action at a tag or branch runs whatever commit that name points to when the job starts. If the name moves, the job quietly runs different code. A lockfile records the commits behind those names, for the actions and for their transitive dependencies, which are the actions those actions use in turn. GitHub's `gh actions-lock` extension for the GitHub CLI generates the file at `.github/workflows/actions.lock`. The workflow file keeps its readable references, and the lockfile decides what actually runs.

Adoption can be gradual. Teams onboard workflows one at a time. Once a workflow is onboarded, GitHub Actions requires every dependency of that workflow to appear in the lockfile and runs its recorded commit. Adoption therefore does not have to cover every workflow at once. For teams that want a firm rule, enterprise, organization and repository administrators can use a Require lockfile policy to enforce adoption. The changelog does not describe what happens to workflows that break the policy, so administrators should test the policy on a small scope before applying it broadly.

Two features keep the file honest over time. When Dependabot opens a version update for an action in an onboarded workflow, it also regenerates the matching lockfile entry in the same pull request, with no extra configuration. This saves a separate regeneration step. Teams can also check for stale lockfiles. The check verifies that the lockfile is up to date without changing any files, so it can run as a CI check and fail a build when someone edits a workflow but forgets the lockfile.

GitHub is clear about the limit. Lockfiles help protect against unexpected dependency changes, but they do not decide whether a dependency is safe. A locked commit that was malicious or vulnerable when it was locked stays malicious or vulnerable. GitHub advises reviewing dependencies before locking them. A lockfile therefore moves the review point earlier, to the moment of locking and each Dependabot update, rather than replacing review. The entry also does not say anything about self-hosted runners or GitHub Enterprise Server, so teams there should check the documentation.

To start, install the extension from the gh-actions-lock repository, generate the lockfile, then review and commit both the lockfile and the workflow changes. GitHub points to its documentation on workflow dependency lockfiles and to a community discussion and issue tracker for feedback.

For teams that rely on third-party actions, the practical gain is a reviewable record of exactly which code a pipeline ran, plus a way to make drift visible in a pull request.