A local action is easier to control, because its code lives in your own repository and changes go through your pull request review. A Marketplace action is someone else's code that you reference from outside. Local actions trade convenience for upkeep, and some automated checks skip them, so review them deliberately.
What a local action is
A local action is stored in the same repository as the workflow, in a folder, and referenced with a path instead of an owner and repository name. It has the same metadata file as any action and can be JavaScript, a container, or composite steps. A Marketplace action sits in its own public repository and is referenced by owner, name and a version reference.
What changes for security
| Question | Local action | Marketplace action |
|---|---|---|
| Who can change the code? | Anyone who can merge to your repository | The maintainer of another repository |
| Where is it reviewed? | In your pull requests | Only when you review a version bump |
| Can a tag move under you? | No tag, the code is in your commit | Yes, unless you pin to a full SHA |
| Can a rename or deletion break you? | No | Yes, GitHub does not redirect calls to a renamed action |
| Do update tools cover it? | No, they ignore it | Yes |
| Can it use pre steps? | No, runs.pre is not supported for local actions | Yes |
The first row is the main gain. With a local action the code is part of your history, and the review you already do for application code applies. The second gain is stability: no outside owner can alter what runs.
What local actions do not fix
GitHub's guidance says Dependabot ignores locally referenced actions and reusable workflows. So version updates and alerts do not cover them, and the actions your local action calls inside may go unchecked. If your local action is composite and uses third party actions, those nested references still need pinning and review. See do composite actions pin the actions they call inside.
A local action also inherits the same trust problem in one case: a pull request. If a workflow checks out the code from an untrusted pull request and then runs a local action from that checkout, the contributor controls the action. Keep privileged workflows from running local actions taken from untrusted code.
When local is the right call
- Shared steps used across several workflows in one repository, such as setting up tools or running your standard checks.
- Steps that touch credentials, where you want the code under your review rules.
- Cases where a third-party action does something small that you could write yourself in a few lines.
Choose Marketplace actions when the problem is complex and well maintained, such as a setup step for a language runtime, and pin them and review bumps. A middle path is a fork in your organization, covered in should you fork a third-party action.
Protect the folder
Whichever you choose, treat the actions folder and the workflows folder as sensitive. Use code owners so changes need approval from a named reviewer, as GitHub's guidance describes. See CODEOWNERS for workflow files.
Quick check
Is a local action automatically safe?
No. It is only as safe as your review of it and anything it calls. It removes the outside maintainer from the picture, not the need to read the code.
Do local actions need pinning?
The local reference is tied to the commit being run, so there is nothing to pin. Pin any third-party actions the local action calls.
Sources
- GitHub Docs: Secure use reference
- GitHub Docs: Metadata syntax for GitHub Actions
- GitHub Docs: Renaming a repository
Last reviewed: 19 October 2026.
