About permissions for GitHub Packages

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 GitHub Packages registries below use repository-scoped permissions:

npm registry
RubyGems registry
Apache Maven registry
NuGet registry

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.

Currently, only the Container registry offers granular permissions for your container image packages.

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 user 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.

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, delete, and manage this package. Can read and write package metadata. Can grant package permissions.

For more information, see "Configuring a package's access control and visibility."

About scopes and permissions for package registries

To use or manage a package hosted by a package registry, you must use a token with the appropriate scope, and your user account must have appropriate permissions.

For example:

To download and install packages from a repository, your token must have the read:packages scope, and your user account must have read permission.
To delete a package on GitHub, your token must at least have the delete:packages and read:packages scope. The repo 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

When you create a GitHub Actions workflow, you can use the GITHUB_TOKEN to publish and install packages in GitHub Packages without needing to store and manage a personal access token.

For more information, see:

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

To publish 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

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."