5 simple things you can do with GitHub Packages to level up your workflows

Whether you’re contributing to an open source project, building a personal project, or spinning up the next feature at your 9-to-5 job, finding (or building) the right packages is a core part of any development workflow.

Package managers and registries are nothing new. But using one often means integrating one more service into your repository and workflow. That’s why we introduced GitHub Packages in 2019 to build a package and container registry right into every public and private GitHub repository.

GitHub Packages connects to your industry and community-standard package managers including npm, Gradle, Maven, RubyGems, NuGet, and even Docker and OCI for containers to help centralize your development workflows on GitHub.

The net effect is that your packages live with your code—and that proximity is unique. It can also be incredibly helpful when it comes to offering a tighter integration. Need proof? Here are a few simple things you can do with GitHub Packages to level-up your workflows.

1. Bring your packages right next to your code

When you’re working on a project with dependencies, it’s important to make sure they’re easy to access, consume, and review. And since you often don’t have one package but many interconnected packages, having a registry that includes all your dependencies across t\he different technologies you’re using—well, it can simplify things a fair bit.

That’s even more important in an organization where you may have pre-approved packages you’ll need to use across any number of projects. Cue one of the big benefits of GitHub Packages: it lets you keep your packages right in your repository and organization. That means you have one less piece of infrastructure to worry about when you’re integrating things.

Let’s say, for instance, that you’re working on a project with code in your GitHub repository and packages on npm. That means you likely have a few different user credentials and permissions to keep straight. But with GitHub Packages, you can centralize your credentials and permissioning across your systems—and you don’t need to build out separate package registries and mirror your permissions across your systems and projects.

When you’re eventually consuming a package, having that close relationship between the packages and the code makes it simpler to know what you’re using and where it lives.

Pro tip: Packages works with a number of common package registries, making it easy to publish packages with your preferred tool of choice and host them right in your GitHub project.

Here’s one more helpful feature: Any package hosted on GitHub comes with download statistics and a complete history, which makes it easy to track its usage in your repository, organization, or across the broader open source GitHub ecosystem.

Learn about what GitHub Packages can do >

2. Host your container registry in your repository

Here’s something fun: GitHub Packages also supports Docker and OCI images in its own native container registry. So, if you’re using Docker or OCI in any one of your projects, you can publish and manage the entire process (and, even insert the entire process into your CI/CD pipeline via GitHub Actions, but more on that in the next section).

One of the advantages of doing this on GitHub is it makes it simpler to quickly provision containers with all your dependencies in place. Accordingly, if you have an organization with 50 projects, all of that can be published via the GitHub Container Registry.

The container registry also offers access policies and the ability to encourage the usage of a standardized base image throughout an organization. That makes easier to enforce permissioning and standardization across a project. The GitHub Container Registry also supports layer caching, which enables you to quickly spin up images in your CI/CD pipeline. Plus, the GitHub Container Registry comes with more fine-grained permissioning, which you can use to separate out permissions for a package from the permissions on the underlying source code to restrict who can publish their own containers.

And here’s something else: You can also anonymously access public container images—like our own super-linter. That makes it easier to use what you want on your terms.

Learn how to use GitHub Packages to host a container registry in your repositories >

Pro tip: If you’re using GitHub Enterprise Cloud, you can also create and use containers with internal visibility in your projects—and that means any members of your organization or at your company can quickly share data via containers. You can learn more in our Changelog.

3. Use GitHub Actions to automate how you manage packages and containers

When it comes to publishing and consuming packages and containers with GitHub Packages, you can manage everything via GitHub Actions. That means you can automate how your packages are consumed and plug them right into your CI/CD pipeline without doing anything special.

If you’re using packages across different systems and adding containers to the mix, the ability to automate what packages get consumed by which services can become really useful, really fast. That means that for any developer or team using GitHub Packages, they have all of their packages right in their repository, there’s no need to source them from different places, and they build automation workflows to consume and manage them at scale.

Learn more about publishing, consuming, and installing packages with GitHub Actions >

4. Use GITHUB_TOKEN to secure how you manage packages and containers with GitHub Actions

If you’re using GitHub Actions to automate package management across your projects, here’s something you should be doing right now: using GITHUB_TOKEN to reduce the attack surface of your development pipeline.

GITHUB_TOKEN is a special access token available with GitHub Actions. Each token is automatically generated for every job that needs authentication or installation access. And once that job is complete, the token automatically expires to reduce any possible risk exposure.

Put more simply: When you run a workflow, the token only exists until that workflow is completed and then it’s deleted. In other solutions, you might have a token that exists for a longer period of time—and if you don’t rotate that token, it may expire and break things.

The GitHub token in an action workflow can by default publish to GitHub Packages. The net benefit is you have a much more secure system when you use GITHUB_TOKEN and reduce your attack surface area.

Learn how to use GITHUB_TOKEN in your workflows >

5. Create a private GitHub repository with a private package registry

A free GitHub account gives you unlimited public package hosting on any public repository. But GitHub Packages also works on private repositories for free with 500MB of storage and 1GB of transfer (that’s enough storage to host 331,000 pages of YAML, assuming we did our math right).

Packages on GitHub inherit the visibility and permissions of the repository they’re stored under, and that means that you immediately have a private package registry on any private repository you spin up.

The net benefit: You can create a private repository with private packages and never have to worry about them getting shared publicly.

Learn more about using private packages on GitHub >

Start using GitHub Packages

GitHub Packages are available in any organization on GitHub and can be leveraged across any repository within a given organization. To get started, check out our GitHub Docs.

Written by

Tina Heidinger

@tinaheidinger