{"id":1191,"date":"2026-09-26T05:27:43","date_gmt":"2026-09-26T05:27:43","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/?p=1191"},"modified":"2026-09-26T05:27:46","modified_gmt":"2026-09-26T05:27:46","slug":"github-packages-complete-reference-guide-hands-on-tutorial","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/github-packages-complete-reference-guide-hands-on-tutorial\/","title":{"rendered":"GitHub Packages \u2014 Complete Reference Guide & Hands-On Tutorial"},"content":{"rendered":"\n
\n

Last Verified:<\/strong> September 2026
Scope:<\/strong> GitHub.com \/ GitHub Enterprise Cloud unless explicitly stated otherwise
Audience:<\/strong> Developers, DevOps engineers, platform engineers, administrators, architects, trainers, and engineering teams<\/p>\n<\/blockquote>\n\n\n\n

GitHub Packages is GitHub’s package-hosting platform. It lets teams publish, store, secure, discover, automate, and consume software packages and container images while keeping package ownership, source code, CI\/CD, permissions, security metadata, and billing close to the GitHub development workflow.<\/p>\n\n\n\n

This guide is organized as a progressive learning journey: concept \u2192 why \u2192 how \u2192 example \u2192 practice \u2192 real-world use case \u2192 best practices \u2192 troubleshooting<\/strong>.<\/p>\n\n\n\n

\n\n\n\n

1. What GitHub Packages Is<\/h2>\n\n\n\n

GitHub Packages is a set of package registries integrated with GitHub. A package is a distributable software artifact such as a container image, an npm library, a Java artifact, a NuGet package, or a Ruby gem.<\/p>\n\n\n\n

Why teams use it<\/h3>\n\n\n\n

A typical software organization produces more than source code. It also produces reusable libraries, container images, command-line tools, SDKs, internal frameworks, application dependencies, and release artifacts. Those outputs need a trusted place to live.<\/p>\n\n\n\n

GitHub Packages solves that problem by giving teams a registry that is integrated with:<\/p>\n\n\n\n

    \n
  • GitHub repositories<\/li>\n\n\n\n
  • GitHub organizations and teams<\/li>\n\n\n\n
  • GitHub Actions<\/li>\n\n\n\n
  • GitHub permissions and tokens<\/li>\n\n\n\n
  • GitHub Releases<\/li>\n\n\n\n
  • Supply-chain security features<\/li>\n\n\n\n
  • Artifact attestations<\/li>\n\n\n\n
  • Linked artifacts<\/li>\n\n\n\n
  • REST APIs and webhooks<\/li>\n\n\n\n
  • Billing and usage controls<\/li>\n<\/ul>\n\n\n\n

    Core lifecycle<\/h3>\n\n\n\n
    flowchart LR\n    A[Source Code] --> B[Build]\n    B --> C[Test]\n    C --> D[Package]\n    D --> E[Authenticate]\n    E --> F[Publish]\n    F --> G[Registry]\n    G --> H[Install \/ Pull]\n    H --> I[Application or Deployment]\n    I --> J[Observe \/ Audit]\n    J --> K[Update \/ Retire]\n<\/code><\/pre>\n\n\n\n
    The important idea is that a registry sits between producers<\/strong> and consumers<\/strong>. Producers create immutable versions; consumers fetch known versions through an authenticated and governed channel.<\/p>\n\n\n\n
    GitHub Packages vs GitHub Releases vs Actions artifacts<\/h3>\n\n\n\n
    Capability<\/th>GitHub Packages<\/th>GitHub Releases<\/th>GitHub Actions artifacts<\/th><\/tr><\/thead>
    Primary purpose<\/td>Dependency\/package distribution<\/td>Product release publishing<\/td>Temporary workflow outputs<\/td><\/tr>
    Typical consumers<\/td>Applications, builds, deployments<\/td>Humans and release automation<\/td>Workflow jobs and engineers<\/td><\/tr>
    Versioned package semantics<\/td>Yes<\/td>Release\/tag semantics<\/td>No package-manager semantics<\/td><\/tr>
    Package manager integration<\/td>Yes<\/td>No<\/td>No<\/td><\/tr>
    Container registry<\/td>Yes<\/td>No<\/td>No<\/td><\/tr>
    Long-term reusable dependency<\/td>Yes<\/td>Sometimes<\/td>Usually no<\/td><\/tr>
    CI intermediate file<\/td>Possible but not ideal<\/td>No<\/td>Yes<\/td><\/tr>
    Best example<\/td>ghcr.io\/acme\/api:1.4.2<\/code><\/td>v1.4.2<\/code> release + binaries<\/td>test reports, build outputs<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    A useful rule:<\/p>\n\n\n\n
      \n
    • Use\u00a0Packages<\/strong>\u00a0when another build, runtime, or developer will consume the artifact as a package.<\/li>\n\n\n\n
    • Use\u00a0Releases<\/strong>\u00a0when you are publishing a release event, release notes, and downloadable assets.<\/li>\n\n\n\n
    • Use\u00a0Actions artifacts<\/strong>\u00a0for workflow-produced files that are primarily tied to a workflow run.<\/li>\n<\/ul>\n\n\n\n
      \n\n\n\n
      2. Supported Registries and Permission Models<\/h2>\n\n\n\n
      GitHub Packages supports these principal registries:<\/p>\n\n\n\n
      Ecosystem<\/th>Registry \/ endpoint<\/th>Typical client<\/th>Permission model<\/th><\/tr><\/thead>
      Containers<\/td>ghcr.io<\/code><\/td>Docker \/ OCI clients<\/td>Granular user\/org scoped<\/td><\/tr>
      npm<\/td>npm.pkg.github.com<\/code><\/td>npm \/ Yarn<\/td>Granular user\/org scoped<\/td><\/tr>
      NuGet<\/td>nuget.pkg.github.com<\/code><\/td>dotnet<\/code> \/ NuGet CLI<\/td>Granular user\/org scoped<\/td><\/tr>
      RubyGems<\/td>rubygems.pkg.github.com<\/code><\/td>gem<\/code> \/ Bundler<\/td>Granular user\/org scoped<\/td><\/tr>
      Apache Maven<\/td>maven.pkg.github.com<\/code><\/td>Maven<\/td>Repository scoped<\/td><\/tr>
      Gradle<\/td>Maven-compatible GitHub Packages endpoint<\/td>Gradle<\/td>Repository scoped<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
      GitHub’s legacy Docker registry used docker.pkg.github.com<\/code>. It has been replaced by the Container registry at ghcr.io<\/code> and should be treated primarily as a migration\/backward-compatibility topic.<\/p>\n\n\n\n
      Granular packages vs repository-scoped packages<\/h3>\n\n\n\n
      This is one of the most important architectural distinctions in GitHub Packages.<\/p>\n\n\n\n
      Granular-permission packages<\/h4>\n\n\n\n
      Supported by:<\/p>\n\n\n\n
        \n
      • Container registry<\/li>\n\n\n\n
      • npm<\/li>\n\n\n\n
      • NuGet<\/li>\n\n\n\n
      • RubyGems<\/li>\n<\/ul>\n\n\n\n
        These packages can be scoped to a personal account or organization. Their visibility and access can be managed separately from a repository, although they can be connected to one.<\/p>\n\n\n\n
        Repository-scoped packages<\/h4>\n\n\n\n
        Supported by:<\/p>\n\n\n\n
          \n
        • Apache Maven<\/li>\n\n\n\n
        • Gradle<\/li>\n<\/ul>\n\n\n\n
          These packages inherit their repository’s permissions and visibility.<\/p>\n\n\n\n
          Package scope model<\/h3>\n\n\n\n
          flowchart TD\n    A[GitHub Package]\n    A --> B{Registry permission model}\n    B -->|Granular| C[User or Organization Scope]\n    C --> D[Optional repository connection]\n    C --> E[Independent Read \/ Write \/ Admin]\n    B -->|Repository scoped| F[Repository]\n    F --> G[Repository visibility]\n    F --> H[Repository permissions]\n<\/code><\/pre>\n\n\n\n
          \n\n\n\n
          3. Core Concepts and Terminology<\/h2>\n\n\n\n
          Term<\/th>Meaning<\/th><\/tr><\/thead>
          Package<\/td>A distributable software artifact managed by a registry<\/td><\/tr>
          Registry<\/td>Service that stores and distributes package versions<\/td><\/tr>
          Package manager<\/td>Client that publishes or installs packages<\/td><\/tr>
          Namespace<\/td>Owner\/name space used to prevent naming ambiguity<\/td><\/tr>
          Package owner<\/td>User, organization, or repository that controls package scope<\/td><\/tr>
          Version<\/td>A named package release such as 1.4.2<\/code><\/td><\/tr>
          Tag<\/td>A movable or human-friendly alias, especially common for containers<\/td><\/tr>
          Digest<\/td>Content-addressed immutable identifier, especially for OCI images<\/td><\/tr>
          Metadata<\/td>Description, source repository, license, tags, publication data, etc.<\/td><\/tr>
          Visibility<\/td>Public, private, or internal where supported<\/td><\/tr>
          Permission<\/td>Read, write, or admin access<\/td><\/tr>
          Repository connection<\/td>Association between a granular package and source repository<\/td><\/tr>
          Publisher<\/td>User or automation that creates a package version<\/td><\/tr>
          Consumer<\/td>Build, developer, service, or deployment that downloads the package<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
          Version vs tag vs digest<\/h3>\n\n\n\n
          For containers, these three terms must not be confused:<\/p>\n\n\n\n
            \n
          • Version<\/strong>: a package version as represented by GitHub’s package system.<\/li>\n\n\n\n
          • Tag<\/strong>: a friendly image reference such as\u00a01.8.0<\/code>,\u00a0main<\/code>, or\u00a0latest<\/code>.<\/li>\n\n\n\n
          • Digest<\/strong>: immutable content identifier such as\u00a0sha256:...<\/code>.<\/li>\n<\/ul>\n\n\n\n
            For production deployment, digest pinning is the strongest way to guarantee that the exact bytes tested are the bytes deployed.<\/p>\n\n\n\n
            \n\n\n\n
            4. Where Packages Appear in GitHub<\/h2>\n\n\n\n
            GitHub exposes packages from multiple contexts:<\/p>\n\n\n\n
            Organization packages<\/h3>\n\n\n\n
            Navigate to the organization and select Packages<\/strong>. This is the natural management surface for shared internal libraries and container images owned by an organization.<\/p>\n\n\n\n
            User packages<\/h3>\n\n\n\n
            A user’s profile can expose packages scoped to that user.<\/p>\n\n\n\n
            Repository packages<\/h3>\n\n\n\n
            A repository sidebar can show packages associated with that repository. For repository-scoped registries, the repository is the package’s permission boundary. For granular registries, the repository is a connection that can provide source metadata and optionally inherited access.<\/p>\n\n\n\n
            Package search and discovery<\/h3>\n\n\n\n
            Use organization, user, or repository Packages surfaces to browse packages you can access. From a package landing page, follow source-repository and version links to understand ownership and usage. For private\/internal packages, discovery is permission-aware: a package that exists but is outside your access boundary may not be visible as a normal browsable asset.<\/p>\n\n\n\n
            Package landing page<\/h3>\n\n\n\n
            A package page can expose:<\/p>\n\n\n\n
              \n
            • Description<\/li>\n\n\n\n
            • Installation and usage instructions<\/li>\n\n\n\n
            • Source repository<\/li>\n\n\n\n
            • Version history<\/li>\n\n\n\n
            • Publication dates<\/li>\n\n\n\n
            • Download activity<\/li>\n\n\n\n
            • Metadata<\/li>\n\n\n\n
            • Package settings<\/li>\n\n\n\n
            • Access configuration<\/li>\n<\/ul>\n\n\n\n
              \n\n\n\n
              5. Access Control, Visibility, and Permissions<\/h2>\n\n\n\n
              Package roles<\/h3>\n\n\n\n
              Role<\/th>Typical capability<\/th><\/tr><\/thead>
              Read<\/td>View metadata and download\/install<\/td><\/tr>
              Write<\/td>Read plus upload\/publish<\/td><\/tr>
              Admin<\/td>Publish, delete\/manage package, change access, grant permissions<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
              For organization-scoped granular packages, access can be granted to individuals or teams. Organization owners also have administrative control.<\/p>\n\n\n\n
              Visibility<\/h3>\n\n\n\n
              Depending on the registry and account context, packages can be:<\/p>\n\n\n\n
                \n
              • Public<\/strong>\u00a0\u2014 intended for broad consumption.<\/li>\n\n\n\n
              • Private<\/strong>\u00a0\u2014 restricted to explicitly authorized users\/repositories.<\/li>\n\n\n\n
              • Internal<\/strong>\u00a0\u2014 organization\/enterprise-oriented visibility where supported by granular registries and plan context.<\/li>\n<\/ul>\n\n\n\n
                For most GitHub Packages registries, even public packages require package-client authentication. The major exception is the Container registry: public container images can be pulled anonymously.<\/p>\n\n\n\n
                Permission inheritance<\/h3>\n\n\n\n
                When a granular package is connected to a repository, GitHub can let the package inherit repository permissions. Organizations can also disable automatic inheritance for newly published packages.<\/p>\n\n\n\n
                Use inheritance when repository membership should define package access. Use explicit granular access when one package is shared across many repositories or teams.<\/p>\n\n\n\n
                Repository transfer behavior<\/h3>\n\n\n\n
                Repository transfers affect the two package models differently:<\/p>\n\n\n\n
                  \n
                • Granular packages:<\/strong>\u00a0the package remains owned by its user\/organization scope. A repository connection can be removed during transfer, and workflows\/Codespaces can lose access.<\/li>\n\n\n\n
                • Repository-scoped packages:<\/strong>\u00a0the package follows the repository and its ownership\/permission model.<\/li>\n<\/ul>\n\n\n\n
                  This is why migration planning must include package ownership, not only repository ownership.<\/p>\n\n\n\n
                  \n\n\n\n
                  6. Authentication and Authorization<\/h2>\n\n\n\n
                  Authentication answers who are you?<\/strong> Authorization answers what may you do?<\/strong><\/p>\n\n\n\n
                  Personal access token (classic)<\/h3>\n\n\n\n
                  GitHub Packages package-client authentication uses a personal access token (classic)<\/strong> with package scopes.<\/p>\n\n\n\n
                  Scope<\/th>Purpose<\/th>Typical minimum package permission<\/th><\/tr><\/thead>
                  read:packages<\/code><\/td>Download\/install<\/td>Read<\/td><\/tr>
                  write:packages<\/code><\/td>Publish\/upload<\/td>Write<\/td><\/tr>
                  delete:packages<\/code><\/td>Delete<\/td>Admin<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                  For organizations using SAML SSO, the token may also need authorization for that organization.<\/p>\n\n\n\n
                  GITHUB_TOKEN<\/code><\/h3>\n\n\n\n
                  Inside GitHub Actions, prefer the repository’s automatically generated GITHUB_TOKEN<\/code> where possible.<\/p>\n\n\n\n
                  Example minimum workflow permissions for publishing:<\/p>\n\n\n\n
                  permissions:\n  contents: read\n  packages: write\n<\/code><\/pre>\n\n\n\n
                  For a consumer workflow that only installs a package:<\/p>\n\n\n\n
                  permissions:\n  contents: read\n  packages: read\n<\/code><\/pre>\n\n\n\n
                  For cross-repository use of granular packages, grant the consumer repository access under the package’s Manage Actions access<\/strong> settings.<\/p>\n\n\n\n
                  Important distinction: package clients vs REST API tokens<\/h3>\n\n\n\n
                  Do not generalize token rules blindly.<\/p>\n\n\n\n
                    \n
                  • Package-manager authentication is documented around PAT classic and\u00a0GITHUB_TOKEN<\/code>\u00a0in Actions.<\/li>\n\n\n\n
                  • Some Packages REST API endpoints also support GitHub App user\/installation access tokens or fine-grained token types as documented per endpoint.<\/li>\n<\/ul>\n\n\n\n
                    Always follow the authentication section of the exact API endpoint you are using.<\/p>\n\n\n\n
                    Secure token handling<\/h3>\n\n\n\n
                    Recommended:<\/p>\n\n\n\n
                      \n
                    • Prefer\u00a0GITHUB_TOKEN<\/code>\u00a0in Actions.<\/li>\n\n\n\n
                    • Use minimal permissions.<\/li>\n\n\n\n
                    • Store long-lived credentials in GitHub secrets or an external secret manager.<\/li>\n\n\n\n
                    • Rotate PATs.<\/li>\n\n\n\n
                    • Revoke unused credentials.<\/li>\n\n\n\n
                    • Avoid tokens in checked-in\u00a0.npmrc<\/code>,\u00a0settings.xml<\/code>,\u00a0nuget.config<\/code>,\u00a0Gemfile<\/code>, shell scripts, or Dockerfiles.<\/li>\n\n\n\n
                    • Treat self-hosted runners as part of your security boundary.<\/li>\n\n\n\n
                    • Pin third-party Actions to trusted commit SHAs for high-assurance release workflows.<\/li>\n<\/ul>\n\n\n\n
                      Avoid:<\/p>\n\n\n\n
                        \n
                      • Shared developer PATs<\/li>\n\n\n\n
                      • Admin-scoped tokens for read-only consumers<\/li>\n\n\n\n
                      • Printing tokens in diagnostic output<\/li>\n\n\n\n
                      • Publishing from untrusted pull-request contexts<\/li>\n\n\n\n
                      • Reusing the same token across unrelated systems<\/li>\n<\/ul>\n\n\n\n
                        \n\n\n\n
                        7. Package Lifecycle<\/h2>\n\n\n\n
                        A healthy package lifecycle is deliberate and auditable.<\/p>\n\n\n\n
                        stateDiagram-v2\n    [*] --> Build\n    Build --> Test\n    Test --> Publish: pass\n    Test --> Build: fail\/fix\n    Publish --> Active\n    Active --> NewVersion\n    NewVersion --> Active\n    Active --> Deprecated: ecosystem supports deprecation\n    Active --> Deleted\n    Deleted --> Restored: within restore rules\n    Deleted --> [*]: retention window expires\n<\/code><\/pre>\n\n\n\n
                        Typical lifecycle stages<\/h3>\n\n\n\n
                          \n
                        1. Build source.<\/li>\n\n\n\n
                        2. Run unit\/integration\/security tests.<\/li>\n\n\n\n
                        3. Choose version.<\/li>\n\n\n\n
                        4. Authenticate.<\/li>\n\n\n\n
                        5. Publish package.<\/li>\n\n\n\n
                        6. Verify package metadata.<\/li>\n\n\n\n
                        7. Grant consumer access.<\/li>\n\n\n\n
                        8. Install\/pull by consumers.<\/li>\n\n\n\n
                        9. Publish new versions rather than overwriting releases.<\/li>\n\n\n\n
                        10. Retire old versions based on retention policy.<\/li>\n\n\n\n
                        11. Restore only when supported and still inside the restoration window.<\/li>\n<\/ol>\n\n\n\n
                          Semantic Versioning<\/h3>\n\n\n\n
                          For libraries, Semantic Versioning is a useful convention:<\/p>\n\n\n\n
                            \n
                          • MAJOR<\/code>: incompatible change<\/li>\n\n\n\n
                          • MINOR<\/code>: backward-compatible feature<\/li>\n\n\n\n
                          • PATCH<\/code>: backward-compatible fix<\/li>\n<\/ul>\n\n\n\n
                            Example:<\/p>\n\n\n\n
                            2.7.4\n\u2502 \u2502 \u2514\u2500 patch\n\u2502 \u2514\u2500\u2500\u2500 minor\n\u2514\u2500\u2500\u2500\u2500\u2500 major\n<\/code><\/pre>\n\n\n\n
                            Pre-releases can use identifiers such as:<\/p>\n\n\n\n
                            2.8.0-alpha.1\n2.8.0-beta.2\n2.8.0-rc.1\n<\/code><\/pre>\n\n\n\n
                            Container image tags can mirror SemVer, but production deployment should prefer immutable digests.<\/p>\n\n\n\n
                            \n\n\n\n
                            8. Getting Started: Publish a Container to GHCR<\/h2>\n\n\n\n
                            Containers are the easiest way to see the complete GitHub Packages workflow end to end.<\/p>\n\n\n\n
                            Prerequisites<\/h3>\n\n\n\n
                              \n
                            • GitHub account<\/li>\n\n\n\n
                            • Repository such as\u00a0acme\/hello-api<\/code><\/li>\n\n\n\n
                            • Docker installed locally, or GitHub Actions<\/li>\n\n\n\n
                            • Permission to publish to the target namespace<\/li>\n<\/ul>\n\n\n\n
                              Example application<\/h3>\n\n\n\n
                              Create a minimal Dockerfile<\/code>:<\/p>\n\n\n\n
                              FROM nginx:alpine\nCOPY .\/index.html \/usr\/share\/nginx\/html\/index.html\n\nLABEL org.opencontainers.image.source=\"https:\/\/github.com\/acme\/hello-api\"\nLABEL org.opencontainers.image.description=\"Hello API training image\"\nLABEL org.opencontainers.image.licenses=\"MIT\"\n<\/code><\/pre>\n\n\n\n
                              Create index.html<\/code>:<\/p>\n\n\n\n
                              <h1>Hello from GitHub Container Registry<\/h1>\n<\/code><\/pre>\n\n\n\n
                              Authenticate locally<\/h3>\n\n\n\n
                              Export a PAT classic with the minimum required scopes:<\/p>\n\n\n\n
                              export CR_PAT=\"YOUR_TOKEN\"\necho \"$CR_PAT\" | docker login ghcr.io -u YOUR_GITHUB_USERNAME --password-stdin\n<\/code><\/pre>\n\n\n\n
                              Build and tag<\/h3>\n\n\n\n
                              docker build -t hello-api:1.0.0 .\ndocker tag hello-api:1.0.0 ghcr.io\/acme\/hello-api:1.0.0\n<\/code><\/pre>\n\n\n\n
                              Push<\/h3>\n\n\n\n
                              docker push ghcr.io\/acme\/hello-api:1.0.0\n<\/code><\/pre>\n\n\n\n
                              Verify<\/h3>\n\n\n\n
                              docker pull ghcr.io\/acme\/hello-api:1.0.0\n<\/code><\/pre>\n\n\n\n
                              For a public container, an anonymous pull can work without a registry login.<\/p>\n\n\n\n
                              Pull by digest<\/h3>\n\n\n\n
                              After publishing, capture the image digest and deploy the immutable reference:<\/p>\n\n\n\n
                              docker pull ghcr.io\/acme\/hello-api@sha256:REPLACE_WITH_DIGEST\n<\/code><\/pre>\n\n\n\n
                              Expected result<\/h3>\n\n\n\n
                              The package appears under the owning user\/organization’s Packages page. If source metadata is configured correctly, the package page can link back to its repository.<\/p>\n\n\n\n
                              \n\n\n\n
                              9. GitHub Container Registry Deep Dive<\/h2>\n\n\n\n
                              What GHCR stores<\/h3>\n\n\n\n
                              GHCR supports Docker Image Manifest V2 Schema 2 and OCI image specifications. It can host Docker and OCI images, including foreign layers such as Windows image layers.<\/p>\n\n\n\n
                              Common reference structure<\/h3>\n\n\n\n
                              ghcr.io\/OWNER\/IMAGE:TAG\n<\/code><\/pre>\n\n\n\n
                              Examples:<\/p>\n\n\n\n
                              ghcr.io\/acme\/payments-api:2.3.1\nghcr.io\/acme\/payments-api:sha-4c912ab\nghcr.io\/acme\/payments-api@sha256:...\n<\/code><\/pre>\n\n\n\n
                              OCI metadata<\/h3>\n\n\n\n
                              Useful OCI annotations\/labels include:<\/p>\n\n\n\n
                              org.opencontainers.image.source\norg.opencontainers.image.description\norg.opencontainers.image.licenses\norg.opencontainers.image.revision\norg.opencontainers.image.version\n<\/code><\/pre>\n\n\n\n
                              These improve traceability and package presentation.<\/p>\n\n\n\n
                              Tagging strategy<\/h3>\n\n\n\n
                              A strong release can publish several tags pointing to the same digest:<\/p>\n\n\n\n
                              2.4.1\n2.4\n2\nsha-a1b2c3d\n<\/code><\/pre>\n\n\n\n
                              Use latest<\/code> only if your team defines exactly what it means. Never use latest<\/code> as the sole production deployment reference.<\/p>\n\n\n\n
                              Multi-platform images<\/h3>\n\n\n\n
                              With Buildx, one logical image tag can point to an OCI image index containing multiple platform manifests.<\/p>\n\n\n\n
                              docker buildx build \\\n  --platform linux\/amd64,linux\/arm64 \\\n  -t ghcr.io\/acme\/api:2.4.1 \\\n  --push .\n<\/code><\/pre>\n\n\n\n
                              flowchart TD\n    A[ghcr.io\/acme\/api:2.4.1] --> B[OCI Image Index]\n    B --> C[linux\/amd64 manifest]\n    B --> D[linux\/arm64 manifest]\n<\/code><\/pre>\n\n\n\n
                              Container registry best practices<\/h3>\n\n\n\n
                                \n
                              • Use multi-stage builds.<\/li>\n\n\n\n
                              • Use small, maintained base images.<\/li>\n\n\n\n
                              • Add OCI source\/license metadata.<\/li>\n\n\n\n
                              • Publish immutable release tags.<\/li>\n\n\n\n
                              • Add commit-SHA tags for traceability.<\/li>\n\n\n\n
                              • Capture and promote digests.<\/li>\n\n\n\n
                              • Generate provenance attestations.<\/li>\n\n\n\n
                              • Generate an SBOM.<\/li>\n\n\n\n
                              • Scan dependencies and base images.<\/li>\n\n\n\n
                              • Use least-privilege workflow permissions.<\/li>\n<\/ul>\n\n\n\n
                                \n\n\n\n
                                10. npm Registry<\/h2>\n\n\n\n
                                GitHub’s npm registry is used for Node.js packages. It supports granular user\/organization-scoped permissions.<\/p>\n\n\n\n
                                Package naming<\/h3>\n\n\n\n
                                GitHub Packages npm packages are scoped packages. A typical package name is:<\/p>\n\n\n\n
                                {\n  \"name\": \"@acme\/shared-utils\",\n  \"version\": \"1.2.0\",\n  \"description\": \"Shared utilities for Acme services\",\n  \"repository\": {\n    \"type\": \"git\",\n    \"url\": \"git+https:\/\/github.com\/acme\/shared-utils.git\"\n  }\n}\n<\/code><\/pre>\n\n\n\n
                                Configure .npmrc<\/code><\/h3>\n\n\n\n
                                @acme:registry=https:\/\/npm.pkg.github.com\n\/\/npm.pkg.github.com\/:_authToken=${NODE_AUTH_TOKEN}\n<\/code><\/pre>\n\n\n\n
                                Do not commit a literal token into .npmrc<\/code>.<\/p>\n\n\n\n
                                Publish locally<\/h3>\n\n\n\n
                                export NODE_AUTH_TOKEN=\"YOUR_PAT_CLASSIC\"\nnpm publish\n<\/code><\/pre>\n\n\n\n
                                Install<\/h3>\n\n\n\n
                                npm install @acme\/shared-utils@1.2.0\n<\/code><\/pre>\n\n\n\n
                                GitHub Actions publishing<\/h3>\n\n\n\n
                                name: Publish npm package\n\non:\n  release:\n    types: [published]\n\njobs:\n  publish:\n    runs-on: ubuntu-latest\n    permissions:\n      contents: read\n      packages: write\n\n    steps:\n      - uses: actions\/checkout@v6\n\n      - uses: actions\/setup-node@v7\n        with:\n          node-version: '20.x'\n          registry-url: 'https:\/\/npm.pkg.github.com'\n          scope: '@acme'\n\n      - run: npm ci\n      - run: npm test\n      - run: npm publish\n        env:\n          NODE_AUTH_TOKEN: ${{ secrets.GITHUB_TOKEN }}\n<\/code><\/pre>\n\n\n\n
                                npm use case<\/h3>\n\n\n\n
                                A company maintains a shared TypeScript library consumed by ten internal services. The package is owned by the organization, write access is limited to the platform team, and each consuming repository receives read access through Manage Actions access.<\/p>\n\n\n\n
                                npm gotchas<\/h3>\n\n\n\n
                                  \n
                                • Ensure the package is scoped to the expected user\/organization.<\/li>\n\n\n\n
                                • Ensure\u00a0.npmrc<\/code>\u00a0routes only the intended scope to GitHub Packages.<\/li>\n\n\n\n
                                • Avoid routing all npm traffic to a private registry unless that is explicitly intended.<\/li>\n\n\n\n
                                • Keep npmjs.org and GitHub Packages sources clear to avoid dependency confusion and accidental publication.<\/li>\n<\/ul>\n\n\n\n
                                  \n\n\n\n
                                  11. Apache Maven Registry<\/h2>\n\n\n\n
                                  Maven packages on GitHub Packages are repository-scoped. This means the package follows repository permissions rather than having an independent granular permission model.<\/p>\n\n\n\n
                                  Maven coordinates<\/h3>\n\n\n\n
                                  A Maven artifact is identified by:<\/p>\n\n\n\n
                                  groupId:artifactId:version\n<\/code><\/pre>\n\n\n\n
                                  Example:<\/p>\n\n\n\n
                                  com.acme:payments-sdk:2.1.0\n<\/code><\/pre>\n\n\n\n
                                  pom.xml<\/code><\/h3>\n\n\n\n
                                  <project xmlns=\"http:\/\/maven.apache.org\/POM\/4.0.0\"\n         xmlns:xsi=\"http:\/\/www.w3.org\/2001\/XMLSchema-instance\"\n         xsi:schemaLocation=\"http:\/\/maven.apache.org\/POM\/4.0.0 https:\/\/maven.apache.org\/xsd\/maven-4.0.0.xsd\">\n  <modelVersion>4.0.0<\/modelVersion>\n\n  <groupId>com.acme<\/groupId>\n  <artifactId>payments-sdk<\/artifactId>\n  <version>2.1.0<\/version>\n\n  <distributionManagement>\n    <repository>\n      <id>github<\/id>\n      <name>GitHub Packages<\/name>\n      <url>https:\/\/maven.pkg.github.com\/acme\/payments-sdk<\/url>\n    <\/repository>\n  <\/distributionManagement>\n<\/project>\n<\/code><\/pre>\n\n\n\n
                                  settings.xml<\/code><\/h3>\n\n\n\n
                                  <settings xmlns=\"http:\/\/maven.apache.org\/SETTINGS\/1.0.0\">\n  <servers>\n    <server>\n      <id>github<\/id>\n      <username>${env.GITHUB_ACTOR}<\/username>\n      <password>${env.GITHUB_TOKEN}<\/password>\n    <\/server>\n  <\/servers>\n<\/settings>\n<\/code><\/pre>\n\n\n\n
                                  Publish<\/h3>\n\n\n\n
                                  mvn --batch-mode deploy\n<\/code><\/pre>\n\n\n\n
                                  Consume<\/h3>\n\n\n\n
                                  A consumer repository can configure the GitHub Packages Maven repository and add a dependency:<\/p>\n\n\n\n
                                  <dependency>\n  <groupId>com.acme<\/groupId>\n  <artifactId>payments-sdk<\/artifactId>\n  <version>2.1.0<\/version>\n<\/dependency>\n<\/code><\/pre>\n\n\n\n
                                  GitHub Actions<\/h3>\n\n\n\n
                                  name: Publish Maven package\n\non:\n  release:\n    types: [created]\n\njobs:\n  publish:\n    runs-on: ubuntu-latest\n    permissions:\n      contents: read\n      packages: write\n\n    steps:\n      - uses: actions\/checkout@v6\n\n      - uses: actions\/setup-java@v4\n        with:\n          distribution: temurin\n          java-version: '21'\n\n      - run: mvn --batch-mode verify\n      - run: mvn --batch-mode deploy\n        env:\n          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}\n<\/code><\/pre>\n\n\n\n
                                  Maven design implication<\/h3>\n\n\n\n
                                  Because Maven packages are repository-scoped, do not design access as though the package has independent organization-level ACLs. If many teams need the package, model the repository permissions accordingly.<\/p>\n\n\n\n
                                  \n\n\n\n
                                  12. Gradle Registry<\/h2>\n\n\n\n
                                  GitHub’s Gradle support uses Maven-format package publishing and is repository-scoped.<\/p>\n\n\n\n
                                  Groovy DSL example<\/h3>\n\n\n\n
                                  plugins {\n    id 'java-library'\n    id 'maven-publish'\n}\n\nversion = '1.3.0'\ngroup = 'com.acme'\n\npublishing {\n    publications {\n        mavenJava(MavenPublication) {\n            from components.java\n        }\n    }\n\n    repositories {\n        maven {\n            name = \"GitHubPackages\"\n            url = uri(\"https:\/\/maven.pkg.github.com\/acme\/shared-java\")\n            credentials {\n                username = System.getenv(\"GITHUB_ACTOR\")\n                password = System.getenv(\"GITHUB_TOKEN\")\n            }\n        }\n    }\n}\n<\/code><\/pre>\n\n\n\n
                                  Kotlin DSL example<\/h3>\n\n\n\n
                                  plugins {\n    `java-library`\n    `maven-publish`\n}\n\ngroup = \"com.acme\"\nversion = \"1.3.0\"\n\npublishing {\n    publications {\n        create<MavenPublication>(\"mavenJava\") {\n            from(components[\"java\"])\n        }\n    }\n\n    repositories {\n        maven {\n            name = \"GitHubPackages\"\n            url = uri(\"https:\/\/maven.pkg.github.com\/acme\/shared-java\")\n            credentials {\n                username = System.getenv(\"GITHUB_ACTOR\")\n                password = System.getenv(\"GITHUB_TOKEN\")\n            }\n        }\n    }\n}\n<\/code><\/pre>\n\n\n\n
                                  Publish<\/h3>\n\n\n\n
                                  .\/gradlew publish\n<\/code><\/pre>\n\n\n\n
                                  GitHub Actions<\/h3>\n\n\n\n
                                  name: Publish Gradle package\n\non:\n  release:\n    types: [created]\n\njobs:\n  publish:\n    runs-on: ubuntu-latest\n    permissions:\n      contents: read\n      packages: write\n\n    steps:\n      - uses: actions\/checkout@v6\n      - uses: actions\/setup-java@v4\n        with:\n          distribution: temurin\n          java-version: '21'\n\n      - name: Setup Gradle\n        uses: gradle\/actions\/setup-gradle@v4\n\n      - run: .\/gradlew test\n      - run: .\/gradlew publish\n        env:\n          GITHUB_ACTOR: ${{ github.actor }}\n          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}\n<\/code><\/pre>\n\n\n\n
                                  For high-assurance release pipelines, pin third-party actions to a reviewed commit SHA rather than a moving tag.<\/p>\n\n\n\n
                                  \n\n\n\n
                                  13. NuGet Registry<\/h2>\n\n\n\n
                                  GitHub Packages supports NuGet packages with granular user\/organization-scoped permissions.<\/p>\n\n\n\n
                                  Add a package source<\/h3>\n\n\n\n
                                  dotnet nuget add source \\\n  --username YOUR_GITHUB_USERNAME \\\n  --password YOUR_PAT_CLASSIC \\\n  --store-password-in-clear-text \\\n  --name github \\\n  \"https:\/\/nuget.pkg.github.com\/acme\/index.json\"\n<\/code><\/pre>\n\n\n\n
                                  The --store-password-in-clear-text<\/code> option is convenient for demonstrations but is a security tradeoff. In CI, prefer injected credentials and ephemeral runners.<\/p>\n\n\n\n
                                  Pack<\/h3>\n\n\n\n
                                  dotnet pack --configuration Release\n<\/code><\/pre>\n\n\n\n
                                  Publish<\/h3>\n\n\n\n
                                  dotnet nuget push \"bin\/Release\/Acme.Tools.1.0.0.nupkg\" \\\n  --api-key YOUR_PAT_CLASSIC \\\n  --source github\n<\/code><\/pre>\n\n\n\n
                                  Install<\/h3>\n\n\n\n
                                  dotnet add package Acme.Tools --version 1.0.0 --source github\n<\/code><\/pre>\n\n\n\n
                                  nuget.config<\/code> with source mapping<\/h3>\n\n\n\n
                                  Source mapping helps prevent dependency confusion by ensuring private package IDs resolve only from the intended source.<\/p>\n\n\n\n
                                  <?xml version=\"1.0\" encoding=\"utf-8\"?>\n<configuration>\n  <packageSources>\n    <add key=\"nuget.org\" value=\"https:\/\/api.nuget.org\/v3\/index.json\" \/>\n    <add key=\"github\" value=\"https:\/\/nuget.pkg.github.com\/acme\/index.json\" \/>\n  <\/packageSources>\n\n  <packageSourceMapping>\n    <packageSource key=\"nuget.org\">\n      <package pattern=\"*\" \/>\n    <\/packageSource>\n    <packageSource key=\"github\">\n      <package pattern=\"Acme.*\" \/>\n    <\/packageSource>\n  <\/packageSourceMapping>\n<\/configuration>\n<\/code><\/pre>\n\n\n\n
                                  Current size note<\/h3>\n\n\n\n
                                  GitHub documents that a NuGet .nupkg<\/code> archive for a package version must be smaller than 2.147 GB.<\/p>\n\n\n\n
                                  \n\n\n\n
                                  14. RubyGems Registry<\/h2>\n\n\n\n
                                  GitHub Packages supports Ruby gems with granular user\/organization-scoped permissions.<\/p>\n\n\n\n
                                  Prerequisites<\/h3>\n\n\n\n
                                  GitHub’s current documentation lists RubyGems 2.4.1+ and Bundler 1.6.4+ as minimums. In production, use a supported modern Ruby\/RubyGems\/Bundler toolchain.<\/p>\n\n\n\n
                                  Authenticate with RubyGems<\/h3>\n\n\n\n
                                  gem sources --add \\\n  https://YOUR_USERNAME:YOUR_PAT_CLASSIC@rubygems.pkg.github.com\/acme\/\n<\/code><\/pre>\n\n\n\n
                                  Authenticate with Bundler<\/h3>\n\n\n\n
                                  bundle config https:\/\/rubygems.pkg.github.com\/acme \\\n  YOUR_USERNAME:YOUR_PAT_CLASSIC\n<\/code><\/pre>\n\n\n\n
                                  Gem metadata<\/h3>\n\n\n\n
                                  Gem::Specification.new do |spec|\n  spec.name        = \"acme-tools\"\n  spec.version     = \"1.0.0\"\n  spec.summary     = \"Internal Acme Ruby utilities\"\n  spec.files       = Dir[\"lib\/**\/*\"]\n  spec.require_paths = [\"lib\"]\n  spec.metadata = {\n    \"github_repo\" => \"ssh:\/\/github.com\/acme\/acme-tools\"\n  }\nend\n<\/code><\/pre>\n\n\n\n
                                  Build and publish<\/h3>\n\n\n\n
                                  gem build acme-tools.gemspec\ngem push --key github \\\n  --host https:\/\/rubygems.pkg.github.com\/acme \\\n  acme-tools-1.0.0.gem\n<\/code><\/pre>\n\n\n\n
                                  Bundler consumption<\/h3>\n\n\n\n
                                  source \"https:\/\/rubygems.org\"\n\nsource \"https:\/\/rubygems.pkg.github.com\/acme\" do\n  gem \"acme-tools\", \"1.0.0\"\nend\n<\/code><\/pre>\n\n\n\n
                                  \n\n\n\n
                                  15. Connecting Packages to Repositories<\/h2>\n\n\n\n
                                  For granular registries, package ownership and repository ownership are separate concepts.<\/p>\n\n\n\n
                                  Why connect a package to a repository?<\/h3>\n\n\n\n
                                  A connection can provide:<\/p>\n\n\n\n
                                    \n
                                  • Source repository link<\/li>\n\n\n\n
                                  • README\/context on the package page<\/li>\n\n\n\n
                                  • Permission inheritance, if enabled<\/li>\n\n\n\n
                                  • Automatic Actions access from the linked repository<\/li>\n\n\n\n
                                  • Better provenance and discoverability<\/li>\n<\/ul>\n\n\n\n
                                    Manual connection<\/h3>\n\n\n\n
                                    Typical UI flow:<\/p>\n\n\n\n
                                      \n
                                    1. Open the package landing page.<\/li>\n\n\n\n
                                    2. Open\u00a0Package settings<\/strong>.<\/li>\n\n\n\n
                                    3. Find the repository connection area.<\/li>\n\n\n\n
                                    4. Choose\u00a0Connect repository<\/strong>.<\/li>\n\n\n\n
                                    5. Select the source repository.<\/li>\n\n\n\n
                                    6. Decide whether repository permissions should be inherited.<\/li>\n\n\n\n
                                    7. Verify Actions\/Codespaces access if needed.<\/li>\n<\/ol>\n\n\n\n
                                      Automatic container linkage<\/h3>\n\n\n\n
                                      OCI source metadata can establish repository context:<\/p>\n\n\n\n
                                      LABEL org.opencontainers.image.source=\"https:\/\/github.com\/acme\/payments-api\"\n<\/code><\/pre>\n\n\n\n
                                      Design pattern: one producer, many consumers<\/h3>\n\n\n\n
                                      flowchart LR\n    P[Producer repository] --> W[Build\/Test workflow]\n    W --> R[Organization package]\n    R --> C1[Consumer repo A]\n    R --> C2[Consumer repo B]\n    R --> C3[Consumer repo C]\n<\/code><\/pre>\n\n\n\n
                                      For this pattern, granular permissions are ideal: the package can remain organization-owned while individual repositories receive only read access.<\/p>\n\n\n\n
                                      \n\n\n\n
                                      16. GitHub Actions and GitHub Packages<\/h2>\n\n\n\n
                                      GitHub Actions is the preferred automation layer for build-test-publish workflows.<\/p>\n\n\n\n
                                      Standard pipeline<\/h3>\n\n\n\n
                                      flowchart LR\n    A[Push \/ Tag \/ Release] --> B[Checkout]\n    B --> C[Build]\n    C --> D[Test]\n    D --> E[Package]\n    E --> F[Authenticate]\n    F --> G[Publish]\n    G --> H[Verify]\n    H --> I[Attest \/ SBOM]\n<\/code><\/pre>\n\n\n\n
                                      Trigger choices<\/h3>\n\n\n\n
                                      Trigger<\/th>Good for<\/th>Risk \/ consideration<\/th><\/tr><\/thead>
                                      push<\/code> to branch<\/td>Snapshot\/dev builds<\/td>Can create many versions<\/td><\/tr>
                                      Git tag<\/td>Version-driven releases<\/td>Protect tag creation<\/td><\/tr>
                                      GitHub Release<\/td>Human-reviewed release flow<\/td>Release creation must be governed<\/td><\/tr>
                                      workflow_dispatch<\/code><\/td>Manual controlled publish<\/td>Requires operational discipline<\/td><\/tr>
                                      schedule<\/code><\/td>Periodic rebuilds<\/td>Must avoid accidental republish collision<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                      Recommended release workflow permissions<\/h3>\n\n\n\n
                                      permissions:\n  contents: read\n  packages: write\n  attestations: write\n  id-token: write\n<\/code><\/pre>\n\n\n\n
                                      Only request attestations<\/code> and id-token<\/code> when the workflow actually generates attestations.<\/p>\n\n\n\n
                                      Test before publish<\/h3>\n\n\n\n
                                      jobs:\n  test:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions\/checkout@v6\n      - run: .\/scripts\/test.sh\n\n  publish:\n    needs: test\n    if: github.event_name == 'release'\n    runs-on: ubuntu-latest\n    permissions:\n      contents: read\n      packages: write\n    steps:\n      - uses: actions\/checkout@v6\n      - run: .\/scripts\/publish.sh\n<\/code><\/pre>\n\n\n\n
                                      The important control is the dependency: publishing does not start unless tests succeed.<\/p>\n\n\n\n
                                      \n\n\n\n
                                      17. Container Publishing Workflow with Metadata and Provenance<\/h2>\n\n\n\n
                                      A production-quality container workflow should build, test, publish, capture the digest, and generate provenance.<\/p>\n\n\n\n
                                      name: Publish container\n\non:\n  release:\n    types: [published]\n\nenv:\n  REGISTRY: ghcr.io\n  IMAGE_NAME: ${{ github.repository }}\n\njobs:\n  publish:\n    runs-on: ubuntu-latest\n    permissions:\n      contents: read\n      packages: write\n      attestations: write\n      id-token: write\n\n    steps:\n      - uses: actions\/checkout@v6\n\n      - name: Log in to GHCR\n        uses: docker\/login-action@v3\n        with:\n          registry: ${{ env.REGISTRY }}\n          username: ${{ github.actor }}\n          password: ${{ secrets.GITHUB_TOKEN }}\n\n      - name: Generate image metadata\n        id: meta\n        uses: docker\/metadata-action@v5\n        with:\n          images: ${{ env.REGISTRY }}\/${{ env.IMAGE_NAME }}\n          tags: |\n            type=semver,pattern={{version}}\n            type=semver,pattern={{major}}.{{minor}}\n            type=sha\n\n      - name: Build and push\n        id: push\n        uses: docker\/build-push-action@v6\n        with:\n          context: .\n          push: true\n          tags: ${{ steps.meta.outputs.tags }}\n          labels: ${{ steps.meta.outputs.labels }}\n\n      - name: Generate provenance attestation\n        uses: actions\/attest@v4\n        with:\n          subject-name: ${{ env.REGISTRY }}\/${{ env.IMAGE_NAME }}\n          subject-digest: ${{ steps.push.outputs.digest }}\n          push-to-registry: true\n<\/code><\/pre>\n\n\n\n
                                      \n
                                      For high-assurance production workflows, pin non-GitHub and third-party Actions to a reviewed full commit SHA. The major-version tags above are easier for training and should not be mistaken for the strongest supply-chain posture.<\/p>\n<\/blockquote>\n\n\n\n
                                      Multi-platform extension<\/h3>\n\n\n\n
                                      Add Buildx setup and configure:<\/p>\n\n\n\n
                                      with:\n  platforms: linux\/amd64,linux\/arm64\n  push: true\n<\/code><\/pre>\n\n\n\n
                                      \n\n\n\n
                                      18. Actions and Codespaces Package Access<\/h2>\n\n\n\n
                                      Granular packages can grant access to repositories separately for GitHub Actions and GitHub Codespaces.<\/p>\n\n\n\n
                                      Actions access<\/h3>\n\n\n\n
                                      Use package settings when a workflow in one repository needs a package owned elsewhere.<\/p>\n\n\n\n
                                      Typical flow:<\/p>\n\n\n\n
                                        \n
                                      1. Open the package.<\/li>\n\n\n\n
                                      2. Open\u00a0Package settings<\/strong>.<\/li>\n\n\n\n
                                      3. Find\u00a0Manage Actions access<\/strong>.<\/li>\n\n\n\n
                                      4. Add the workflow repository.<\/li>\n\n\n\n
                                      5. Choose the minimum required role.<\/li>\n\n\n\n
                                      6. Set workflow\u00a0permissions<\/code>\u00a0to\u00a0packages: read<\/code>\u00a0or\u00a0packages: write<\/code>\u00a0as appropriate.<\/li>\n\n\n\n
                                      7. Test with\u00a0GITHUB_TOKEN<\/code>\u00a0before introducing a PAT.<\/li>\n<\/ol>\n\n\n\n
                                        Codespaces access<\/h3>\n\n\n\n
                                        For supported granular packages, package settings can also allow selected repositories’ Codespaces to install the package. This is useful when developer environments need private dependencies but you do not want developers maintaining broad package credentials.<\/p>\n\n\n\n
                                        Cross-repository access decision<\/h3>\n\n\n\n
                                        flowchart TD\n    A[Workflow needs package] --> B{Same repository\/package relationship?}\n    B -->|Yes| C[Use GITHUB_TOKEN]\n    B -->|No| D{Granular registry?}\n    D -->|Yes| E[Grant repository package access]\n    E --> C\n    D -->|No \/ repo-scoped| F[Use repository permission model]\n    F --> G[Validate token and repository access]\n<\/code><\/pre>\n\n\n\n
                                        \n\n\n\n
                                        19. Deleting, Restoring, and Cleaning Up Packages<\/h2>\n\n\n\n
                                        Deletion is a destructive operation and should be governed like a release operation.<\/p>\n\n\n\n
                                        Current GitHub.com rules<\/h3>\n\n\n\n
                                        GitHub documents that users with sufficient access can delete:<\/p>\n\n\n\n
                                          \n
                                        • An entire private package.<\/li>\n\n\n\n
                                        • A specific version of a private package.<\/li>\n\n\n\n
                                        • A public package if no version has more than 5,000 downloads.<\/li>\n\n\n\n
                                        • A public package version if that version does not have more than 5,000 downloads.<\/li>\n<\/ul>\n\n\n\n
                                          For a public package\/version above the documented 5,000-download threshold, GitHub Support is required for deletion assistance.<\/p>\n\n\n\n
                                          Restoration<\/h3>\n\n\n\n
                                          A deleted package or package version can normally be restored when:<\/p>\n\n\n\n
                                            \n
                                          • It is restored within 30 days of deletion.<\/li>\n\n\n\n
                                          • The package namespace\/version has not been reused in a way that blocks restoration.<\/li>\n<\/ul>\n\n\n\n
                                            GitHub Actions deletion\/restoration<\/h3>\n\n\n\n
                                            GitHub currently documents workflow-based delete\/restore through the REST API as public preview<\/strong>. For granular packages, the workflow repository must have package admin access and the workflow token must be configured appropriately.<\/p>\n\n\n\n
                                            Safe cleanup policy<\/h3>\n\n\n\n
                                            A practical organization policy could be:<\/p>\n\n\n\n
                                            Package class<\/th>Retention suggestion<\/th><\/tr><\/thead>
                                            Production releases<\/td>Keep indefinitely or per compliance policy<\/td><\/tr>
                                            Supported major\/minor releases<\/td>Keep while supported<\/td><\/tr>
                                            Release candidates<\/td>Keep last 5\u201310<\/td><\/tr>
                                            Branch\/dev builds<\/td>Keep 7\u201330 days<\/td><\/tr>
                                            Pull-request builds<\/td>Keep only while PR is active plus grace period<\/td><\/tr>
                                            Untagged container manifests<\/td>Clean after verifying no digest references depend on them<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                            Example: list container versions with GitHub CLI<\/h3>\n\n\n\n
                                            gh api \\\n  -H \"Accept: application\/vnd.github+json\" \\\n  -H \"X-GitHub-Api-Version: 2026-03-10\" \\\n  \"\/orgs\/acme\/packages\/container\/payments-api\/versions?per_page=100\"\n<\/code><\/pre>\n\n\n\n
                                            Example: delete a version<\/h3>\n\n\n\n
                                            gh api \\\n  --method DELETE \\\n  -H \"Accept: application\/vnd.github+json\" \\\n  -H \"X-GitHub-Api-Version: 2026-03-10\" \\\n  \"\/orgs\/acme\/packages\/container\/payments-api\/versions\/PACKAGE_VERSION_ID\"\n<\/code><\/pre>\n\n\n\n
                                            Use a dry-run\/reporting step before automated deletion.<\/p>\n\n\n\n
                                            \n\n\n\n
                                            20. REST API for GitHub Packages<\/h2>\n\n\n\n
                                            The Packages REST API can list and manage packages and versions for users and organizations.<\/p>\n\n\n\n
                                            Common package types<\/h3>\n\n\n\n
                                            The REST API recognizes package types including:<\/p>\n\n\n\n
                                            npm\nmaven\nrubygems\ndocker\nnuget\ncontainer\n<\/code><\/pre>\n\n\n\n
                                            Gradle packages use the API package type maven<\/code>. Legacy Docker-registry images can be represented by docker<\/code>, while GHCR images use container<\/code>.<\/p>\n\n\n\n
                                            List organization packages<\/h3>\n\n\n\n
                                            gh api \\\n  -H \"Accept: application\/vnd.github+json\" \\\n  -H \"X-GitHub-Api-Version: 2026-03-10\" \\\n  \"\/orgs\/acme\/packages?package_type=container&per_page=100\"\n<\/code><\/pre>\n\n\n\n
                                            Get a package<\/h3>\n\n\n\n
                                            gh api \\\n  -H \"Accept: application\/vnd.github+json\" \\\n  -H \"X-GitHub-Api-Version: 2026-03-10\" \\\n  \"\/orgs\/acme\/packages\/container\/payments-api\"\n<\/code><\/pre>\n\n\n\n
                                            List versions<\/h3>\n\n\n\n
                                            gh api \\\n  -H \"Accept: application\/vnd.github+json\" \\\n  -H \"X-GitHub-Api-Version: 2026-03-10\" \\\n  \"\/orgs\/acme\/packages\/container\/payments-api\/versions?state=active&per_page=100\"\n<\/code><\/pre>\n\n\n\n
                                            Pagination<\/h3>\n\n\n\n
                                            The API defaults to paginated responses. For large estates:<\/p>\n\n\n\n
                                            gh api --paginate \\\n  -H \"X-GitHub-Api-Version: 2026-03-10\" \\\n  \"\/orgs\/acme\/packages?package_type=container&per_page=100\"\n<\/code><\/pre>\n\n\n\n
                                            API authentication caution<\/h3>\n\n\n\n
                                            Endpoint support differs by operation. PAT classic is the baseline package token model, while current REST documentation also lists GitHub App and fine-grained token support for selected endpoints. Do not assume every endpoint accepts every token type.<\/p>\n\n\n\n
                                            \n\n\n\n
                                            21. GitHub CLI for Package Administration<\/h2>\n\n\n\n
                                            There is no need to wait for a dedicated gh package<\/code> command to automate package operations. gh api<\/code> can call the Packages REST API directly.<\/p>\n\n\n\n
                                            Inventory script<\/h3>\n\n\n\n
                                            #!\/usr\/bin\/env bash\nset -euo pipefail\n\nORG=\"${1:?usage: $0 ORG}\"\nTYPE=\"${2:-container}\"\n\ngh api --paginate \\\n  -H \"Accept: application\/vnd.github+json\" \\\n  -H \"X-GitHub-Api-Version: 2026-03-10\" \\\n  \"\/orgs\/${ORG}\/packages?package_type=${TYPE}&per_page=100\" \\\n  --jq '.[] | [.name, .visibility, .version_count, .updated_at] | @tsv'\n<\/code><\/pre>\n\n\n\n
                                            Example output:<\/p>\n\n\n\n
                                            payments-api    private    42    2026-09-24T03:10:21Z\nshared-ui       internal   18    2026-09-20T09:04:03Z\n<\/code><\/pre>\n\n\n\n
                                            Why gh api<\/code> is useful<\/h3>\n\n\n\n
                                              \n
                                            • Auth can reuse GitHub CLI login.<\/li>\n\n\n\n
                                            • Pagination is easy.<\/li>\n\n\n\n
                                            • --jq<\/code>\u00a0supports lightweight reporting.<\/li>\n\n\n\n
                                            • Scripts can run locally or in Actions.<\/li>\n\n\n\n
                                            • It exposes new REST features without waiting for a specialized CLI subcommand.<\/li>\n<\/ul>\n\n\n\n
                                              \n\n\n\n
                                              22. GraphQL and GitHub Packages<\/h2>\n\n\n\n
                                              Treat GraphQL support as a compatibility area, not the default management API for GitHub Packages.<\/p>\n\n\n\n
                                              GitHub documents that the Packages GraphQL API cannot be used with registries that support granular permissions. GraphQL remains relevant mainly to repository-scoped package models and historical integrations.<\/p>\n\n\n\n
                                              For new automation across Container, npm, NuGet, and RubyGems, prefer the REST API unless a documented GraphQL object is specifically required.<\/p>\n\n\n\n
                                              Decision table<\/h3>\n\n\n\n
                                              Need<\/th>Preferred interface<\/th><\/tr><\/thead>
                                              List\/manage modern granular packages<\/td>REST API<\/td><\/tr>
                                              Automate from shell<\/td>gh api<\/code><\/td><\/tr>
                                              Receive publish event<\/td>Webhook<\/td><\/tr>
                                              Package manager publish\/install<\/td>Native package client<\/td><\/tr>
                                              Historical\/repository-scoped graph use case<\/td>GraphQL where documented<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                              \n\n\n\n
                                              23. Package Webhooks and Event Automation<\/h2>\n\n\n\n
                                              GitHub exposes a package<\/code> webhook event for GitHub Packages activity. The documented published<\/code> action fires when a package is published.<\/p>\n\n\n\n
                                              Typical automation<\/h3>\n\n\n\n
                                              sequenceDiagram\n    participant Publisher\n    participant GitHubPackages as GitHub Packages\n    participant Webhook\n    participant Scanner\n    participant Chat as Notification System\n\n    Publisher->>GitHubPackages: Publish package\n    GitHubPackages->>Webhook: package.published\n    Webhook->>Scanner: Start external scan\n    Scanner-->>Webhook: Result\n    Webhook->>Chat: Publish status\n<\/code><\/pre>\n\n\n\n
                                              Example use cases<\/h3>\n\n\n\n
                                                \n
                                              • Start an external vulnerability scan after publication.<\/li>\n\n\n\n
                                              • Synchronize metadata to a CMDB.<\/li>\n\n\n\n
                                              • Notify a release channel.<\/li>\n\n\n\n
                                              • Trigger downstream deployment orchestration.<\/li>\n\n\n\n
                                              • Register the artifact in an internal catalog.<\/li>\n<\/ul>\n\n\n\n
                                                package<\/code> vs registry_package<\/code><\/h3>\n\n\n\n
                                                GitHub’s webhook documentation recommends the newer package<\/code> event over the older registry_package<\/code> event. Existing integrations should be reviewed before migration rather than changed blindly.<\/p>\n\n\n\n
                                                Webhook security<\/h3>\n\n\n\n
                                                  \n
                                                • Use a webhook secret.<\/li>\n\n\n\n
                                                • Validate GitHub signatures.<\/li>\n\n\n\n
                                                • Reject stale\/replayed requests where practical.<\/li>\n\n\n\n
                                                • Make handlers idempotent.<\/li>\n\n\n\n
                                                • Do not treat an incoming publish event as sufficient authorization for production deployment.<\/li>\n<\/ul>\n\n\n\n
                                                  \n\n\n\n
                                                  24. GitHub App Integration<\/h2>\n\n\n\n
                                                  GitHub Apps are appropriate when a service needs organization-wide automation without relying on a person’s credentials.<\/p>\n\n\n\n
                                                  Possible responsibilities:<\/p>\n\n\n\n
                                                    \n
                                                  • Receive package webhooks.<\/li>\n\n\n\n
                                                  • Read package metadata through supported REST endpoints.<\/li>\n\n\n\n
                                                  • Create audit records.<\/li>\n\n\n\n
                                                  • Enforce internal policy outside GitHub.<\/li>\n\n\n\n
                                                  • Integrate package events with deployment or security tooling.<\/li>\n<\/ul>\n\n\n\n
                                                    App design principles<\/h3>\n\n\n\n
                                                      \n
                                                    • Request only required repository\/organization permissions.<\/li>\n\n\n\n
                                                    • Use short-lived installation access tokens.<\/li>\n\n\n\n
                                                    • Verify webhook signatures.<\/li>\n\n\n\n
                                                    • Store App private keys securely.<\/li>\n\n\n\n
                                                    • Model each REST endpoint’s accepted token types explicitly.<\/li>\n<\/ul>\n\n\n\n
                                                      \n\n\n\n
                                                      25. Billing, Storage, Data Transfer, and Budgets<\/h2>\n\n\n\n
                                                      GitHub Packages usage is tied to the owning account and plan.<\/p>\n\n\n\n
                                                      Included usage currently documented by GitHub<\/h3>\n\n\n\n
                                                      Plan<\/th>Included storage<\/th>Included data transfer \/ month<\/th><\/tr><\/thead>
                                                      GitHub Free<\/td>500 MB<\/td>1 GB<\/td><\/tr>
                                                      GitHub Pro<\/td>2 GB<\/td>10 GB<\/td><\/tr>
                                                      GitHub Free for organizations<\/td>500 MB<\/td>1 GB<\/td><\/tr>
                                                      GitHub Team<\/td>2 GB<\/td>10 GB<\/td><\/tr>
                                                      GitHub Enterprise Cloud<\/td>50 GB<\/td>100 GB<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                      GitHub documents that the included storage pool is shared with GitHub Actions artifacts.<\/p>\n\n\n\n
                                                      Container registry billing status<\/h3>\n\n\n\n
                                                      As of September 2026, GitHub’s billing documentation says Container registry image storage and bandwidth are currently free, with at least one month of notice promised before a policy change.<\/p>\n\n\n\n
                                                      Treat that as a current policy, not a permanent architecture assumption.<\/p>\n\n\n\n
                                                      Actions package transfer<\/h3>\n\n\n\n
                                                      GitHub documents that package downloads performed by GitHub Actions using a GITHUB_TOKEN<\/code> do not count against the hosting repository’s data-transfer usage. Current billing documentation further distinguishes token and runner type: GITHUB_TOKEN<\/code> access is free for GitHub-hosted and self-hosted runners; PAT-based package access is documented as free on GitHub-hosted runners but billable on self-hosted runners.<\/p>\n\n\n\n
                                                      Cost controls<\/h3>\n\n\n\n
                                                      Recommended:<\/p>\n\n\n\n
                                                        \n
                                                      • Define version-retention rules.<\/li>\n\n\n\n
                                                      • Clean snapshot\/dev packages.<\/li>\n\n\n\n
                                                      • Avoid duplicating the same large binary under unnecessary versions.<\/li>\n\n\n\n
                                                      • Monitor package and Actions storage together.<\/li>\n\n\n\n
                                                      • Configure budgets\/spending limits where applicable.<\/li>\n\n\n\n
                                                      • Enable budget alerts at 75%, 90%, and 100% where useful.<\/li>\n\n\n\n
                                                      • Enable included-usage alerts at 90% and 100% for GitHub Packages storage\/bandwidth.<\/li>\n\n\n\n
                                                      • Review sudden changes in download patterns.<\/li>\n\n\n\n
                                                      • Track organization ownership before moving repositories\/packages.<\/li>\n<\/ul>\n\n\n\n
                                                        Storage forecasting<\/h3>\n\n\n\n
                                                        A simple estimate:<\/p>\n\n\n\n
                                                        Monthly retained storage growth\n\u2248 average package size \u00d7 new retained versions per month \u00d7 package count\n<\/code><\/pre>\n\n\n\n
                                                        For containers, deduplicated layer behavior can make real storage different from a naive image-size multiplication, so billing\/usage reports remain the source of truth.<\/p>\n\n\n\n
                                                        \n\n\n\n
                                                        26. Organization Package Administration<\/h2>\n\n\n\n
                                                        Organization owners should treat package configuration as part of platform governance.<\/p>\n\n\n\n
                                                        Organization-level concerns<\/h3>\n\n\n\n
                                                          \n
                                                        • Who may create packages?<\/li>\n\n\n\n
                                                        • Which visibility levels are allowed?<\/li>\n\n\n\n
                                                        • Should granular packages inherit repository permissions automatically?<\/li>\n\n\n\n
                                                        • Which teams can administer shared packages?<\/li>\n\n\n\n
                                                        • Who may publish production packages?<\/li>\n\n\n\n
                                                        • What is the naming convention?<\/li>\n\n\n\n
                                                        • What is the retention policy?<\/li>\n\n\n\n
                                                        • How are external\/public packages reviewed?<\/li>\n\n\n\n
                                                        • What is the response plan for a compromised package?<\/li>\n<\/ul>\n\n\n\n
                                                          Suggested organization standard<\/h3>\n\n\n\n
                                                          Area<\/th>Recommended standard<\/th><\/tr><\/thead>
                                                          Ownership<\/td>Organization, not individual users, for business packages<\/td><\/tr>
                                                          Publishing<\/td>CI-first; developer-laptop publishing only for controlled exceptions<\/td><\/tr>
                                                          Credentials<\/td>GITHUB_TOKEN<\/code> in Actions; minimal PAT classic for local use<\/td><\/tr>
                                                          Visibility<\/td>Private\/internal by default for proprietary packages<\/td><\/tr>
                                                          Source link<\/td>Required<\/td><\/tr>
                                                          Versioning<\/td>SemVer for libraries; immutable release tags\/digests for containers<\/td><\/tr>
                                                          Release<\/td>Protected tags\/releases or environment approval<\/td><\/tr>
                                                          Retention<\/td>Explicit per package class<\/td><\/tr>
                                                          Provenance<\/td>Attest production artifacts<\/td><\/tr>
                                                          SBOM<\/td>Generate for production\/security-sensitive artifacts<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                          \n\n\n\n
                                                          27. Enterprise Considerations<\/h2>\n\n\n\n
                                                          Enterprise Managed Users<\/h3>\n\n\n\n
                                                          GitHub documents that Enterprise Managed Users can publish to organization namespaces but cannot publish packages to their own user namespace because there is no personal storage allocation.<\/p>\n\n\n\n
                                                          GitHub Enterprise Cloud<\/h3>\n\n\n\n
                                                          Enterprise Cloud is relevant when you need organization\/enterprise governance, internal visibility, broader security capabilities, or private\/internal artifact attestations.<\/p>\n\n\n\n
                                                          For GitHub Enterprise Cloud with data residency<\/strong>, do not assume the GitHub.com registry matrix is identical. Current GitHub documentation says the Maven and Gradle registries are unavailable in the data-residency offering. Service URLs can also differ; for example, the Container registry uses a tenant-specific containers.SUBDOMAIN.ghe.com<\/code> endpoint rather than ghcr.io<\/code>. Review the exact GHE.com feature matrix before migration.<\/p>\n\n\n\n
                                                          Artifact attestations and plan behavior<\/h3>\n\n\n\n
                                                          GitHub currently documents artifact attestations as available on current plans, with an important visibility distinction:<\/p>\n\n\n\n
                                                            \n
                                                          • On Free, Pro, and Team, attestations are available for public repositories.<\/li>\n\n\n\n
                                                          • Private\/internal repository attestations require GitHub Enterprise Cloud.<\/li>\n<\/ul>\n\n\n\n
                                                            Always recheck plan requirements before making compliance commitments.<\/p>\n\n\n\n
                                                            GitHub Enterprise Server<\/h3>\n\n\n\n
                                                            GitHub Enterprise Server capabilities vary by server version. Do not copy GitHub.com registry availability, action versions, API versions, or security-feature assumptions directly to GHES. Check the documentation for the exact GHES release you operate.<\/p>\n\n\n\n
                                                            \n\n\n\n
                                                            28. Package Architecture Patterns<\/h2>\n\n\n\n
                                                            Centralized organization package registry<\/h3>\n\n\n\n
                                                            flowchart TB\n    subgraph Producers\n      A[Service A Repo]\n      B[Library Repo]\n      C[UI Repo]\n    end\n\n    A --> P[Organization Packages]\n    B --> P\n    C --> P\n\n    P --> X[Consumer Repo 1]\n    P --> Y[Consumer Repo 2]\n    P --> Z[Runtime \/ Deployment]\n<\/code><\/pre>\n\n\n\n
                                                            Benefits:<\/p>\n\n\n\n
                                                              \n
                                                            • Central ownership<\/li>\n\n\n\n
                                                            • Easier discovery<\/li>\n\n\n\n
                                                            • Consistent access model<\/li>\n\n\n\n
                                                            • Shared CI patterns<\/li>\n\n\n\n
                                                            • Easier audit and retention<\/li>\n<\/ul>\n\n\n\n
                                                              Multi-repository shared library<\/h3>\n\n\n\n
                                                              Producer repository publishes @acme\/auth-client<\/code>. Many services consume a pinned version. The producer team owns write\/admin; consumers receive read-only access.<\/p>\n\n\n\n
                                                              Monorepo with multiple packages<\/h3>\n\n\n\n
                                                              repo\/\n\u251c\u2500\u2500 packages\/\n\u2502   \u251c\u2500\u2500 api-client\/\n\u2502   \u251c\u2500\u2500 ui-kit\/\n\u2502   \u2514\u2500\u2500 config\/\n\u251c\u2500\u2500 .github\/workflows\/\n\u2514\u2500\u2500 package.json\n<\/code><\/pre>\n\n\n\n
                                                              Publishing options:<\/p>\n\n\n\n
                                                                \n
                                                              • Independent package versions<\/li>\n\n\n\n
                                                              • One shared release version<\/li>\n\n\n\n
                                                              • Changed-package detection<\/li>\n\n\n\n
                                                              • Matrix publishing<\/li>\n\n\n\n
                                                              • Path filters<\/li>\n<\/ul>\n\n\n\n
                                                                Use tools such as workspace managers\/change detection only when their additional complexity is justified.<\/p>\n\n\n\n
                                                                \n\n\n\n
                                                                29. Build Once, Deploy Many<\/h2>\n\n\n\n
                                                                A mature release pipeline should avoid rebuilding the artifact independently for each environment.<\/p>\n\n\n\n
                                                                flowchart LR\n    A[Commit] --> B[Build + Test]\n    B --> C[Immutable Artifact]\n    C --> D[Dev]\n    D --> E[Stage]\n    E --> F[Production]\n<\/code><\/pre>\n\n\n\n
                                                                The artifact moving through environments should be the same bytes.<\/p>\n\n\n\n
                                                                Containers<\/h3>\n\n\n\n
                                                                Good:<\/p>\n\n\n\n
                                                                ghcr.io\/acme\/api@sha256:abc123...\n<\/code><\/pre>\n\n\n\n
                                                                Riskier:<\/p>\n\n\n\n
                                                                ghcr.io\/acme\/api:latest\n<\/code><\/pre>\n\n\n\n
                                                                Promotion patterns<\/h3>\n\n\n\n
                                                                  \n
                                                                • Promote a digest, not a rebuild.<\/li>\n\n\n\n
                                                                • Add an environment\/release tag to an existing digest if your workflow needs tags.<\/li>\n\n\n\n
                                                                • Store release metadata that records the exact digest\/version.<\/li>\n\n\n\n
                                                                • Roll back by redeploying a previously approved immutable version.<\/li>\n<\/ul>\n\n\n\n
                                                                  Why this matters<\/h3>\n\n\n\n
                                                                  Rebuilding per environment creates a provenance gap: production may contain different bytes from the artifact tested in staging even when source revision is the same.<\/p>\n\n\n\n
                                                                  \n\n\n\n
                                                                  30. Versioning and Release Strategy<\/h2>\n\n\n\n
                                                                  Libraries<\/h3>\n\n\n\n
                                                                  Recommended:<\/p>\n\n\n\n
                                                                    \n
                                                                  • Semantic versions<\/li>\n\n\n\n
                                                                  • Clear compatibility policy<\/li>\n\n\n\n
                                                                  • Pre-release identifiers<\/li>\n\n\n\n
                                                                  • Changelog\/release notes<\/li>\n\n\n\n
                                                                  • No version reuse<\/li>\n<\/ul>\n\n\n\n
                                                                    Containers<\/h3>\n\n\n\n
                                                                    Recommended tag set:<\/p>\n\n\n\n
                                                                    2.7.3\n2.7\n2\nsha-74cce21\n<\/code><\/pre>\n\n\n\n
                                                                    Optional:<\/p>\n\n\n\n
                                                                    latest\nmain\nrelease-candidate\n<\/code><\/pre>\n\n\n\n
                                                                    Only use mutable tags if your automation understands that they are pointers, not identities.<\/p>\n\n\n\n
                                                                    Release-driven publishing<\/h3>\n\n\n\n
                                                                    A controlled release path:<\/p>\n\n\n\n
                                                                    flowchart LR\n    A[Merge to main] --> B[CI]\n    B --> C[Create version tag]\n    C --> D[GitHub Release]\n    D --> E[Publish package]\n    E --> F[Attest]\n    F --> G[Promote exact version]\n<\/code><\/pre>\n\n\n\n
                                                                    Rollback<\/h3>\n\n\n\n
                                                                    Do not overwrite 2.7.3<\/code> with fixed bytes. Publish 2.7.4<\/code> or redeploy a prior known-good immutable artifact.<\/p>\n\n\n\n
                                                                    \n\n\n\n
                                                                    31. Software Supply-Chain Security<\/h2>\n\n\n\n
                                                                    Publishing a package is only one part of the problem. A secure software supply chain must answer:<\/p>\n\n\n\n
                                                                      \n
                                                                    • Where did this artifact come from?<\/li>\n\n\n\n
                                                                    • Which source revision produced it?<\/li>\n\n\n\n
                                                                    • Which workflow built it?<\/li>\n\n\n\n
                                                                    • Was the build trusted?<\/li>\n\n\n\n
                                                                    • Has the artifact changed?<\/li>\n\n\n\n
                                                                    • What dependencies are inside it?<\/li>\n\n\n\n
                                                                    • Is it deployed to production?<\/li>\n<\/ul>\n\n\n\n
                                                                      Security model<\/h3>\n\n\n\n
                                                                      flowchart LR\n    A[Source] --> B[Trusted Workflow]\n    B --> C[Build]\n    C --> D[Package]\n    D --> E[Provenance]\n    D --> F[SBOM]\n    D --> G[Registry]\n    G --> H[Verification]\n    H --> I[Deployment]\n    I --> J[Runtime \/ Linked Artifact Context]\n<\/code><\/pre>\n\n\n\n
                                                                      Core strategies<\/h3>\n\n\n\n
                                                                        \n
                                                                      • Pin dependencies where practical.<\/li>\n\n\n\n
                                                                      • Use lockfiles.<\/li>\n\n\n\n
                                                                      • Protect release branches\/tags\/workflows.<\/li>\n\n\n\n
                                                                      • Minimize workflow token permissions.<\/li>\n\n\n\n
                                                                      • Pin third-party Actions for high-assurance builds.<\/li>\n\n\n\n
                                                                      • Use immutable package versions.<\/li>\n\n\n\n
                                                                      • Use container digests for deployment.<\/li>\n\n\n\n
                                                                      • Generate provenance attestations.<\/li>\n\n\n\n
                                                                      • Generate SBOMs.<\/li>\n\n\n\n
                                                                      • Scan dependencies and images.<\/li>\n\n\n\n
                                                                      • Record runtime\/deployment context.<\/li>\n<\/ul>\n\n\n\n
                                                                        \n\n\n\n
                                                                        32. Artifact Attestations and Build Provenance<\/h2>\n\n\n\n
                                                                        Artifact attestations establish verifiable information about where and how an artifact was built.<\/p>\n\n\n\n
                                                                        Why provenance matters<\/h3>\n\n\n\n
                                                                        Without provenance, a package digest proves identity but not origin. Provenance connects an artifact to trusted build metadata such as repository, workflow, and commit.<\/p>\n\n\n\n
                                                                        Workflow permissions<\/h3>\n\n\n\n
                                                                        A provenance workflow commonly needs:<\/p>\n\n\n\n
                                                                        permissions:\n  contents: read\n  id-token: write\n  attestations: write\n<\/code><\/pre>\n\n\n\n
                                                                        For linked-artifact storage records using registry publishing, GitHub’s current linked-artifacts flow can also require:<\/p>\n\n\n\n
                                                                        artifact-metadata: write\n<\/code><\/pre>\n\n\n\n
                                                                        Verify an attestation<\/h3>\n\n\n\n
                                                                        For a built artifact:<\/p>\n\n\n\n
                                                                        gh attestation verify .\/dist\/my-binary \\\n  -R acme\/my-project\n<\/code><\/pre>\n\n\n\n
                                                                        For a container, verification uses the subject image\/digest and the repository\/owner context supported by gh attestation verify<\/code>.<\/p>\n\n\n\n
                                                                        SLSA<\/h3>\n\n\n\n
                                                                        SLSA is a framework for reasoning about supply-chain security and provenance. GitHub attestations can provide signed build provenance that contributes to a stronger SLSA-oriented build process. Do not claim a particular SLSA level solely because an attestation exists; the complete build system and controls matter.<\/p>\n\n\n\n
                                                                        \n\n\n\n
                                                                        33. Software Bill of Materials (SBOM)<\/h2>\n\n\n\n
                                                                        An SBOM is a machine-readable inventory of software components and dependencies.<\/p>\n\n\n\n
                                                                        Common formats include:<\/p>\n\n\n\n
                                                                          \n
                                                                        • SPDX<\/li>\n\n\n\n
                                                                        • CycloneDX<\/li>\n<\/ul>\n\n\n\n
                                                                          Why SBOMs matter<\/h3>\n\n\n\n
                                                                          They help teams answer:<\/p>\n\n\n\n
                                                                            \n
                                                                          • Which components are inside this build?<\/li>\n\n\n\n
                                                                          • Do we use a vulnerable library?<\/li>\n\n\n\n
                                                                          • Which version is deployed?<\/li>\n\n\n\n
                                                                          • What should be reviewed during an incident?<\/li>\n<\/ul>\n\n\n\n
                                                                            Attesting an SBOM<\/h3>\n\n\n\n
                                                                            After generating an SBOM file, GitHub Actions can attach an SBOM attestation. GitHub’s current documentation supports SPDX and CycloneDX predicate flows.<\/p>\n\n\n\n
                                                                            Example verification for an SPDX SBOM attestation:<\/p>\n\n\n\n
                                                                            gh attestation verify PATH\/TO\/ARTIFACT \\\n  -R acme\/repository \\\n  --predicate-type https:\/\/spdx.dev\/Document\/v2.3\n<\/code><\/pre>\n\n\n\n
                                                                            SBOM is not a vulnerability scan<\/h3>\n\n\n\n
                                                                            An SBOM tells you what is present. Vulnerability-management tooling tells you whether known vulnerabilities affect those components. Use both.<\/p>\n\n\n\n
                                                                            \n\n\n\n
                                                                            34. Dependency Graph and Dependabot<\/h2>\n\n\n\n
                                                                            The dependency graph summarizes dependencies detected from repository manifests\/lockfiles and dependencies submitted by supported automation\/API flows.<\/p>\n\n\n\n
                                                                            It can show:<\/p>\n\n\n\n
                                                                              \n
                                                                            • Direct dependencies<\/li>\n\n\n\n
                                                                            • Transitive dependencies where supported<\/li>\n\n\n\n
                                                                            • Versions<\/li>\n\n\n\n
                                                                            • Licenses<\/li>\n\n\n\n
                                                                            • Known vulnerabilities<\/li>\n\n\n\n
                                                                            • Dependents for public ecosystems where available<\/li>\n<\/ul>\n\n\n\n
                                                                              Dependency data sources<\/h3>\n\n\n\n
                                                                              GitHub can populate the graph through:<\/p>\n\n\n\n
                                                                                \n
                                                                              • Static manifest\/lockfile analysis<\/li>\n\n\n\n
                                                                              • Dependabot graph jobs where supported<\/li>\n\n\n\n
                                                                              • Automatic dependency submission<\/li>\n\n\n\n
                                                                              • Dependency submission API<\/li>\n<\/ul>\n\n\n\n
                                                                                Why lockfiles matter<\/h3>\n\n\n\n
                                                                                A lockfile records the exact resolved dependency set. That improves reproducibility and gives security tooling better evidence than a broad version range alone.<\/p>\n\n\n\n
                                                                                Dependabot integration<\/h3>\n\n\n\n
                                                                                Once dependency data is present, GitHub can use it for:<\/p>\n\n\n\n
                                                                                  \n
                                                                                • Dependabot alerts<\/li>\n\n\n\n
                                                                                • Dependabot security updates<\/li>\n\n\n\n
                                                                                • Dependabot version updates<\/li>\n\n\n\n
                                                                                • Dependency review in pull requests<\/li>\n<\/ul>\n\n\n\n
                                                                                  Private registry access<\/h3>\n\n\n\n
                                                                                  If Dependabot must resolve private dependencies, configure private registry access according to the ecosystem and repository security settings. Do not place credentials in the dependency manifest itself.<\/p>\n\n\n\n
                                                                                  \n\n\n\n
                                                                                  35. Package Vulnerability Management<\/h2>\n\n\n\n
                                                                                  A package-security response should connect advisories, releases, and consumers.<\/p>\n\n\n\n
                                                                                  Example response flow<\/h3>\n\n\n\n
                                                                                  flowchart TD\n    A[Vulnerability identified] --> B[Assess affected versions]\n    B --> C[Fix source\/dependency]\n    C --> D[Build + test]\n    D --> E[Publish patched version]\n    E --> F[Create advisory\/release notes]\n    F --> G[Update consumers]\n    G --> H[Verify production rollout]\n<\/code><\/pre>\n\n\n\n
                                                                                  Practical controls<\/h3>\n\n\n\n
                                                                                    \n
                                                                                  • Track CVEs and GitHub Security Advisories (GHSA).<\/li>\n\n\n\n
                                                                                  • Publish patched versions rather than replacing existing versions.<\/li>\n\n\n\n
                                                                                  • Use Dependabot\/security campaigns where appropriate.<\/li>\n\n\n\n
                                                                                  • Identify production impact using deployment\/runtime context.<\/li>\n\n\n\n
                                                                                  • Revoke compromised credentials immediately.<\/li>\n\n\n\n
                                                                                  • Quarantine or delete malicious\/accidentally published packages where safe and permitted.<\/li>\n\n\n\n
                                                                                  • Preserve evidence during supply-chain incidents.<\/li>\n<\/ul>\n\n\n\n
                                                                                    \n\n\n\n
                                                                                    36. Linked Artifacts<\/h2>\n\n\n\n
                                                                                    Linked artifacts provide an organization-level view of software artifacts built with GitHub Actions, even when the artifact is stored outside GitHub Packages.<\/p>\n\n\n\n
                                                                                    The linked artifacts page is metadata-centric: it does not act as the registry storing the artifact bytes.<\/p>\n\n\n\n
                                                                                    What it connects<\/h3>\n\n\n\n
                                                                                    flowchart LR\n    A[GitHub Repository] --> B[GitHub Actions Build]\n    B --> C[Artifact]\n    C --> D[Storage Record]\n    C --> E[Deployment Record]\n    D --> F[Linked Artifacts]\n    E --> F\n    F --> G[Security \/ Audit \/ Policy Context]\n<\/code><\/pre>\n\n\n\n
                                                                                    Storage records<\/h3>\n\n\n\n
                                                                                    Storage records can describe:<\/p>\n\n\n\n
                                                                                      \n
                                                                                    • Source repository<\/li>\n\n\n\n
                                                                                    • Artifact registry<\/li>\n\n\n\n
                                                                                    • Artifact repository, where applicable<\/li>\n\n\n\n
                                                                                    • Provenance\/attestations<\/li>\n\n\n\n
                                                                                    • Build information<\/li>\n<\/ul>\n\n\n\n
                                                                                      Deployment records<\/h3>\n\n\n\n
                                                                                      Deployment records can include:<\/p>\n\n\n\n
                                                                                        \n
                                                                                      • Environment<\/li>\n\n\n\n
                                                                                      • Cluster\/runtime context<\/li>\n\n\n\n
                                                                                      • Production status<\/li>\n\n\n\n
                                                                                      • Runtime risks such as public internet exposure<\/li>\n\n\n\n
                                                                                      • Sensitive-data context<\/li>\n<\/ul>\n\n\n\n
                                                                                        GitHub explicitly distinguishes these records from the repository deployments dashboard; they are separate data sources.<\/p>\n\n\n\n
                                                                                        Ways to populate linked artifacts<\/h3>\n\n\n\n
                                                                                        Current GitHub documentation lists:<\/p>\n\n\n\n
                                                                                          \n
                                                                                        • Artifact-attestation workflows<\/li>\n\n\n\n
                                                                                        • JFrog Artifactory integration<\/li>\n\n\n\n
                                                                                        • Dynatrace integration<\/li>\n\n\n\n
                                                                                        • Microsoft Defender for Cloud integration<\/li>\n\n\n\n
                                                                                        • Custom integrations using the artifact metadata REST API<\/li>\n<\/ul>\n\n\n\n
                                                                                          GitHub currently marks the Microsoft Defender for Cloud integration as public preview.<\/p>\n\n\n\n
                                                                                          Attestation-based storage records<\/h3>\n\n\n\n
                                                                                          GitHub documents automatic storage-record creation when the attestation action uses:<\/p>\n\n\n\n
                                                                                          push-to-registry: true\n<\/code><\/pre>\n\n\n\n
                                                                                          and the workflow has:<\/p>\n\n\n\n
                                                                                          permissions:\n  artifact-metadata: write\n<\/code><\/pre>\n\n\n\n
                                                                                          Why linked artifacts are useful<\/h3>\n\n\n\n
                                                                                            \n
                                                                                          • Trace a built artifact to source.<\/li>\n\n\n\n
                                                                                          • See where it is stored.<\/li>\n\n\n\n
                                                                                          • See whether it is deployed.<\/li>\n\n\n\n
                                                                                          • Prioritize Dependabot\/code-scanning findings affecting production.<\/li>\n\n\n\n
                                                                                          • Export evidence for audit\/compliance.<\/li>\n\n\n\n
                                                                                          • Associate runtime risk with source repositories.<\/li>\n<\/ul>\n\n\n\n
                                                                                            \n\n\n\n
                                                                                            37. Access Governance<\/h2>\n\n\n\n
                                                                                            A registry can become a shadow production system if package governance is weak.<\/p>\n\n\n\n
                                                                                            Recommended access model<\/h3>\n\n\n\n
                                                                                            Persona<\/th>Read<\/th>Write<\/th>Admin<\/th><\/tr><\/thead>
                                                                                            Application developer<\/td>Yes<\/td>Usually no<\/td>No<\/td><\/tr>
                                                                                            Package maintainer<\/td>Yes<\/td>Yes<\/td>Sometimes<\/td><\/tr>
                                                                                            CI release workflow<\/td>Yes<\/td>Yes<\/td>Only when operationally required<\/td><\/tr>
                                                                                            Platform team<\/td>Yes<\/td>Controlled<\/td>Yes for shared packages<\/td><\/tr>
                                                                                            Consumer service<\/td>Yes<\/td>No<\/td>No<\/td><\/tr>
                                                                                            Security\/audit automation<\/td>Metadata read<\/td>No<\/td>No<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                                                            Team-based permissions<\/h3>\n\n\n\n
                                                                                            Prefer team access over individual grants for organization packages. This reduces long-term permission drift.<\/p>\n\n\n\n
                                                                                            Repository inheritance<\/h3>\n\n\n\n
                                                                                            Use inheritance when the package’s lifecycle matches one repository. Break inheritance when the package is a shared organization resource requiring a different audience.<\/p>\n\n\n\n
                                                                                            \n\n\n\n
                                                                                            38. Visibility Governance<\/h2>\n\n\n\n
                                                                                            Default posture<\/h3>\n\n\n\n
                                                                                            For proprietary packages:<\/p>\n\n\n\n
                                                                                              \n
                                                                                            1. Start private\/internal.<\/li>\n\n\n\n
                                                                                            2. Grant read access intentionally.<\/li>\n\n\n\n
                                                                                            3. Make a package public only after review.<\/li>\n<\/ol>\n\n\n\n
                                                                                              Public package checklist<\/h3>\n\n\n\n
                                                                                              Before changing visibility to public:<\/p>\n\n\n\n
                                                                                                \n
                                                                                              • Confirm package contains no proprietary code.<\/li>\n\n\n\n
                                                                                              • Confirm no embedded credentials\/secrets.<\/li>\n\n\n\n
                                                                                              • Confirm source\/license metadata is correct.<\/li>\n\n\n\n
                                                                                              • Confirm public distribution is legally approved.<\/li>\n\n\n\n
                                                                                              • Confirm package name\/namespace is correct.<\/li>\n\n\n\n
                                                                                              • Confirm published versions cannot disclose internal build paths or sensitive metadata.<\/li>\n<\/ul>\n\n\n\n
                                                                                                Public package deletion has additional constraints, so publication should be treated as potentially irreversible at scale.<\/p>\n\n\n\n
                                                                                                \n\n\n\n
                                                                                                39. Credential Governance<\/h2>\n\n\n\n
                                                                                                Preferred order<\/h3>\n\n\n\n
                                                                                                For GitHub Actions:<\/p>\n\n\n\n
                                                                                                  \n
                                                                                                1. GITHUB_TOKEN<\/code><\/li>\n\n\n\n
                                                                                                2. GitHub App token when a service\/app model is needed and endpoint support exists<\/li>\n\n\n\n
                                                                                                3. PAT classic only when required by package-client or cross-boundary behavior<\/li>\n<\/ol>\n\n\n\n
                                                                                                  For developer package-client use, PAT classic remains the normal GitHub Packages model.<\/p>\n\n\n\n
                                                                                                  Rotation policy<\/h3>\n\n\n\n
                                                                                                  Define:<\/p>\n\n\n\n
                                                                                                    \n
                                                                                                  • Owner<\/li>\n\n\n\n
                                                                                                  • Purpose<\/li>\n\n\n\n
                                                                                                  • Required scopes<\/li>\n\n\n\n
                                                                                                  • Expiry<\/li>\n\n\n\n
                                                                                                  • Rotation period<\/li>\n\n\n\n
                                                                                                  • Revocation procedure<\/li>\n\n\n\n
                                                                                                  • Incident response<\/li>\n<\/ul>\n\n\n\n
                                                                                                    Machine users<\/h3>\n\n\n\n
                                                                                                    Do not create a machine user merely to avoid understanding package permissions. Prefer GitHub Apps or repository\/organization automation patterns when they better match the use case.<\/p>\n\n\n\n
                                                                                                    \n\n\n\n
                                                                                                    40. Publication Governance<\/h2>\n\n\n\n
                                                                                                    CI-only publishing<\/h3>\n\n\n\n
                                                                                                    The strongest default is to publish production packages only from controlled CI.<\/p>\n\n\n\n
                                                                                                    Benefits:<\/p>\n\n\n\n
                                                                                                      \n
                                                                                                    • Reproducibility<\/li>\n\n\n\n
                                                                                                    • Centralized credentials<\/li>\n\n\n\n
                                                                                                    • Audit trail<\/li>\n\n\n\n
                                                                                                    • Consistent tests<\/li>\n\n\n\n
                                                                                                    • Provenance generation<\/li>\n\n\n\n
                                                                                                    • Easier policy enforcement<\/li>\n<\/ul>\n\n\n\n
                                                                                                      Protected release workflow<\/h3>\n\n\n\n
                                                                                                      A common design:<\/p>\n\n\n\n
                                                                                                      flowchart TD\n    A[PR reviewed] --> B[Merge]\n    B --> C[CI passes]\n    C --> D[Create protected tag\/release]\n    D --> E[Approval if required]\n    E --> F[Publish]\n    F --> G[Attest + SBOM]\n    G --> H[Promote immutable artifact]\n<\/code><\/pre>\n\n\n\n
                                                                                                      Naming convention example<\/h3>\n\n\n\n
                                                                                                      Libraries:\n  @acme\/<domain>-<purpose>\n\nContainers:\n  ghcr.io\/acme\/<service>\n\nJava:\n  com.acme.<domain>:<artifact>\n\nNuGet:\n  Acme.<Domain>.<Package>\n<\/code><\/pre>\n\n\n\n
                                                                                                      \n\n\n\n
                                                                                                      41. Consumption Governance<\/h2>\n\n\n\n
                                                                                                      Consumption is as important as publication.<\/p>\n\n\n\n
                                                                                                      Recommended controls<\/h3>\n\n\n\n
                                                                                                        \n
                                                                                                      • Approved registries<\/li>\n\n\n\n
                                                                                                      • Approved package sources<\/li>\n\n\n\n
                                                                                                      • Lockfiles<\/li>\n\n\n\n
                                                                                                      • Version constraints<\/li>\n\n\n\n
                                                                                                      • Digest pinning for production containers<\/li>\n\n\n\n
                                                                                                      • Vulnerability review<\/li>\n\n\n\n
                                                                                                      • License review<\/li>\n\n\n\n
                                                                                                      • Source mapping where supported<\/li>\n\n\n\n
                                                                                                      • Explicit private registry authentication<\/li>\n<\/ul>\n\n\n\n
                                                                                                        Dependency confusion<\/h3>\n\n\n\n
                                                                                                        A private package name can collide with a package in a public registry if source resolution is not controlled. Mitigations include scoped npm packages, NuGet package source mapping, explicit Maven\/Gradle repository ordering, and private namespace standards.<\/p>\n\n\n\n
                                                                                                        \n\n\n\n
                                                                                                        42. CI\/CD Design Patterns<\/h2>\n\n\n\n
                                                                                                        Build \u2192 Test \u2192 Publish<\/h3>\n\n\n\n
                                                                                                        The baseline pattern:<\/p>\n\n\n\n
                                                                                                        build \u2192 unit test \u2192 integration test \u2192 package \u2192 publish \u2192 verify\n<\/code><\/pre>\n\n\n\n
                                                                                                        Release-driven publishing<\/h3>\n\n\n\n
                                                                                                        Only release\/tag events produce production packages.<\/p>\n\n\n\n
                                                                                                        Multi-job pipeline<\/h3>\n\n\n\n
                                                                                                        flowchart LR\n    A[Build] --> B[Unit Tests]\n    B --> C[Integration Tests]\n    C --> D[Security Checks]\n    D --> E[Publish]\n    E --> F[Attest]\n<\/code><\/pre>\n\n\n\n
                                                                                                        Environment-gated publish<\/h3>\n\n\n\n
                                                                                                        GitHub Environments can add approvals or protection controls before a production publishing job executes.<\/p>\n\n\n\n
                                                                                                        Reusable workflow<\/h3>\n\n\n\n
                                                                                                        Centralize release logic in a reusable workflow so many repositories inherit the same permission model, tagging rules, and attestation behavior.<\/p>\n\n\n\n
                                                                                                        \n\n\n\n
                                                                                                        43. Monorepo and Multi-Package Publishing<\/h2>\n\n\n\n
                                                                                                        Challenges<\/h3>\n\n\n\n
                                                                                                          \n
                                                                                                        • Which package changed?<\/li>\n\n\n\n
                                                                                                        • Which version should increment?<\/li>\n\n\n\n
                                                                                                        • Should all packages share one version?<\/li>\n\n\n\n
                                                                                                        • How do you avoid publishing unaffected packages?<\/li>\n<\/ul>\n\n\n\n
                                                                                                          Changed-path matrix pattern<\/h3>\n\n\n\n
                                                                                                          strategy:\n  matrix:\n    package:\n      - api-client\n      - ui-kit\n      - config\n<\/code><\/pre>\n\n\n\n
                                                                                                          Combine a matrix with changed-path detection or your monorepo tool of choice.<\/p>\n\n\n\n
                                                                                                          Independent versions<\/h3>\n\n\n\n
                                                                                                          Best when packages have separate consumers and release cadences.<\/p>\n\n\n\n
                                                                                                          Shared versions<\/h3>\n\n\n\n
                                                                                                          Best when packages form one tightly coupled product release.<\/p>\n\n\n\n
                                                                                                          Avoid publishing every package on every commit just because the repository contains many packages.<\/p>\n\n\n\n
                                                                                                          \n\n\n\n
                                                                                                          44. Container CI\/CD Advanced Patterns<\/h2>\n\n\n\n
                                                                                                          Multi-stage build<\/h3>\n\n\n\n
                                                                                                          FROM node:22-alpine AS build\nWORKDIR \/app\nCOPY package*.json .\/\nRUN npm ci\nCOPY . .\nRUN npm run build\n\nFROM nginx:alpine\nCOPY --from=build \/app\/dist \/usr\/share\/nginx\/html\n<\/code><\/pre>\n\n\n\n
                                                                                                          Advantages:<\/p>\n\n\n\n
                                                                                                            \n
                                                                                                          • Smaller runtime image<\/li>\n\n\n\n
                                                                                                          • Build tools absent from final image<\/li>\n\n\n\n
                                                                                                          • Reduced attack surface<\/li>\n<\/ul>\n\n\n\n
                                                                                                            Layer caching<\/h3>\n\n\n\n
                                                                                                            BuildKit\/Buildx can reuse unchanged layers. Cache configuration should never cause secrets or credentials to be baked into image layers.<\/p>\n\n\n\n
                                                                                                            Digest capture<\/h3>\n\n\n\n
                                                                                                            The build\/push action exposes the published digest. Save it as release metadata and use it for deployment\/attestation.<\/p>\n\n\n\n
                                                                                                            Multi-architecture<\/h3>\n\n\n\n
                                                                                                            Use Buildx and QEMU\/native builders to publish AMD64 and ARM64 manifests under one tag.<\/p>\n\n\n\n
                                                                                                            Secure publishing<\/h3>\n\n\n\n
                                                                                                              \n
                                                                                                            • Minimal\u00a0packages: write<\/code><\/li>\n\n\n\n
                                                                                                            • Trusted trigger<\/li>\n\n\n\n
                                                                                                            • Protected source<\/li>\n\n\n\n
                                                                                                            • Pinned Actions<\/li>\n\n\n\n
                                                                                                            • Provenance<\/li>\n\n\n\n
                                                                                                            • SBOM<\/li>\n\n\n\n
                                                                                                            • Vulnerability scanning<\/li>\n\n\n\n
                                                                                                            • Digest-based deployment<\/li>\n<\/ul>\n\n\n\n
                                                                                                              \n\n\n\n
                                                                                                              45. Deployment Integration<\/h2>\n\n\n\n
                                                                                                              GitHub Packages containers can be consumed by Docker and container orchestration platforms such as Kubernetes and cloud container services.<\/p>\n\n\n\n
                                                                                                              Kubernetes private image pull<\/h3>\n\n\n\n
                                                                                                              A typical secret-based approach:<\/p>\n\n\n\n
                                                                                                              kubectl create secret docker-registry ghcr-pull \\\n  --docker-server=ghcr.io \\\n  --docker-username=YOUR_USERNAME \\\n  --docker-password=YOUR_PAT_CLASSIC \\\n  --namespace=my-app\n<\/code><\/pre>\n\n\n\n
                                                                                                              Pod snippet:<\/p>\n\n\n\n
                                                                                                              apiVersion: v1\nkind: Pod\nmetadata:\n  name: api\nspec:\n  imagePullSecrets:\n    - name: ghcr-pull\n  containers:\n    - name: api\n      image: ghcr.io\/acme\/api@sha256:REPLACE_WITH_DIGEST\n<\/code><\/pre>\n\n\n\n
                                                                                                              For production, evaluate workload identity, secret rotation, external secret managers, and platform-native registry integration rather than relying on manually maintained long-lived pull secrets.<\/p>\n\n\n\n
                                                                                                              Common deployment targets<\/h3>\n\n\n\n
                                                                                                              Target<\/th>Typical GitHub Packages use<\/th>Main consideration<\/th><\/tr><\/thead>
                                                                                                              Docker hosts<\/td>Pull GHCR image directly<\/td>Credential rotation and digest pinning<\/td><\/tr>
                                                                                                              Kubernetes<\/td>imagePullSecrets<\/code> or platform identity<\/td>Namespace secret scope and rotation<\/td><\/tr>
                                                                                                              Amazon ECS \/ EKS<\/td>Deploy GHCR-hosted OCI image<\/td>Private-registry credentials \/ secret integration<\/td><\/tr>
                                                                                                              Azure AKS \/ Container Apps<\/td>Deploy OCI image<\/td>Registry credentials and platform secret model<\/td><\/tr>
                                                                                                              Google GKE \/ Cloud Run<\/td>Deploy OCI image<\/td>External-registry authentication and egress policy<\/td><\/tr>
                                                                                                              Other OCI runtimes<\/td>Pull by tag or digest<\/td>Verify OCI compatibility and auth model<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                                                                              GitHub Packages is the artifact source; each runtime still has its own secure secret, identity, network, and deployment controls.<\/p>\n\n\n\n
                                                                                                              \n\n\n\n
                                                                                                              46. Package Automation Patterns<\/h2>\n\n\n\n
                                                                                                              Automated publishing<\/h3>\n\n\n\n
                                                                                                              Triggers can include:<\/p>\n\n\n\n
                                                                                                                \n
                                                                                                              • Tag<\/li>\n\n\n\n
                                                                                                              • GitHub Release<\/li>\n\n\n\n
                                                                                                              • Protected branch<\/li>\n\n\n\n
                                                                                                              • Manual dispatch<\/li>\n\n\n\n
                                                                                                              • Schedule for rebuilds<\/li>\n<\/ul>\n\n\n\n
                                                                                                                Automated cleanup<\/h3>\n\n\n\n
                                                                                                                A safe cleanup automation should:<\/p>\n\n\n\n
                                                                                                                  \n
                                                                                                                1. List versions.<\/li>\n\n\n\n
                                                                                                                2. Classify protected releases.<\/li>\n\n\n\n
                                                                                                                3. Identify candidates by age\/count\/tag.<\/li>\n\n\n\n
                                                                                                                4. Print a dry-run report.<\/li>\n\n\n\n
                                                                                                                5. Require approval for destructive classes if risk is high.<\/li>\n\n\n\n
                                                                                                                6. Delete by immutable version ID.<\/li>\n\n\n\n
                                                                                                                7. Log results.<\/li>\n<\/ol>\n\n\n\n
                                                                                                                  Automated promotion<\/h3>\n\n\n\n
                                                                                                                  For containers, promotion should retag or record an existing digest rather than rebuild.<\/p>\n\n\n\n
                                                                                                                  Event automation<\/h3>\n\n\n\n
                                                                                                                  Use package webhooks to trigger notifications, scanning, catalog registration, or downstream orchestration.<\/p>\n\n\n\n
                                                                                                                  \n\n\n\n
                                                                                                                  47. Troubleshooting Authentication<\/h2>\n\n\n\n
                                                                                                                  Authentication failures are usually caused by the wrong token type, insufficient scopes, SSO authorization, an incorrect registry endpoint, or a credential not being presented by the client.<\/p>\n\n\n\n
                                                                                                                  Symptom<\/th>Likely cause<\/th>Diagnose<\/th>Fix<\/th><\/tr><\/thead>
                                                                                                                  401 Unauthorized<\/code><\/td>Invalid\/expired token<\/td>Re-authenticate; inspect token age\/scopes<\/td>Replace\/rotate token<\/td><\/tr>
                                                                                                                  Login succeeds but install fails<\/td>Missing read:packages<\/code> or package ACL<\/td>Check package access and token scope<\/td>Add minimum read access<\/td><\/tr>
                                                                                                                  Publish denied<\/td>Missing write:packages<\/code> or write role<\/td>Check token + package\/repository permission<\/td>Grant write only where required<\/td><\/tr>
                                                                                                                  Works locally, fails in Actions<\/td>GITHUB_TOKEN<\/code> permissions too narrow<\/td>Inspect workflow permissions<\/code><\/td>Add packages: read\/write<\/code><\/td><\/tr>
                                                                                                                  Cross-repo package not found<\/td>Workflow repo not granted package access<\/td>Package settings \u2192 Actions access<\/td>Grant repo access<\/td><\/tr>
                                                                                                                  Organization access fails<\/td>PAT not SSO-authorized<\/td>Check org SSO authorization<\/td>Authorize token for org<\/td><\/tr>
                                                                                                                  Wrong endpoint<\/td>Client points to public\/default registry<\/td>Inspect client config<\/td>Use correct GitHub Packages endpoint<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                                                                                  Diagnostic principle<\/h3>\n\n\n\n
                                                                                                                  Separate the layers:<\/p>\n\n\n\n
                                                                                                                    \n
                                                                                                                  1. Can the client reach the registry?<\/li>\n\n\n\n
                                                                                                                  2. Is the credential accepted?<\/li>\n\n\n\n
                                                                                                                  3. Does the credential have the required scope?<\/li>\n\n\n\n
                                                                                                                  4. Does the underlying user\/repository have package permission?<\/li>\n\n\n\n
                                                                                                                  5. Is the package in the expected namespace?<\/li>\n<\/ol>\n\n\n\n
                                                                                                                    \n\n\n\n
                                                                                                                    48. Troubleshooting Authorization<\/h2>\n\n\n\n
                                                                                                                    A valid token can still be unauthorized.<\/p>\n\n\n\n
                                                                                                                    Read denied<\/h3>\n\n\n\n
                                                                                                                    Check:<\/p>\n\n\n\n
                                                                                                                      \n
                                                                                                                    • Package visibility<\/li>\n\n\n\n
                                                                                                                    • User\/team read role<\/li>\n\n\n\n
                                                                                                                    • Repository inheritance<\/li>\n\n\n\n
                                                                                                                    • Actions access grant<\/li>\n\n\n\n
                                                                                                                    • packages: read<\/code>\u00a0workflow permission<\/li>\n\n\n\n
                                                                                                                    • Repository-scoped package permissions<\/li>\n<\/ul>\n\n\n\n
                                                                                                                      Write denied<\/h3>\n\n\n\n
                                                                                                                      Check:<\/p>\n\n\n\n
                                                                                                                        \n
                                                                                                                      • Package write role<\/li>\n\n\n\n
                                                                                                                      • write:packages<\/code>\u00a0PAT scope<\/li>\n\n\n\n
                                                                                                                      • packages: write<\/code>\u00a0workflow permission<\/li>\n\n\n\n
                                                                                                                      • Publishing namespace<\/li>\n\n\n\n
                                                                                                                      • Repository ownership for Maven\/Gradle<\/li>\n<\/ul>\n\n\n\n
                                                                                                                        Admin denied<\/h3>\n\n\n\n
                                                                                                                        Deletion\/access changes require admin-level control. A CI workflow should not receive admin unless its specific operation needs it.<\/p>\n\n\n\n
                                                                                                                        Inheritance confusion<\/h3>\n\n\n\n
                                                                                                                        If a package inherits repository permissions, changing explicit package ACLs may not behave as expected until inherited access is removed. Understand which model is active before changing permissions.<\/p>\n\n\n\n
                                                                                                                        \n\n\n\n
                                                                                                                        49. Troubleshooting Publishing<\/h2>\n\n\n\n
                                                                                                                        Problem<\/th>Likely cause<\/th>Better approach<\/th><\/tr><\/thead>
                                                                                                                        Version already exists<\/td>Immutable version collision<\/td>Increment version; do not reuse release number<\/td><\/tr>
                                                                                                                        Namespace conflict<\/td>Wrong owner\/package scope<\/td>Verify package name and owner<\/td><\/tr>
                                                                                                                        Package published to wrong repo<\/td>Incorrect source\/destination metadata<\/td>Check repository\/package config<\/td><\/tr>
                                                                                                                        npm publish goes to npmjs.org<\/td>.npmrc<\/code>\/publishConfig<\/code> incorrect<\/td>Explicitly configure scope\/registry<\/td><\/tr>
                                                                                                                        Maven deploy fails<\/td>distributionManagement<\/code>\/server ID mismatch<\/td>Match pom.xml<\/code> server ID to settings.xml<\/code><\/td><\/tr>
                                                                                                                        Gradle credentials missing<\/td>Environment variables unavailable<\/td>Inject GITHUB_ACTOR<\/code>\/GITHUB_TOKEN<\/code><\/td><\/tr>
                                                                                                                        NuGet source not found<\/td>nuget.config<\/code> source mismatch<\/td>Validate source URL\/name<\/td><\/tr>
                                                                                                                        Container push denied<\/td>Wrong namespace\/token permission<\/td>Validate ghcr.io\/OWNER\/IMAGE<\/code> and write access<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                                                                                        Verify before publish<\/h3>\n\n\n\n
                                                                                                                        # npm<\/em>\nnpm pack --dry-run\n\n# Maven<\/em>\nmvn --batch-mode verify\n\n# Gradle<\/em>\n.\/gradlew build\n\n# .NET<\/em>\ndotnet pack --configuration Release\n\n# Ruby<\/em>\ngem build your-package.gemspec\n\n# Container<\/em>\ndocker build -t local\/test:verify .\n<\/code><\/pre>\n\n\n\n
                                                                                                                        \n\n\n\n
                                                                                                                        50. Troubleshooting Installation and Dependency Resolution<\/h2>\n\n\n\n
                                                                                                                        Package not found<\/h3>\n\n\n\n
                                                                                                                        Possible causes:<\/p>\n\n\n\n
                                                                                                                          \n
                                                                                                                        • Wrong package name\/version<\/li>\n\n\n\n
                                                                                                                        • Wrong registry URL<\/li>\n\n\n\n
                                                                                                                        • Package is private and authentication is missing<\/li>\n\n\n\n
                                                                                                                        • Cross-repository access is missing<\/li>\n\n\n\n
                                                                                                                        • Client is querying the public registry first\/only<\/li>\n<\/ul>\n\n\n\n
                                                                                                                          Dependency resolution failure<\/h3>\n\n\n\n
                                                                                                                          Inspect the package manager’s source configuration before blaming GitHub Packages.<\/p>\n\n\n\n
                                                                                                                          Examples:<\/p>\n\n\n\n
                                                                                                                          npm config list\nmvn help:effective-settings\n.\/gradlew repositories\n\ndotnet nuget list source\nbundle config list\n<\/code><\/pre>\n\n\n\n
                                                                                                                          Version mismatch<\/h3>\n\n\n\n
                                                                                                                          Use explicit versions while diagnosing. Avoid floating ranges or mutable tags until basic connectivity is confirmed.<\/p>\n\n\n\n
                                                                                                                          \n\n\n\n
                                                                                                                          51. Container Registry Troubleshooting<\/h2>\n\n\n\n
                                                                                                                          Login<\/h3>\n\n\n\n
                                                                                                                          echo \"$CR_PAT\" | docker login ghcr.io -u \"$GITHUB_USER\" --password-stdin\n<\/code><\/pre>\n\n\n\n
                                                                                                                          If login fails, verify the PAT classic, scopes, SSO authorization, and account name.<\/p>\n\n\n\n
                                                                                                                          Image not found<\/h3>\n\n\n\n
                                                                                                                          docker pull ghcr.io\/acme\/api:1.0.0\n<\/code><\/pre>\n\n\n\n
                                                                                                                          Check:<\/p>\n\n\n\n
                                                                                                                            \n
                                                                                                                          • Owner capitalization\/name<\/li>\n\n\n\n
                                                                                                                          • Package visibility<\/li>\n\n\n\n
                                                                                                                          • Tag existence<\/li>\n\n\n\n
                                                                                                                          • Package ACL<\/li>\n\n\n\n
                                                                                                                          • Authentication<\/li>\n<\/ul>\n\n\n\n
                                                                                                                            Architecture mismatch<\/h3>\n\n\n\n
                                                                                                                            Symptom:<\/p>\n\n\n\n
                                                                                                                            exec format error\n<\/code><\/pre>\n\n\n\n
                                                                                                                            Inspect image platforms:<\/p>\n\n\n\n
                                                                                                                            docker buildx imagetools inspect ghcr.io\/acme\/api:1.0.0\n<\/code><\/pre>\n\n\n\n
                                                                                                                            Publish a multi-architecture image or deploy the matching platform.<\/p>\n\n\n\n
                                                                                                                            Tag vs digest confusion<\/h3>\n\n\n\n
                                                                                                                            docker inspect --format='{{index .RepoDigests 0}}' ghcr.io\/acme\/api:1.0.0\n<\/code><\/pre>\n\n\n\n
                                                                                                                            Use digests when validating whether two environments run identical content.<\/p>\n\n\n\n
                                                                                                                            \n\n\n\n
                                                                                                                            52. CI\/CD Troubleshooting<\/h2>\n\n\n\n
                                                                                                                            Workflow permission error<\/h3>\n\n\n\n
                                                                                                                            Inspect the job’s effective permissions:<\/p>\n\n\n\n
                                                                                                                            permissions:\n  contents: read\n  packages: write\n<\/code><\/pre>\n\n\n\n
                                                                                                                            Do not assume repository defaults provide write access.<\/p>\n\n\n\n
                                                                                                                            Pull-request security<\/h3>\n\n\n\n
                                                                                                                            Do not publish packages from untrusted fork PR code using privileged secrets\/tokens. Split validation from trusted publish jobs.<\/p>\n\n\n\n
                                                                                                                            Self-hosted runners<\/h3>\n\n\n\n
                                                                                                                            A compromised self-hosted runner may expose credentials, source, build outputs, or package tokens. Isolate runner groups and use ephemeral runners for high-value release workloads where practical.<\/p>\n\n\n\n
                                                                                                                            Version collisions<\/h3>\n\n\n\n
                                                                                                                            If many parallel jobs publish the same version, only one can logically own that immutable release. Generate the version once and coordinate publishing.<\/p>\n\n\n\n
                                                                                                                            \n\n\n\n
                                                                                                                            53. Registry Migration<\/h2>\n\n\n\n
                                                                                                                            A registry migration is not just copying files. It includes metadata, credentials, consumers, automation, access, and rollback.<\/p>\n\n\n\n
                                                                                                                            Migration phases<\/h3>\n\n\n\n
                                                                                                                            flowchart LR\n    A[Inventory] --> B[Map namespaces\/versions]\n    B --> C[Design access]\n    C --> D[Copy\/publish artifacts]\n    D --> E[Update CI publishers]\n    E --> F[Update consumers]\n    F --> G[Validate]\n    G --> H[Freeze old registry]\n    H --> I[Retire]\n<\/code><\/pre>\n\n\n\n
                                                                                                                            Inventory<\/h3>\n\n\n\n
                                                                                                                            Capture:<\/p>\n\n\n\n
                                                                                                                              \n
                                                                                                                            • Packages<\/li>\n\n\n\n
                                                                                                                            • Versions\/tags\/digests<\/li>\n\n\n\n
                                                                                                                            • Owners<\/li>\n\n\n\n
                                                                                                                            • Visibility<\/li>\n\n\n\n
                                                                                                                            • Consumers<\/li>\n\n\n\n
                                                                                                                            • CI publishers<\/li>\n\n\n\n
                                                                                                                            • Credentials<\/li>\n\n\n\n
                                                                                                                            • Retention rules<\/li>\n\n\n\n
                                                                                                                            • Download\/usage patterns<\/li>\n<\/ul>\n\n\n\n
                                                                                                                              Consumer migration<\/h3>\n\n\n\n
                                                                                                                              Update:<\/p>\n\n\n\n
                                                                                                                                \n
                                                                                                                              • Registry URL<\/li>\n\n\n\n
                                                                                                                              • Package source config<\/li>\n\n\n\n
                                                                                                                              • Credentials<\/li>\n\n\n\n
                                                                                                                              • Lockfiles if source metadata changes<\/li>\n\n\n\n
                                                                                                                              • CI workflows<\/li>\n\n\n\n
                                                                                                                              • Deployment pull secrets<\/li>\n<\/ul>\n\n\n\n
                                                                                                                                Rollback<\/h3>\n\n\n\n
                                                                                                                                Keep the previous registry read-only for a defined period when business requirements allow. Do not delete source artifacts until consumers have been verified.<\/p>\n\n\n\n
                                                                                                                                \n\n\n\n
                                                                                                                                54. Legacy Docker Registry Migration<\/h2>\n\n\n\n
                                                                                                                                The legacy endpoint:<\/p>\n\n\n\n
                                                                                                                                docker.pkg.github.com\n<\/code><\/pre>\n\n\n\n
                                                                                                                                has been replaced by:<\/p>\n\n\n\n
                                                                                                                                ghcr.io\n<\/code><\/pre>\n\n\n\n
                                                                                                                                What changes<\/h3>\n\n\n\n
                                                                                                                                  \n
                                                                                                                                • Image naming<\/li>\n\n\n\n
                                                                                                                                • Authentication configuration<\/li>\n\n\n\n
                                                                                                                                • Workflow registry endpoint<\/li>\n\n\n\n
                                                                                                                                • Package permission model<\/li>\n\n\n\n
                                                                                                                                • Repository association behavior<\/li>\n\n\n\n
                                                                                                                                • Consumer references<\/li>\n<\/ul>\n\n\n\n
                                                                                                                                  Example conceptual change<\/h3>\n\n\n\n
                                                                                                                                  Old:<\/p>\n\n\n\n
                                                                                                                                  docker.pkg.github.com\/acme\/api\/api:1.0.0\n<\/code><\/pre>\n\n\n\n
                                                                                                                                  Modern:<\/p>\n\n\n\n
                                                                                                                                  ghcr.io\/acme\/api:1.0.0\n<\/code><\/pre>\n\n\n\n
                                                                                                                                  Do not start new platform designs on the legacy Docker registry.<\/p>\n\n\n\n
                                                                                                                                  \n\n\n\n
                                                                                                                                  55. Observability, Activity, and Auditing<\/h2>\n\n\n\n
                                                                                                                                  Package observability asks more than “is the registry up?”<\/p>\n\n\n\n
                                                                                                                                  Track:<\/p>\n\n\n\n
                                                                                                                                    \n
                                                                                                                                  • Package inventory<\/li>\n\n\n\n
                                                                                                                                  • Version count<\/li>\n\n\n\n
                                                                                                                                  • Publication activity<\/li>\n\n\n\n
                                                                                                                                  • Download activity where exposed<\/li>\n\n\n\n
                                                                                                                                  • Package ownership<\/li>\n\n\n\n
                                                                                                                                  • Repository links<\/li>\n\n\n\n
                                                                                                                                  • Storage usage<\/li>\n\n\n\n
                                                                                                                                  • Data transfer<\/li>\n\n\n\n
                                                                                                                                  • Deletion events<\/li>\n\n\n\n
                                                                                                                                  • Provenance<\/li>\n\n\n\n
                                                                                                                                  • Deployment context<\/li>\n<\/ul>\n\n\n\n
                                                                                                                                    Audit questions<\/h3>\n\n\n\n
                                                                                                                                      \n
                                                                                                                                    • Who can publish this package?<\/li>\n\n\n\n
                                                                                                                                    • Which workflow published version\u00a02.7.3<\/code>?<\/li>\n\n\n\n
                                                                                                                                    • Which commit produced this digest?<\/li>\n\n\n\n
                                                                                                                                    • Which repositories can consume it?<\/li>\n\n\n\n
                                                                                                                                    • Is it deployed to production?<\/li>\n\n\n\n
                                                                                                                                    • Does it have provenance?<\/li>\n\n\n\n
                                                                                                                                    • Is an SBOM available?<\/li>\n\n\n\n
                                                                                                                                    • Which vulnerable dependencies affect it?<\/li>\n<\/ul>\n\n\n\n
                                                                                                                                      Linked-artifact value<\/h3>\n\n\n\n
                                                                                                                                      Linked artifacts help connect build, storage, provenance, and deployment metadata into an auditable view rather than forcing teams to reconstruct the story manually.<\/p>\n\n\n\n
                                                                                                                                      \n\n\n\n
                                                                                                                                      56. Organization Usage Reporting<\/h2>\n\n\n\n
                                                                                                                                      At minimum, establish a periodic inventory report containing:<\/p>\n\n\n\n
                                                                                                                                      Field<\/th>Why it matters<\/th><\/tr><\/thead>
                                                                                                                                      Package<\/td>Asset identity<\/td><\/tr>
                                                                                                                                      Type<\/td>Registry\/ecosystem<\/td><\/tr>
                                                                                                                                      Visibility<\/td>Exposure risk<\/td><\/tr>
                                                                                                                                      Owner<\/td>Accountability<\/td><\/tr>
                                                                                                                                      Source repository<\/td>Traceability<\/td><\/tr>
                                                                                                                                      Versions<\/td>Retention pressure<\/td><\/tr>
                                                                                                                                      Last updated<\/td>Staleness<\/td><\/tr>
                                                                                                                                      Production use<\/td>Business criticality<\/td><\/tr>
                                                                                                                                      Provenance<\/td>Supply-chain assurance<\/td><\/tr>
                                                                                                                                      Storage<\/td>Cost\/capacity<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                                                                                                      Simple REST inventory<\/h3>\n\n\n\n
                                                                                                                                      gh api --paginate \\\n  -H \"X-GitHub-Api-Version: 2026-03-10\" \\\n  \"\/orgs\/acme\/packages?package_type=container&per_page=100\" \\\n  --jq '.[] | {name,visibility,version_count,updated_at,html_url}'\n<\/code><\/pre>\n\n\n\n
                                                                                                                                      Repeat per package type as needed.<\/p>\n\n\n\n
                                                                                                                                      \n\n\n\n
                                                                                                                                      57. Best Practices<\/h2>\n\n\n\n
                                                                                                                                      Package design<\/h3>\n\n\n\n
                                                                                                                                      Recommended:<\/p>\n\n\n\n
                                                                                                                                        \n
                                                                                                                                      • Clear, stable names<\/li>\n\n\n\n
                                                                                                                                      • Organization ownership for company artifacts<\/li>\n\n\n\n
                                                                                                                                      • Semantic versions for libraries<\/li>\n\n\n\n
                                                                                                                                      • Immutable release versions<\/li>\n\n\n\n
                                                                                                                                      • Source repository linkage<\/li>\n\n\n\n
                                                                                                                                      • License\/description metadata<\/li>\n\n\n\n
                                                                                                                                      • Installation documentation<\/li>\n\n\n\n
                                                                                                                                      • Explicit package owner\/team<\/li>\n<\/ul>\n\n\n\n
                                                                                                                                        Avoid:<\/p>\n\n\n\n
                                                                                                                                          \n
                                                                                                                                        • Ambiguous names<\/li>\n\n\n\n
                                                                                                                                        • User-owned business-critical packages<\/li>\n\n\n\n
                                                                                                                                        • Version reuse<\/li>\n\n\n\n
                                                                                                                                        • Packages without source traceability<\/li>\n\n\n\n
                                                                                                                                        • Packages nobody owns<\/li>\n<\/ul>\n\n\n\n
                                                                                                                                          Security<\/h3>\n\n\n\n
                                                                                                                                          Recommended:<\/p>\n\n\n\n
                                                                                                                                            \n
                                                                                                                                          • Least privilege<\/li>\n\n\n\n
                                                                                                                                          • GITHUB_TOKEN<\/code>\u00a0in Actions<\/li>\n\n\n\n
                                                                                                                                          • Minimal PAT classic scopes<\/li>\n\n\n\n
                                                                                                                                          • Credential rotation<\/li>\n\n\n\n
                                                                                                                                          • Protected releases<\/li>\n\n\n\n
                                                                                                                                          • Pinned third-party Actions for high-assurance workflows<\/li>\n\n\n\n
                                                                                                                                          • Provenance<\/li>\n\n\n\n
                                                                                                                                          • SBOM<\/li>\n\n\n\n
                                                                                                                                          • Vulnerability scanning<\/li>\n\n\n\n
                                                                                                                                          • Digest-based production deployments<\/li>\n<\/ul>\n\n\n\n
                                                                                                                                            Avoid:<\/p>\n\n\n\n
                                                                                                                                              \n
                                                                                                                                            • Long-lived admin tokens<\/li>\n\n\n\n
                                                                                                                                            • Shared PATs<\/li>\n\n\n\n
                                                                                                                                            • Secrets in package config files<\/li>\n\n\n\n
                                                                                                                                            • Publishing from untrusted PR jobs<\/li>\n\n\n\n
                                                                                                                                            • Mutable-only production tags<\/li>\n<\/ul>\n\n\n\n
                                                                                                                                              CI\/CD<\/h3>\n\n\n\n
                                                                                                                                              Recommended:<\/p>\n\n\n\n
                                                                                                                                                \n
                                                                                                                                              • Test before publish<\/li>\n\n\n\n
                                                                                                                                              • Release\/tag-driven production publishing<\/li>\n\n\n\n
                                                                                                                                              • Reusable workflows<\/li>\n\n\n\n
                                                                                                                                              • Build once, deploy many<\/li>\n\n\n\n
                                                                                                                                              • Automated cleanup with dry run<\/li>\n\n\n\n
                                                                                                                                              • Release metadata that captures digest\/version<\/li>\n<\/ul>\n\n\n\n
                                                                                                                                                Avoid:<\/p>\n\n\n\n
                                                                                                                                                  \n
                                                                                                                                                • Rebuilding per environment<\/li>\n\n\n\n
                                                                                                                                                • Manual production publishing as the normal path<\/li>\n\n\n\n
                                                                                                                                                • Publishing every commit forever without retention<\/li>\n<\/ul>\n\n\n\n
                                                                                                                                                  Organization governance<\/h3>\n\n\n\n
                                                                                                                                                  Recommended:<\/p>\n\n\n\n
                                                                                                                                                    \n
                                                                                                                                                  • Team-based permissions<\/li>\n\n\n\n
                                                                                                                                                  • Default visibility rules<\/li>\n\n\n\n
                                                                                                                                                  • Naming policy<\/li>\n\n\n\n
                                                                                                                                                  • Versioning policy<\/li>\n\n\n\n
                                                                                                                                                  • Retention policy<\/li>\n\n\n\n
                                                                                                                                                  • Usage monitoring<\/li>\n\n\n\n
                                                                                                                                                  • Audit ownership<\/li>\n<\/ul>\n\n\n\n
                                                                                                                                                    \n\n\n\n
                                                                                                                                                    58. Common Anti-Patterns<\/h2>\n\n\n\n
                                                                                                                                                    Anti-pattern<\/th>Why it is risky<\/th>Better approach<\/th><\/tr><\/thead>
                                                                                                                                                    Hardcoded token<\/td>Credential leak<\/td>Secret manager \/ GITHUB_TOKEN<\/code><\/td><\/tr>
                                                                                                                                                    One PAT shared by team<\/td>No individual accountability<\/td>Team ACL + individual auth<\/td><\/tr>
                                                                                                                                                    Admin token for downloads<\/td>Excess privilege<\/td>Read-only token\/access<\/td><\/tr>
                                                                                                                                                    Publish only from laptop<\/td>Weak reproducibility\/audit<\/td>CI-first publishing<\/td><\/tr>
                                                                                                                                                    Reuse version numbers<\/td>Breaks immutability\/trust<\/td>New version per change<\/td><\/tr>
                                                                                                                                                    Only use latest<\/code><\/td>Cannot identify artifact<\/td>SemVer + SHA + digest<\/td><\/tr>
                                                                                                                                                    No source link<\/td>Weak traceability<\/td>Connect package to repo<\/td><\/tr>
                                                                                                                                                    Unlimited snapshots<\/td>Storage\/cost noise<\/td>Retention policy<\/td><\/tr>
                                                                                                                                                    Public by accident<\/td>Data exposure<\/td>Private\/internal default<\/td><\/tr>
                                                                                                                                                    No provenance<\/td>Hard to verify origin<\/td>Artifact attestations<\/td><\/tr>
                                                                                                                                                    No SBOM<\/td>Poor component visibility<\/td>Generate SBOM<\/td><\/tr>
                                                                                                                                                    Rebuild for prod<\/td>Different bytes than tested<\/td>Promote same immutable artifact<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                                                                                                                    \n\n\n\n
                                                                                                                                                    59. Quick Reference Cheat Sheet<\/h2>\n\n\n\n
                                                                                                                                                    Registry endpoints<\/h3>\n\n\n\n
                                                                                                                                                    Registry<\/th>Endpoint \/ pattern<\/th><\/tr><\/thead>
                                                                                                                                                    Container<\/td>ghcr.io\/OWNER\/IMAGE<\/code><\/td><\/tr>
                                                                                                                                                    npm<\/td>https:\/\/npm.pkg.github.com<\/code><\/td><\/tr>
                                                                                                                                                    Maven<\/td>https:\/\/maven.pkg.github.com\/OWNER\/REPOSITORY<\/code><\/td><\/tr>
                                                                                                                                                    Gradle<\/td>Maven-compatible GitHub Packages repository URL<\/td><\/tr>
                                                                                                                                                    NuGet<\/td>https:\/\/nuget.pkg.github.com\/NAMESPACE\/index.json<\/code><\/td><\/tr>
                                                                                                                                                    RubyGems<\/td>https:\/\/rubygems.pkg.github.com\/NAMESPACE<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                                                                                                                    Token scopes<\/h3>\n\n\n\n
                                                                                                                                                    read:packages\nwrite:packages\ndelete:packages\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                    Workflow permissions<\/h3>\n\n\n\n
                                                                                                                                                    Read:<\/p>\n\n\n\n
                                                                                                                                                    permissions:\n  contents: read\n  packages: read\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                    Publish:<\/p>\n\n\n\n
                                                                                                                                                    permissions:\n  contents: read\n  packages: write\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                    Attest:<\/p>\n\n\n\n
                                                                                                                                                    permissions:\n  contents: read\n  packages: write\n  attestations: write\n  id-token: write\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                    Container commands<\/h3>\n\n\n\n
                                                                                                                                                    docker login ghcr.io\ndocker build -t ghcr.io\/acme\/api:1.0.0 .\ndocker push ghcr.io\/acme\/api:1.0.0\ndocker pull ghcr.io\/acme\/api:1.0.0\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                    npm<\/h3>\n\n\n\n
                                                                                                                                                    npm publish\nnpm install @acme\/pkg@1.0.0\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                    Maven<\/h3>\n\n\n\n
                                                                                                                                                    mvn --batch-mode verify\nmvn --batch-mode deploy\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                    Gradle<\/h3>\n\n\n\n
                                                                                                                                                    .\/gradlew build\n.\/gradlew publish\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                    NuGet<\/h3>\n\n\n\n
                                                                                                                                                    dotnet pack --configuration Release\ndotnet nuget push PACKAGE.nupkg --source github --api-key TOKEN\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                    RubyGems<\/h3>\n\n\n\n
                                                                                                                                                    gem build package.gemspec\ngem push --host https:\/\/rubygems.pkg.github.com\/NAMESPACE package.gem\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                    REST with GitHub CLI<\/h3>\n\n\n\n
                                                                                                                                                    gh api \"\/orgs\/ORG\/packages?package_type=container\"\ngh api \"\/orgs\/ORG\/packages\/container\/NAME\/versions\"\n<\/code><\/pre>\n\n\n\n
                                                                                                                                                    \n\n\n\n
                                                                                                                                                    60. Beginner \u2192 Intermediate \u2192 Advanced Learning Map<\/h2>\n\n\n\n
                                                                                                                                                    Level<\/th>Learn and practice<\/th><\/tr><\/thead>
                                                                                                                                                    Beginner<\/td>Registry purpose, supported ecosystems, auth, publish\/install, visibility, versions<\/td><\/tr>
                                                                                                                                                    Intermediate<\/td>Actions integration, cross-repo access, REST API, cleanup, billing, repository links<\/td><\/tr>
                                                                                                                                                    Advanced<\/td>Build-once promotion, attestations, SBOM, linked artifacts, governance, migration, organization reporting<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                                                                                                                    Recommended training order<\/h3>\n\n\n\n
                                                                                                                                                      \n
                                                                                                                                                    1. Publish\/pull one public or private container.<\/li>\n\n\n\n
                                                                                                                                                    2. Publish one language package.<\/li>\n\n\n\n
                                                                                                                                                    3. Move publishing into GitHub Actions.<\/li>\n\n\n\n
                                                                                                                                                    4. Add a separate consumer repository.<\/li>\n\n\n\n
                                                                                                                                                    5. Add versioning and release triggers.<\/li>\n\n\n\n
                                                                                                                                                    6. Add provenance\/SBOM.<\/li>\n\n\n\n
                                                                                                                                                    7. Add retention automation.<\/li>\n\n\n\n
                                                                                                                                                    8. Build an organization-level governance model.<\/li>\n<\/ol>\n\n\n\n
                                                                                                                                                      \n\n\n\n
                                                                                                                                                      61. Hands-On Exercises<\/h2>\n\n\n\n
                                                                                                                                                      Exercise 1 \u2014 Beginner: Publish a container<\/h3>\n\n\n\n
                                                                                                                                                      Objective:<\/strong> Publish and pull a versioned container from GHCR.<\/p>\n\n\n\n
                                                                                                                                                      Tasks:<\/p>\n\n\n\n
                                                                                                                                                        \n
                                                                                                                                                      1. Create a repository with a small Dockerfile.<\/li>\n\n\n\n
                                                                                                                                                      2. Build\u00a01.0.0<\/code>\u00a0locally.<\/li>\n\n\n\n
                                                                                                                                                      3. Authenticate to GHCR.<\/li>\n\n\n\n
                                                                                                                                                      4. Push the image.<\/li>\n\n\n\n
                                                                                                                                                      5. Open the package page.<\/li>\n\n\n\n
                                                                                                                                                      6. Pull the image on a clean machine\/session.<\/li>\n\n\n\n
                                                                                                                                                      7. Record the digest.<\/li>\n<\/ol>\n\n\n\n
                                                                                                                                                        Expected outcome: a package exists under the intended owner and can be pulled using the expected access model.<\/p>\n\n\n\n
                                                                                                                                                        Exercise 2 \u2014 Intermediate: CI package publishing<\/h3>\n\n\n\n
                                                                                                                                                        Objective:<\/strong> Publish from GitHub Actions without storing a PAT.<\/p>\n\n\n\n
                                                                                                                                                        Tasks:<\/p>\n\n\n\n
                                                                                                                                                          \n
                                                                                                                                                        1. Create a release-triggered workflow.<\/li>\n\n\n\n
                                                                                                                                                        2. Set\u00a0contents: read<\/code>\u00a0and\u00a0packages: write<\/code>.<\/li>\n\n\n\n
                                                                                                                                                        3. Authenticate with\u00a0GITHUB_TOKEN<\/code>.<\/li>\n\n\n\n
                                                                                                                                                        4. Run tests before publishing.<\/li>\n\n\n\n
                                                                                                                                                        5. Publish the package.<\/li>\n\n\n\n
                                                                                                                                                        6. Verify the package version from a second workflow.<\/li>\n<\/ol>\n\n\n\n
                                                                                                                                                          Expected outcome: publishing is reproducible and tied to a GitHub workflow run.<\/p>\n\n\n\n
                                                                                                                                                          Exercise 3 \u2014 Intermediate: Cross-repository consumption<\/h3>\n\n\n\n
                                                                                                                                                          Objective:<\/strong> Allow a consumer repository to read a private granular package.<\/p>\n\n\n\n
                                                                                                                                                          Tasks:<\/p>\n\n\n\n
                                                                                                                                                            \n
                                                                                                                                                          1. Publish a private package from repo A.<\/li>\n\n\n\n
                                                                                                                                                          2. Add repo B under package Actions access.<\/li>\n\n\n\n
                                                                                                                                                          3. Give repo B read access only.<\/li>\n\n\n\n
                                                                                                                                                          4. Set\u00a0packages: read<\/code>\u00a0in repo B workflow.<\/li>\n\n\n\n
                                                                                                                                                          5. Install\/pull the package.<\/li>\n\n\n\n
                                                                                                                                                          6. Remove access and observe the failure.<\/li>\n\n\n\n
                                                                                                                                                          7. Restore read access.<\/li>\n<\/ol>\n\n\n\n
                                                                                                                                                            Expected outcome: students understand package ACLs separately from token scopes.<\/p>\n\n\n\n
                                                                                                                                                            Exercise 4 \u2014 Advanced: Immutable promotion<\/h3>\n\n\n\n
                                                                                                                                                            Objective:<\/strong> Demonstrate build once, deploy many.<\/p>\n\n\n\n
                                                                                                                                                            Tasks:<\/p>\n\n\n\n
                                                                                                                                                              \n
                                                                                                                                                            1. Build and push a container.<\/li>\n\n\n\n
                                                                                                                                                            2. Capture digest.<\/li>\n\n\n\n
                                                                                                                                                            3. Deploy that digest to dev.<\/li>\n\n\n\n
                                                                                                                                                            4. Promote the same digest to stage.<\/li>\n\n\n\n
                                                                                                                                                            5. Verify both environments use identical digest.<\/li>\n\n\n\n
                                                                                                                                                            6. Promote to production.<\/li>\n<\/ol>\n\n\n\n
                                                                                                                                                              Expected outcome: no environment performs a rebuild.<\/p>\n\n\n\n
                                                                                                                                                              Exercise 5 \u2014 Security: Provenance and SBOM<\/h3>\n\n\n\n
                                                                                                                                                              Objective:<\/strong> Add supply-chain evidence.<\/p>\n\n\n\n
                                                                                                                                                              Tasks:<\/p>\n\n\n\n
                                                                                                                                                                \n
                                                                                                                                                              1. Add artifact-attestation permissions.<\/li>\n\n\n\n
                                                                                                                                                              2. Generate provenance after publishing.<\/li>\n\n\n\n
                                                                                                                                                              3. Generate an SPDX or CycloneDX SBOM.<\/li>\n\n\n\n
                                                                                                                                                              4. Attest the SBOM.<\/li>\n\n\n\n
                                                                                                                                                              5. Verify the artifact with GitHub CLI.<\/li>\n\n\n\n
                                                                                                                                                              6. Inspect the attestation output.<\/li>\n<\/ol>\n\n\n\n
                                                                                                                                                                Expected outcome: students can prove where an artifact came from and inspect its component inventory.<\/p>\n\n\n\n
                                                                                                                                                                \n\n\n\n
                                                                                                                                                                62. Complete Practical Project \u2014 Organization Package Platform<\/h2>\n\n\n\n
                                                                                                                                                                Requirement<\/h3>\n\n\n\n
                                                                                                                                                                Design a small but production-oriented GitHub Packages platform for an organization named acme<\/code>.<\/p>\n\n\n\n
                                                                                                                                                                The organization has:<\/p>\n\n\n\n