Do GitHub Actions secrets move when you consolidate repositories?

It depends how you move. A repository transfer keeps its secrets, webhooks and deploy keys. Merging history into a monorepo keeps none of them, because secrets belong to the repository, not to the commits. List every secret before the move, recreate each at the narrowest scope, and rotate values as you go.

Two kinds of move

GitHub's transfer documentation says that if a transferred repository contains webhooks, services, secrets, or deploy keys, they remain associated after the transfer. That is the easy case, and it applies when you keep the repository and change its owner.

A monorepo migration is the other case. You copy history into an existing repo. Nothing in the settings of the source repo comes along: no secrets, no environments, no webhooks, no deploy keys, no branch rules. Workflows that ran fine before will fail on the first run with an empty value where a secret used to be.

The three scopes to inventory

GitHub documents secrets at three levels: repository, environment and organization.

• Repository secrets are available to workflows in that repo. The secure-use guidance warns that any user with write access to a repository has read access to all secrets configured in it.
• Environment secrets are available only to jobs that reference the environment. If the environment requires approval, a job cannot read them until a required reviewer approves.
• Organization secrets can be limited by policy to chosen repositories. Check that the new monorepo is on the allowed list, or the workflow gets nothing.

Steps

1. For each source repo, list secret names at all three levels. The values are not readable, so record names, purpose and owner.
2. Mark which secrets are still used. Search the workflow files for each name. Dead secrets should not migrate.
3. Group by blast radius. A secret that deploys to production should not become a repository-wide secret in a repo that now has hundreds of writers.
4. Recreate production secrets as environment secrets, with required reviewers on the environment. The deployments documentation allows up to six reviewers and an option to prevent self-review.
5. Rotate while you recreate. You are already touching every value, and the old repo's copy will linger until you delete it.
6. Run each workflow once on a branch before you cut over.

Prefer no secret at all

Where a workflow only needs a cloud credential, GitHub's OpenID Connect support lets it request a short-lived token instead of storing a long-lived one. That changes what you must migrate: a trust policy instead of a secret. See OIDC trust policies after repo consolidation.

Clean up the source

Once the monorepo runs, remove secrets from the old repos. An archived repository with live secrets is still a target. The wider checklist is in decommission old repositories after a monorepo migration.

Safeguard's policies, gates and guardrails and its compliance evidence automation can help you show that deployment controls stayed in place across the move.

Quick check

Sources

• GitHub Docs: Transferring a repository
• GitHub Docs: Using secrets in GitHub Actions
• GitHub Docs: Deployments and environments
• GitHub Docs: Secure use reference

Last reviewed: 19 October 2026.