The permissions for packages can be scoped either to a user or an organization or to a repository.
Granular permissions for user/organization-scoped packages
Packages with granular permissions are scoped to a personal user or organization account. You can change the access control and visibility of the package separately from a repository that is connected (or linked) to a package.
The following GitHub Packages registries support granular permissions.
- Container registry
- npm registry
- NuGet registry
- RubyGems registry
Permissions for repository-scoped packages
A repository-scoped package inherits the permissions and visibility of the repository that owns the package. You can find a package scoped to a repository by going to the main page of the repository and clicking the Packages link to the right of the page. For more information, see "Connecting a repository to a package."
The following GitHub Packages registries only support repository-scoped permissions.
-
Docker registry (
docker.pkg.github.com
) -
Apache Maven registry
-
Gradle registry
For other registries, you can choose to allow packages to be scoped to a user or an organization, or linked to a repository.
Visibility and access permissions for container images
If you have admin permissions to a container image, you can set the access permissions for the container image to private or public. Public images allow anonymous access and can be pulled without authentication or signing in via the CLI.
As an admin, you can also grant access permissions for a container image that are separate from the permissions you've set at the organization and repository levels.
For container images published and owned by a personal account, you can give any person an access role. For container images published and owned by an organization, you can give any person or team in the organization an access role.
If you are using a GitHub Actions workflow to manage your container images, you can grant an access role to the repository the workflow is stored in by using the Actions access option in the package's settings. For more information, see "Ensuring workflow access to your package."
Permission | Access description |
---|---|
Read | Can download package. Can read package metadata. |
Write | Can upload and download this package. Can read and write package metadata. |
Admin | Can upload, download, and manage this package. Can read and write package metadata. Can delete and restore packages. |
Note: The ability for GitHub Actions workflows to delete and restore packages using the REST API is currently in public beta and subject to change.
For more information, see "Configuring a package's access control and visibility."
About scopes and permissions for package registries
GitHub Packages only supports authentication using a personal access token (classic). For more information, see "Creating a personal access token."
To use or manage a package hosted by a package registry, you must use a personal access token (classic) with the appropriate scope, and your personal account must have appropriate permissions.
For example:
- To download and install packages from a repository, your personal access token (classic) must have the
read:packages
scope, and your user account must have read permission. - To delete a package on GitHub Enterprise Cloud, your personal access token (classic) must at least have the
delete:packages
andread:packages
scope. Therepo
scope is also required for repo-scoped packages. For more information, see "Deleting and restoring a package."
Scope | Description | Required permission |
---|---|---|
read:packages | Download and install packages from GitHub Packages | read |
write:packages | Upload and publish packages to GitHub Packages | write |
delete:packages | Delete packages from GitHub Packages | admin |
repo | Upload and delete packages (along with write:packages , or delete:packages ) | write or admin |
Note: The ability for GitHub Actions workflows to delete and restore packages using the REST API is currently in public beta and subject to change.
When you create a GitHub Actions workflow, you can use the GITHUB_TOKEN
to publish, install, delete, and restore packages in GitHub Packages without needing to store and manage a personal access token.
For more information, see:
- "Configuring a package’s access control and visibility"
- "Publishing and installing a package with GitHub Actions"
- "Creating a personal access token"
- "Available scopes"
About repository transfers
You can transfer a repository to another user or organization account. For more information, see "Transferring a repository."
When you transfer a repository, GitHub may transfer the packages associated with the repository, depending on the registry the packages belong to.
- For registries that support granular permissions, packages are scoped to a user or organization account, and the account associated with the package does not change when you transfer a repository. If you have linked a package to a repository, the link is removed when you transfer the repository to another user, and any codespaces or GitHub Actions workflows associated with the repository will lose access to the package. For the list of these registries, see "Granular permissions for user/organization-scoped packages."
- For registries that only support repository-scoped permissions, packages are published directly to repositories, and GitHub transfers the packages associated with a repository as part of the repository transfer. All billable usage associated with the packages will subsequently be billed to the new owner. If the previous repository owner is removed as a collaborator on the repository, they may no longer be able to access the packages associated with the repository. For the list of these registries, see "Permissions for repository-scoped packages."
Maintaining access to packages in GitHub Actions workflows
To ensure your workflows will maintain access to your packages, ensure that you're using the right access token in your workflow and that you've enabled GitHub Actions access to your package.
For more conceptual background on GitHub Actions or examples of using packages in workflows, see "Managing GitHub Packages using GitHub Actions workflows."
Access tokens
Note: The ability for GitHub Actions workflows to delete and restore packages using the REST API is currently in public beta and subject to change.
- To publish, install, delete, and restore packages associated with the workflow repository, use
GITHUB_TOKEN
. - To install packages associated with other private repositories that
GITHUB_TOKEN
can't access, use a personal access token (classic)
For more information about GITHUB_TOKEN
used in GitHub Actions workflows, see "Authentication in a workflow."
GitHub Actions access for container images
To ensure your workflows have access to your container image, you must enable GitHub Actions access to the repositories where your workflow is run. You can find this setting on your package's settings page. For more information, see "Ensuring workflow access to your package."