GitHub Actions makes workflow dependency lockfiles generally available

GitHub made workflow lockfiles generally available for GitHub Actions.

**Dek:** Maintainers can keep readable action tags in workflows while GitHub runs the commits recorded in a lockfile. The release adds a practical way to review dependency updates alongside ordinary code changes.

GitHub made Actions workflow dependency lockfiles generally available on October 28 for its Free, Team and Enterprise Cloud plans, including Enterprise Cloud with data residency. The feature lets a workflow keep a familiar tag or branch reference while the platform runs the exact commit recorded in the lockfile. It addresses a familiar problem in continuous integration: a workflow can look unchanged in a repository while an upstream tag has moved. [GitHub changelog](https://github.blog/changelog/2026-10-28-github-actions-workflow-lockfiles-are-generally-available/)

What changes when a workflow opts in

GitHub supports onboarding a workflow individually. Once it is onboarded, each workflow dependency must be in the lockfile and Actions runs the recorded commit. The CLI extension can generate the lockfile and accompanying workflow changes for review. It can also check for stale lockfiles without rewriting the files, which lets teams use the same check in continuous integration. A repository with several workflows can start with one and observe the update process before enforcing the policy more widely. [GitHub changelog](https://github.blog/changelog/2026-10-28-github-actions-workflow-lockfiles-are-generally-available/) · [CLI extension](https://github.com/github/gh-actions-lock)

Dependabot version updates also cover the matching lockfile entries for onboarded workflows. When Dependabot proposes changing an action version, GitHub says it regenerates the corresponding entry in the same pull request without extra configuration. That brings the visible workflow reference and the actual execution commit into one review. Enterprise, organization and repository administrators can use a Require lockfile policy to enforce adoption. [GitHub changelog](https://github.blog/changelog/2026-10-28-github-actions-workflow-lockfiles-are-generally-available/)

Reproducibility and trust remain separate questions

A lockfile provides a repeatable choice of revision. Reviewing that revision still matters, especially when a third-party action can read repository contents, publish packages or reach deployment credentials. A maintainer assessing an update should understand which code revision changed, what the action does and which permissions the workflow gives it. That review protects against a different problem from upstream version drift.

An acceptance test can rerun a representative workflow at the locked revision, verify that a normal dependency update changes both expected files, and check that the stale-file check fails without rewriting source. Teams can then decide which workflow policies to enforce and who reviews changes to privileged actions. The new mechanism makes those decisions easier to carry through a routine pull request.