{"id":78748,"date":"2026-09-26T05:32:03","date_gmt":"2026-09-26T05:32:03","guid":{"rendered":"https:\/\/www.devopsschool.com\/blog\/?p=78748"},"modified":"2026-09-26T05:32:07","modified_gmt":"2026-09-26T05:32:07","slug":"github-packages-essentials-2-hour-hands-on-tutorial","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/blog\/github-packages-essentials-2-hour-hands-on-tutorial\/","title":{"rendered":"GitHub Packages Essentials \u2014 2-Hour Hands-On Tutorial"},"content":{"rendered":"\n
\n

Last Verified:<\/strong> September 2026
Scope:<\/strong> GitHub.com \/ GitHub Enterprise Cloud unless explicitly stated otherwise
Duration:<\/strong> ~2 hours including hands-on practice
Audience:<\/strong> Developers, DevOps engineers, platform engineers, administrators, trainers, and students
Primary hands-on registry:<\/strong> GitHub Container Registry (GHCR)<\/p>\n<\/blockquote>\n\n\n\n

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

This Essentials tutorial intentionally does not<\/strong> attempt to cover every advanced capability. It focuses on the smallest set of concepts and practical skills a learner should understand before working with GitHub Packages in real projects.<\/p>\n\n\n\n

\n\n\n\n

1. What You Should Be Able to Do After 2 Hours<\/h3>\n\n\n\n

By the end of this tutorial, you should be able to:<\/p>\n\n\n\n

    \n
  1. Explain what GitHub Packages is and when to use it.<\/li>\n\n\n\n
  2. Distinguish GitHub Packages from GitHub Releases and GitHub Actions artifacts.<\/li>\n\n\n\n
  3. Identify the six main GitHub Packages registries.<\/li>\n\n\n\n
  4. Understand granular packages vs repository-scoped packages.<\/li>\n\n\n\n
  5. Explain package visibility and Read \/ Write \/ Admin permissions.<\/li>\n\n\n\n
  6. Authenticate using PAT classic locally and\u00a0GITHUB_TOKEN<\/code>\u00a0in GitHub Actions.<\/li>\n\n\n\n
  7. Build, publish, and pull a container image from GHCR.<\/li>\n\n\n\n
  8. Publish a container automatically using GitHub Actions.<\/li>\n\n\n\n
  9. Understand cross-repository package consumption.<\/li>\n\n\n\n
  10. Apply essential versioning, security, and troubleshooting practices.<\/li>\n<\/ol>\n\n\n\n
    \n\n\n\n

    2. Recommended 2-Hour Learning Flow<\/h3>\n\n\n\n
    Time<\/th>Topic<\/th>Outcome<\/th><\/tr><\/thead>
    0\u201310 min<\/td>What GitHub Packages is<\/td>Understand the problem it solves<\/td><\/tr>
    10\u201325 min<\/td>Registries and package model<\/td>Know supported ecosystems and permission models<\/td><\/tr>
    25\u201340 min<\/td>Authentication and permissions<\/td>Understand PAT classic, GITHUB_TOKEN<\/code>, package roles<\/td><\/tr>
    40\u201365 min<\/td>Hands-on GHCR<\/td>Build, push, verify, and pull an image<\/td><\/tr>
    65\u201390 min<\/td>GitHub Actions publishing<\/td>Automate build-test-publish<\/td><\/tr>
    90\u2013105 min<\/td>Cross-repository access<\/td>Understand producer\/consumer package access<\/td><\/tr>
    105\u2013115 min<\/td>Security + versioning + troubleshooting<\/td>Learn production habits and common failures<\/td><\/tr>
    115\u2013120 min<\/td>Knowledge check + cheat sheet<\/td>Reinforce essential commands and decisions<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    \n\n\n\n

    Part 1 \u2014 Understand GitHub Packages<\/h2>\n\n\n\n

    3. What Is GitHub Packages?<\/h3>\n\n\n\n

    A package<\/strong> is a reusable software artifact that another developer, application, build, or deployment can consume.<\/p>\n\n\n\n

    Examples:<\/p>\n\n\n\n

      \n
    • Docker \/ OCI container image<\/li>\n\n\n\n
    • npm package<\/li>\n\n\n\n
    • Maven artifact<\/li>\n\n\n\n
    • Gradle-published Java library<\/li>\n\n\n\n
    • NuGet package<\/li>\n\n\n\n
    • Ruby gem<\/li>\n<\/ul>\n\n\n\n

      GitHub Packages provides registries for storing and distributing these artifacts.<\/p>\n\n\n\n

      Why do teams need a package registry?<\/h4>\n\n\n\n

      Source code alone is not what applications deploy or consume.<\/p>\n\n\n\n

      A typical delivery path looks like this:<\/p>\n\n\n

      flowchart<\/span> LR<\/span>\n    A<\/span>[Source Code]<\/span> --<\/span>> B<\/span>[Build]<\/span>\n    B<\/span> --<\/span>> C<\/span>[Test]<\/span>\n    C<\/span> --<\/span>> D<\/span>[Package]<\/span>\n    D<\/span> --<\/span>> E<\/span>[Publish]<\/span>\n    E<\/span> --<\/span>> F<\/span>[GitHub Packages]<\/span>\n    F<\/span> --<\/span>> G<\/span>[Install \/ Pull]<\/span>\n    G<\/span> --<\/span>> H<\/span>[Application \/ Deployment]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
      A registry sits between the producer<\/strong> and the consumer<\/strong>.<\/p>\n\n\n\n
        \n
      • Producer: creates and publishes a package.<\/li>\n\n\n\n
      • Registry: stores package versions.<\/li>\n\n\n\n
      • Consumer: installs or pulls a package.<\/li>\n<\/ul>\n\n\n\n
        Typical real-world example<\/h4>\n\n\n\n
        A team builds a service called payments-api<\/code>.<\/p>\n\n\n\n
        Instead of deploying directly from source code, CI builds a container image:<\/p>\n\n\n
        ghcr.io\/acme\/payments-api:1.4.2\n<\/code><\/span><\/pre>\n\n\n
        That image is stored in GitHub Container Registry and later pulled by Kubernetes or another deployment platform.<\/p>\n\n\n\n
        \n\n\n\n
        4. GitHub Packages vs Releases vs Actions Artifacts<\/h3>\n\n\n\n
        These three GitHub features solve different problems.<\/p>\n\n\n\n
        Feature<\/th>Primary purpose<\/th>Best example<\/th><\/tr><\/thead>
        GitHub Packages<\/td>Reusable dependencies and deployable packages<\/td>ghcr.io\/acme\/api:1.2.0<\/code><\/td><\/tr>
        GitHub Releases<\/td>Release event, notes, downloadable assets<\/td>v1.2.0<\/code> release with binaries<\/td><\/tr>
        GitHub Actions artifacts<\/td>Temporary workflow outputs<\/td>Test reports, build logs, intermediate files<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
        Simple rule<\/h4>\n\n\n\n
        Use GitHub Packages<\/strong> when another build, developer, application, or deployment will consume the artifact as a package.<\/p>\n\n\n\n
        Use GitHub Releases<\/strong> when publishing release notes and downloadable release assets.<\/p>\n\n\n\n
        Use Actions artifacts<\/strong> for files mainly associated with a workflow run.<\/p>\n\n\n\n
        \n\n\n\n
        Part 2 \u2014 Registries and Permission Models<\/h2>\n\n\n\n
        5. Supported GitHub Packages Registries<\/h3>\n\n\n\n
        GitHub Packages supports six principal package ecosystems.<\/p>\n\n\n\n
        Ecosystem<\/th>Endpoint<\/th>Typical client<\/th>Permission model<\/th><\/tr><\/thead>
        Container<\/td>ghcr.io<\/code><\/td>Docker \/ OCI<\/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<\/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>
        Maven<\/td>maven.pkg.github.com<\/code><\/td>Maven<\/td>Repository scoped<\/td><\/tr>
        Gradle<\/td>Maven-compatible endpoint<\/td>Gradle<\/td>Repository scoped<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
        The old Docker registry endpoint:<\/p>\n\n\n
        docker<\/span>.pkg<\/span>.github<\/span>.com<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
        is legacy. New designs should use:<\/p>\n\n\n
        ghcr<\/span>.io<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
        \n\n\n\n
        6. The Most Important Architecture Concept: Granular vs Repository-Scoped<\/h3>\n\n\n\n
        This distinction changes how access control works.<\/p>\n\n\n
        flowchart TD\n    A[GitHub Package] --> B{Permission model}\n    B -->|Granular| C[User or Organization Scope]\n    C --> D[Independent package permissions]\n    C --> E[Optional repository connection]\n    B -->|Repository scoped| F[Repository]\n    F --> G[Repository permissions]\n    F --> H[Repository visibility]\n<\/code><\/span><\/pre>\n\n\n
        Granular packages<\/h4>\n\n\n\n
        Supported by:<\/p>\n\n\n\n
          \n
        • Container<\/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 have access rules independent of a repository.<\/p>\n\n\n\n
          Example:<\/p>\n\n\n\n
          A package can be owned by organization acme<\/code>, while five different repositories receive read access.<\/p>\n\n\n\n
          Repository-scoped packages<\/h4>\n\n\n\n
          Supported by:<\/p>\n\n\n\n
            \n
          • Maven<\/li>\n\n\n\n
          • Gradle<\/li>\n<\/ul>\n\n\n\n
            These packages inherit the repository’s permissions and visibility.<\/p>\n\n\n\n
            Remember this<\/h4>\n\n\n\n
            \n
            Container\/npm\/NuGet\/RubyGems = package-level access model.
            Maven\/Gradle = repository permission model.<\/p>\n<\/blockquote>\n\n\n\n
            This is one of the most common GitHub Packages design mistakes.<\/p>\n\n\n\n
            \n\n\n\n
            7. Package Visibility and Roles<\/h3>\n\n\n\n
            Package roles<\/h4>\n\n\n\n
            Role<\/th>Typical capability<\/th><\/tr><\/thead>
            Read<\/td>View metadata and download\/install<\/td><\/tr>
            Write<\/td>Read + publish\/upload<\/td><\/tr>
            Admin<\/td>Manage package, access, versions, deletion<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
            Visibility<\/h4>\n\n\n\n
            Depending on registry and account context, packages may be:<\/p>\n\n\n\n
              \n
            • Public<\/li>\n\n\n\n
            • Private<\/li>\n\n\n\n
            • Internal<\/li>\n<\/ul>\n\n\n\n
              For proprietary company packages, a safe starting point is:<\/p>\n\n\n
              Private<\/span>\/Internal -> explicitly grant access -> make public<\/span> only after review\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
              Important GHCR exception<\/h4>\n\n\n\n
              Public GHCR container images can be pulled anonymously.<\/p>\n\n\n\n
              Most other GitHub Packages package-client workflows still require authentication even when a package is public.<\/p>\n\n\n\n
              \n\n\n\n
              Part 3 \u2014 Authentication<\/h2>\n\n\n\n
              8. PAT Classic vs GITHUB_TOKEN<\/code><\/h3>\n\n\n\n
              Authentication is where many first-time GitHub Packages users get confused.<\/p>\n\n\n\n
              Local package-client access<\/h4>\n\n\n\n
              For package clients, GitHub documents personal access token (classic)<\/strong> authentication.<\/p>\n\n\n\n
              Important scopes:<\/p>\n\n\n\n
              Scope<\/th>Use<\/th><\/tr><\/thead>
              read:packages<\/code><\/td>Download\/install<\/td><\/tr>
              write:packages<\/code><\/td>Publish\/upload<\/td><\/tr>
              delete:packages<\/code><\/td>Delete package\/version<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
              Example local GHCR login:<\/p>\n\n\n
              export<\/span> CR_PAT=\"YOUR_PAT_CLASSIC\"<\/span>\n\necho \"$CR_PAT\"<\/span> | docker login ghcr.io \\\n  -u YOUR_GITHUB_USERNAME \\\n  --password-stdin\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
              Do not hardcode the token inside scripts committed to Git.<\/p>\n\n\n\n
              Inside GitHub Actions<\/h4>\n\n\n\n
              Prefer GITHUB_TOKEN<\/code> whenever the package access model supports the operation.<\/p>\n\n\n\n
              Read-only workflow:<\/p>\n\n\n
              permissions:\n  contents: read\n  packages: read\n<\/code><\/span><\/pre>\n\n\n
              Publishing workflow:<\/p>\n\n\n
              permissions:\n  contents: read\n  packages: write\n<\/code><\/span><\/pre>\n\n\n
              Why GITHUB_TOKEN<\/code> is preferred in Actions<\/h4>\n\n\n\n
              It is:<\/p>\n\n\n\n
                \n
              • Automatically generated<\/li>\n\n\n\n
              • Short lived<\/li>\n\n\n\n
              • Repository\/workflow scoped<\/li>\n\n\n\n
              • Permission controllable<\/li>\n\n\n\n
              • Easier to audit than a shared long-lived PAT<\/li>\n<\/ul>\n\n\n\n
                Security rule<\/h4>\n\n\n
                Local package client -> PAT classic when required\nGitHub Actions -> GITHUB_TOKEN whenever possible\n<\/code><\/span><\/pre>\n\n\n
                \n\n\n\n
                Part 4 \u2014 Hands-On: Publish a Container to GHCR<\/h2>\n\n\n\n
                9. Lab 1 \u2014 Build and Publish Manually<\/h3>\n\n\n\n
                Objective<\/h4>\n\n\n\n
                Publish a versioned Docker image to GitHub Container Registry and pull it back successfully.<\/p>\n\n\n\n
                Prerequisites<\/h4>\n\n\n\n
                You need:<\/p>\n\n\n\n
                  \n
                • GitHub account<\/li>\n\n\n\n
                • GitHub repository<\/li>\n\n\n\n
                • Docker<\/li>\n\n\n\n
                • Permission to publish to the target namespace<\/li>\n\n\n\n
                • PAT classic with appropriate package scope<\/li>\n<\/ul>\n\n\n\n
                  For examples below, replace:<\/p>\n\n\n
                  acme\n<\/code><\/span><\/pre>\n\n\n
                  with your GitHub username or organization.<\/p>\n\n\n\n
                  \n\n\n\n
                  Step 1 \u2014 Create a simple application<\/h4>\n\n\n\n
                  Create index.html<\/code>:<\/p>\n\n\n
                  <h1<\/span>><\/span>Hello from GitHub Packages<\/h1<\/span>><\/span>\n<\/code><\/span>Code language:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n\n\n
                  Create Dockerfile<\/code>:<\/p>\n\n\n
                  FROM nginx:alpine\n\nCOPY .\/index.html \/usr\/share\/nginx\/html\/index.html\n\nLABEL org.opencontainers.image.source=\"https:\/\/github.com\/acme\/hello-packages\"<\/span>\nLABEL org.opencontainers.image.description=\"GitHub Packages Essentials demo\"<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                  The source label helps GitHub associate the image with its source repository.<\/p>\n\n\n\n
                  \n\n\n\n
                  Step 2 \u2014 Authenticate to GHCR<\/h4>\n\n\n
                  export<\/span> CR_PAT=\"YOUR_PAT_CLASSIC\"<\/span>\n\necho \"$CR_PAT\"<\/span> | docker login ghcr.io \\\n  -u YOUR_GITHUB_USERNAME \\\n  --password-stdin\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                  Expected result:<\/p>\n\n\n
                  Login Succeeded\n<\/code><\/span><\/pre>\n\n\n
                  \n\n\n\n
                  Step 3 \u2014 Build the image<\/h4>\n\n\n
                  docker<\/span> build<\/span> -t<\/span> hello-packages<\/span>:1.0.0<\/span> .\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                  Verify locally:<\/p>\n\n\n
                  docker images\n<\/code><\/span><\/pre>\n\n\n
                  \n\n\n\n
                  Step 4 \u2014 Tag the image for GHCR<\/h4>\n\n\n
                  docker tag hello-packages:1.0.0 \\\n  ghcr.io\/acme\/hello-packages:1.0.0\n<\/code><\/span><\/pre>\n\n\n
                  Image naming pattern:<\/p>\n\n\n
                  ghcr.io\/OWNER\/IMAGE:TAG\n<\/code><\/span><\/pre>\n\n\n
                  \n\n\n\n
                  Step 5 \u2014 Push the image<\/h4>\n\n\n
                  docker push ghcr.io\/acme\/hello-packages:1.0.0\n<\/code><\/span><\/pre>\n\n\n
                  Expected result:<\/p>\n\n\n\n
                  The image layers are uploaded and GitHub creates or updates the package.<\/p>\n\n\n\n
                  \n\n\n\n
                  Step 6 \u2014 Verify in GitHub<\/h4>\n\n\n\n
                  Open the owner account or organization and navigate to Packages<\/strong>.<\/p>\n\n\n\n
                  Confirm:<\/p>\n\n\n\n
                    \n
                  • Package exists<\/li>\n\n\n\n
                  • Version\u00a01.0.0<\/code>\u00a0exists<\/li>\n\n\n\n
                  • Source repository is correct<\/li>\n\n\n\n
                  • Visibility is correct<\/li>\n\n\n\n
                  • Package metadata is visible<\/li>\n<\/ul>\n\n\n\n
                    \n\n\n\n
                    Step 7 \u2014 Pull the image<\/h4>\n\n\n
                    docker pull ghcr.io\/acme\/hello-packages:1.0.0\n<\/code><\/span><\/pre>\n\n\n
                    Run it:<\/p>\n\n\n
                    docker run --rm -p 8080:80 \\\n  ghcr.io\/acme\/hello-packages:1.0.0\n<\/code><\/span><\/pre>\n\n\n
                    Open:<\/p>\n\n\n
                    http:\/\/localhost:8080<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                    Expected result:<\/p>\n\n\n
                    Hello from<\/span> GitHub Packages\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                    \n\n\n\n
                    10. Tag vs Digest<\/h3>\n\n\n\n
                    A container can be referenced using a tag:<\/p>\n\n\n
                    ghcr.io\/acme\/hello-packages:1.0.0\n<\/code><\/span><\/pre>\n\n\n
                    or an immutable digest:<\/p>\n\n\n
                    ghcr.io\/acme\/hello-packages@sha256:...\n<\/code><\/span><\/pre>\n\n\n
                    Why digest matters<\/h4>\n\n\n\n
                    Tags are human-friendly references. A digest identifies exact content.<\/p>\n\n\n\n
                    For production deployments, digest pinning gives the strongest guarantee that the artifact being deployed is exactly the artifact that was tested.<\/p>\n\n\n\n
                    Recommended release tags<\/h4>\n\n\n\n
                    A mature image may have:<\/p>\n\n\n
                    2.4<\/span>.1<\/span>\n2.4<\/span>\n2\nsha-a1b2c3d<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                    Avoid using only:<\/p>\n\n\n
                    latest\n<\/code><\/span><\/pre>\n\n\n
                    for production.<\/p>\n\n\n\n
                    \n\n\n\n
                    Part 5 \u2014 Automate Publishing with GitHub Actions<\/h2>\n\n\n\n
                    11. Why Move Publishing into CI?<\/h3>\n\n\n\n
                    Manual publishing is useful for learning, but production publishing should normally happen in CI.<\/p>\n\n\n\n
                    Benefits:<\/p>\n\n\n\n
                      \n
                    • Reproducible build<\/li>\n\n\n\n
                    • Automated testing<\/li>\n\n\n\n
                    • Centralized credentials<\/li>\n\n\n\n
                    • Audit trail<\/li>\n\n\n\n
                    • Controlled permissions<\/li>\n\n\n\n
                    • Easier provenance and security controls<\/li>\n<\/ul>\n\n\n\n
                      Recommended lifecycle:<\/p>\n\n\n
                      flowchart<\/span> LR<\/span>\n    A<\/span>[Commit \/ Release]<\/span> --<\/span>> B<\/span>[Checkout]<\/span>\n    B<\/span> --<\/span>> C<\/span>[Build]<\/span>\n    C<\/span> --<\/span>> D<\/span>[Test]<\/span>\n    D<\/span> --<\/span>> E<\/span>[Login]<\/span>\n    E<\/span> --<\/span>> F<\/span>[Publish]<\/span>\n    F<\/span> --<\/span>> G<\/span>[Verify]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                      \n\n\n\n
                      12. Lab 2 \u2014 Publish GHCR Image Using GitHub Actions<\/h3>\n\n\n\n
                      Create:<\/p>\n\n\n
                      .github\/workflows\/publish.yml\n<\/code><\/span><\/pre>\n\n\n
                      Add:<\/p>\n\n\n
                      name<\/span>: Publish container\n\non:\n  release:\n    types: [published]\n\npermissions:\n  contents: read\n  packages: write\n\njobs:\n  publish:\n    runs-on: ubuntu-latest\n\n    steps:\n      - name: Checkout\n        uses: actions\/checkout@v6\n\n      - name: Login to GHCR\n        uses: docker\/login-action@v3\n        with:\n          registry: ghcr.io\n          username: ${{ github.actor }}\n          password: ${{ secrets.GITHUB_TOKEN }}\n\n      - name: Build image\n        run: |\n          docker build \\\n            -t ghcr.io\/${{ github.repository }}:${{ github.event.release.tag_name }} \\\n            .\n\n      - name: Push image\n        run: |\n          docker push \\\n            ghcr.io\/${{ github.repository }}:${{ github.event.release.tag_name }}\n<\/code><\/span>Code language:<\/span> HTTP<\/span> (<\/span>http<\/span>)<\/span><\/small><\/pre>\n\n\n
                      What this workflow does<\/h4>\n\n\n\n
                        \n
                      1. Starts when a GitHub Release is published.<\/li>\n\n\n\n
                      2. Checks out the source code.<\/li>\n\n\n\n
                      3. Authenticates to GHCR using\u00a0GITHUB_TOKEN<\/code>.<\/li>\n\n\n\n
                      4. Builds the container.<\/li>\n\n\n\n
                      5. Tags it using the release tag.<\/li>\n\n\n\n
                      6. Publishes it to GHCR.<\/li>\n<\/ol>\n\n\n\n
                        Why the permissions block matters<\/h4>\n\n\n
                        permissions:\n  contents: read\n  packages: write\n<\/code><\/span><\/pre>\n\n\n
                        The workflow receives only the access it needs.<\/p>\n\n\n\n
                        Do not assume the default token permissions are sufficient.<\/p>\n\n\n\n
                        \n\n\n\n
                        13. Better Production Pattern: Test Before Publish<\/h3>\n\n\n\n
                        Publishing should depend on successful tests.<\/p>\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    runs-on: ubuntu-latest\n    permissions:\n      contents: read\n      packages: write\n\n    steps:\n      - uses: actions\/checkout@v6\n      <em<\/span>><\/span># login, build, and publish steps<\/em<\/span>><\/span>\n<\/code><\/span>Code language:<\/span> HTML, XML<\/span> (<\/span>xml<\/span>)<\/span><\/small><\/pre>\n\n\n
                        The key line is:<\/p>\n\n\n
                        needs<\/span>: test\n<\/code><\/span>Code language:<\/span> HTTP<\/span> (<\/span>http<\/span>)<\/span><\/small><\/pre>\n\n\n
                        If testing fails, publishing does not start.<\/p>\n\n\n\n
                        Essential release rule<\/h4>\n\n\n
                        Build -> Test -> Package -> Publish\n<\/code><\/span><\/pre>\n\n\n
                        not:<\/p>\n\n\n
                        Build -> Publish -> Hope tests pass\n<\/code><\/span><\/pre>\n\n\n
                        \n\n\n\n
                        Part 6 \u2014 Cross-Repository Package Access<\/h2>\n\n\n\n
                        14. Producer and Consumer Repositories<\/h3>\n\n\n\n
                        Real organizations often separate the repository that creates a package from the repositories that consume it.<\/p>\n\n\n
                        flowchart<\/span> LR<\/span>\n    A<\/span>[Producer Repo]<\/span> --<\/span>> B<\/span>[GitHub Actions]<\/span>\n    B<\/span> --<\/span>> C<\/span>[Organization Package]<\/span>\n    C<\/span> --<\/span>> D<\/span>[Consumer Repo A]<\/span>\n    C<\/span> --<\/span>> E<\/span>[Consumer Repo B]<\/span>\n    C<\/span> --<\/span>> F<\/span>[Consumer Repo C]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                        Example:<\/p>\n\n\n
                        shared-types repo\n        |\n        v\n@acme\/shared-types\n        |\n   +----+----+\n   |         |\npayments   orders\n<\/code><\/span><\/pre>\n\n\n
                        For granular packages, GitHub lets you grant selected repositories access through package settings.<\/p>\n\n\n\n
                        Typical cross-repository flow<\/h4>\n\n\n\n
                          \n
                        1. Publish the package from repository A.<\/li>\n\n\n\n
                        2. Open the package settings.<\/li>\n\n\n\n
                        3. Find\u00a0Manage Actions access<\/strong>.<\/li>\n\n\n\n
                        4. Add repository B.<\/li>\n\n\n\n
                        5. Grant only the required role.<\/li>\n\n\n\n
                        6. In repository B, configure:<\/li>\n<\/ol>\n\n\n
                          permissions:\n  contents: read\n  packages: read\n<\/code><\/span><\/pre>\n\n\n
                            \n
                          1. Consume the package using\u00a0GITHUB_TOKEN<\/code>.<\/li>\n<\/ol>\n\n\n\n
                            Critical concept<\/h4>\n\n\n\n
                            Token scope alone is not enough.<\/p>\n\n\n\n
                            A workflow can have:<\/p>\n\n\n
                            packages<\/span>: read\n<\/code><\/span>Code language:<\/span> HTTP<\/span> (<\/span>http<\/span>)<\/span><\/small><\/pre>\n\n\n
                            and still fail if the repository itself has not been granted access to the package.<\/p>\n\n\n\n
                            Think of authorization as two layers:<\/p>\n\n\n
                            Workflow token permission\n        +\nPackage\/repository access\n        =\nSuccessful package operation\n<\/code><\/span><\/pre>\n\n\n
                            \n\n\n\n
                            Part 7 \u2014 Understand the Other Registries<\/h2>\n\n\n\n
                            15. Essential Ecosystem Examples<\/h3>\n\n\n\n
                            You do not need to master every registry during this two-hour session. You should understand the configuration pattern.<\/p>\n\n\n\n
                            npm<\/h4>\n\n\n\n
                            Package name:<\/p>\n\n\n
                            {\n  \"name\"<\/span>: \"@acme\/shared-utils\"<\/span>,\n  \"version\"<\/span>: \"1.2.0\"<\/span>\n}\n<\/code><\/span>Code language:<\/span> JSON \/ JSON with Comments<\/span> (<\/span>json<\/span>)<\/span><\/small><\/pre>\n\n\n
                            .npmrc<\/code>:<\/p>\n\n\n
                            @acme:registry=https:\/\/npm.pkg.github.com<\/span>\n\/\/npm.pkg.github.com\/:_authToken=${NODE_AUTH_TOKEN}<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                            Publish:<\/p>\n\n\n
                            npm publish\n<\/code><\/span><\/pre>\n\n\n
                            Install:<\/p>\n\n\n
                            npm<\/span> install<\/span> @acme<\/span>\/shared-utils@1<\/span>.2.0\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                            Maven<\/h4>\n\n\n\n
                            Endpoint pattern:<\/p>\n\n\n
                            https:\/\/maven.pkg.github.com\/OWNER\/REPOSITORY<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                            Publish:<\/p>\n\n\n
                            mvn --batch-mode deploy\n<\/code><\/span><\/pre>\n\n\n
                            Important: Maven packages are repository scoped<\/strong>.<\/p>\n\n\n\n
                            Gradle<\/h4>\n\n\n\n
                            Publish:<\/p>\n\n\n
                            .\/gradlew publish\n<\/code><\/span><\/pre>\n\n\n
                            Important: GitHub Gradle packages use Maven-format publishing and are repository scoped<\/strong>.<\/p>\n\n\n\n
                            NuGet<\/h4>\n\n\n\n
                            Add source:<\/p>\n\n\n
                            dotnet nuget add source \\\n  --name github \\\n  \"https:\/\/nuget.pkg.github.com\/acme\/index.json\"<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                            Publish:<\/p>\n\n\n
                            dotnet<\/span> nuget<\/span> push<\/span> PACKAGE<\/span>.nupkg<\/span> \\\n  --source<\/span> github<\/span> \\\n  --api-key<\/span> YOUR_PAT_CLASSIC<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                            RubyGems<\/h4>\n\n\n\n
                            Registry pattern:<\/p>\n\n\n
                            https:\/\/rubygems.pkg.github.com\/NAMESPACE<\/span>\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                            Build:<\/p>\n\n\n
                            gem<\/span> build<\/span> package<\/span>.gemspec<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                            Publish:<\/p>\n\n\n
                            gem push \\\n  --host https:\/\/rubygems.pkg.github.com\/acme \\<\/span>\n  package.gem\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                            \n\n\n\n
                            Part 8 \u2014 Essential Security and Release Practices<\/h2>\n\n\n\n
                            16. The 10 Rules Worth Remembering<\/h3>\n\n\n\n
                              \n
                            1. Prefer organization ownership for company packages.<\/li>\n\n\n\n
                            2. Prefer\u00a0GITHUB_TOKEN<\/code>\u00a0instead of long-lived PATs in Actions.<\/li>\n\n\n\n
                            3. Use minimum token permissions.<\/li>\n\n\n\n
                            4. Publish production packages from trusted CI.<\/li>\n\n\n\n
                            5. Test before publishing.<\/li>\n\n\n\n
                            6. Do not reuse release version numbers.<\/li>\n\n\n\n
                            7. Use SemVer for libraries where appropriate.<\/li>\n\n\n\n
                            8. Use immutable container digests for production deployment.<\/li>\n\n\n\n
                            9. Do not store credentials in repository files.<\/li>\n\n\n\n
                            10. Grant consumers Read access, not Write\/Admin access.<\/li>\n<\/ol>\n\n\n\n
                              Good vs risky<\/h4>\n\n\n\n
                              Risky<\/th>Better<\/th><\/tr><\/thead>
                              Shared PAT<\/td>Individual auth or GITHUB_TOKEN<\/code><\/td><\/tr>
                              Admin token for downloads<\/td>Read-only access<\/td><\/tr>
                              Publish manually from laptop<\/td>Controlled CI publishing<\/td><\/tr>
                              Deploy latest<\/code><\/td>Deploy version + digest<\/td><\/tr>
                              Rebuild for each environment<\/td>Build once, promote same artifact<\/td><\/tr>
                              Unlimited dev versions<\/td>Retention\/cleanup policy<\/td><\/tr>
                              Package with no source link<\/td>Connect package to source repository<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                              \n\n\n\n
                              17. Build Once, Deploy Many<\/h3>\n\n\n\n
                              A mature delivery process promotes the same artifact through environments.<\/p>\n\n\n
                              flowchart<\/span> LR<\/span>\n    A<\/span>[Commit]<\/span> --<\/span>> B<\/span>[Build + Test]<\/span>\n    B<\/span> --<\/span>> C<\/span>[Immutable Package]<\/span>\n    C<\/span> --<\/span>> D<\/span>[Dev]<\/span>\n    D<\/span> --<\/span>> E<\/span>[Stage]<\/span>\n    E<\/span> --<\/span>> F<\/span>[Production]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                              Do not rebuild independently for staging and production.<\/p>\n\n\n\n
                              Why?<\/p>\n\n\n\n
                              Because two builds from the same Git commit can still contain different dependency resolutions, timestamps, base image layers, or build-environment effects.<\/p>\n\n\n\n
                              For containers, promote the same digest.<\/p>\n\n\n\n
                              Good:<\/p>\n\n\n
                              ghcr.io\/acme\/api@sha256:abc123...\n<\/code><\/span><\/pre>\n\n\n
                              Riskier:<\/p>\n\n\n
                              ghcr.io\/acme\/api:latest\n<\/code><\/span><\/pre>\n\n\n
                              \n\n\n\n
                              Part 9 \u2014 Troubleshooting<\/h2>\n\n\n\n
                              18. Fast Troubleshooting Matrix<\/h3>\n\n\n\n
                              Problem<\/th>Likely cause<\/th>Check<\/th><\/tr><\/thead>
                              401 Unauthorized<\/code><\/td>Invalid\/expired credential<\/td>Token, login, SSO authorization<\/td><\/tr>
                              Pull\/install denied<\/td>Missing read access<\/td>Package ACL + packages: read<\/code><\/td><\/tr>
                              Push denied<\/td>Missing write access<\/td>Package role + packages: write<\/code><\/td><\/tr>
                              Works locally, fails in Actions<\/td>Workflow token too restricted<\/td>permissions:<\/code> block<\/td><\/tr>
                              Cross-repo package not found<\/td>Consumer repo not granted access<\/td>Manage Actions access<\/td><\/tr>
                              Image tag not found<\/td>Wrong tag or owner<\/td>Package page and image reference<\/td><\/tr>
                              exec format error<\/code><\/td>Architecture mismatch<\/td>Image platforms<\/td><\/tr>
                              Version already exists<\/td>Immutable version collision<\/td>Increment version<\/td><\/tr>
                              npm publishes to npmjs.org<\/td>Registry config incorrect<\/td>.npmrc<\/code> \/ package config<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                              Troubleshooting order<\/h4>\n\n\n\n
                              When package access fails, check in this order:<\/p>\n\n\n
                              1. Correct registry endpoint?\n2. Correct package name\/version?\n3. Authentication working?\n4. Token has required scope\/permission?\n5. User\/repository has package access?\n6. Workflow permissions correct?\n7. Cross-repository access configured?\n<\/code><\/span><\/pre>\n\n\n
                              This sequence prevents random trial-and-error debugging.<\/p>\n\n\n\n
                              \n\n\n\n
                              Part 10 \u2014 Five-Minute Final Practice<\/h2>\n\n\n\n
                              19. Mini Exercise<\/h3>\n\n\n\n
                              Assume:<\/p>\n\n\n\n
                                \n
                              • Organization:\u00a0acme<\/code><\/li>\n\n\n\n
                              • Producer repository:\u00a0payments-api<\/code><\/li>\n\n\n\n
                              • Package:\u00a0ghcr.io\/acme\/payments-api<\/code><\/li>\n\n\n\n
                              • Consumer repository:\u00a0deployment-platform<\/code><\/li>\n<\/ul>\n\n\n\n
                                Answer the following before checking the solution.<\/p>\n\n\n\n
                                Questions<\/h4>\n\n\n\n
                                  \n
                                1. Which registry stores the image?<\/li>\n\n\n\n
                                2. Is GHCR granular or repository scoped?<\/li>\n\n\n\n
                                3. What local token type should you use for Docker authentication?<\/li>\n\n\n\n
                                4. What workflow permission is required to publish?<\/li>\n\n\n\n
                                5. What workflow permission is required only to pull?<\/li>\n\n\n\n
                                6. What else must be configured when another repository consumes a private package?<\/li>\n\n\n\n
                                7. Which is safer for production:\u00a0:latest<\/code>\u00a0or\u00a0@sha256:...<\/code>?<\/li>\n\n\n\n
                                8. Should production rebuild the image after staging approval?<\/li>\n<\/ol>\n\n\n\n
                                  Answers<\/h4>\n\n\n\n
                                    \n
                                  1. GitHub Container Registry \/\u00a0ghcr.io<\/code>.<\/li>\n\n\n\n
                                  2. Granular user\/organization scoped.<\/li>\n\n\n\n
                                  3. PAT classic with the required package scope.<\/li>\n\n\n\n
                                  4. packages: write<\/code>.<\/li>\n\n\n\n
                                  5. packages: read<\/code>.<\/li>\n\n\n\n
                                  6. Grant the consumer repository package\/Actions access.<\/li>\n\n\n\n
                                  7. Immutable digest:\u00a0@sha256:...<\/code>.<\/li>\n\n\n\n
                                  8. No. Promote the same tested artifact.<\/li>\n<\/ol>\n\n\n\n
                                    \n\n\n\n
                                    Part 11 \u2014 Essential Cheat Sheet<\/h2>\n\n\n\n
                                    20. Registry Endpoints<\/h3>\n\n\n\n
                                    Registry<\/th>Endpoint<\/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 endpoint<\/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
                                    \n\n\n\n
                                    21. PAT Classic Scopes<\/h3>\n\n\n
                                    read<\/span>:packages<\/span>\nwrite<\/span>:packages<\/span>\ndelete<\/span>:packages<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                                    \n\n\n\n
                                    22. Workflow Permissions<\/h3>\n\n\n\n
                                    Read:<\/p>\n\n\n
                                    permissions:\n  contents: read\n  packages: read\n<\/code><\/span><\/pre>\n\n\n
                                    Publish:<\/p>\n\n\n
                                    permissions:\n  contents: read\n  packages: write\n<\/code><\/span><\/pre>\n\n\n
                                    \n\n\n\n
                                    23. GHCR Commands<\/h3>\n\n\n\n
                                    Login:<\/p>\n\n\n
                                    echo<\/span> \"$CR_PAT\"<\/span> | docker login ghcr.io \\\n  -u \"$GITHUB_USER\"<\/span> \\\n  --password-stdin\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
                                    Build:<\/p>\n\n\n
                                    docker build -t ghcr.io\/acme\/api:1.0.0 .\n<\/code><\/span><\/pre>\n\n\n
                                    Push:<\/p>\n\n\n
                                    docker push ghcr.io\/acme\/api:1.0.0\n<\/code><\/span><\/pre>\n\n\n
                                    Pull:<\/p>\n\n\n
                                    docker pull ghcr.io\/acme\/api:1.0.0\n<\/code><\/span><\/pre>\n\n\n
                                    Pull immutable digest:<\/p>\n\n\n
                                    docker pull ghcr.io\/acme\/api@sha256:REPLACE_WITH_DIGEST\n<\/code><\/span><\/pre>\n\n\n
                                    \n\n\n\n
                                    Part 12 \u2014 What to Learn Next<\/h2>\n\n\n\n
                                    24. Topics Intentionally Left for the Complete Guide<\/h3>\n\n\n\n
                                    After completing this Essentials tutorial, move to the full reference guide for deeper study of:<\/p>\n\n\n\n
                                      \n
                                    • Package deletion and restoration<\/li>\n\n\n\n
                                    • REST API and\u00a0gh api<\/code><\/li>\n\n\n\n
                                    • Webhooks<\/li>\n\n\n\n
                                    • GitHub Apps<\/li>\n\n\n\n
                                    • Billing and storage management<\/li>\n\n\n\n
                                    • Multi-architecture builds<\/li>\n\n\n\n
                                    • Automated cleanup<\/li>\n\n\n\n
                                    • Registry migration<\/li>\n\n\n\n
                                    • Legacy Docker registry migration<\/li>\n\n\n\n
                                    • Artifact attestations<\/li>\n\n\n\n
                                    • SBOM<\/li>\n\n\n\n
                                    • Dependency graph and Dependabot<\/li>\n\n\n\n
                                    • Linked artifacts<\/li>\n\n\n\n
                                    • Enterprise-specific behavior<\/li>\n\n\n\n
                                    • Organization governance<\/li>\n\n\n\n
                                    • Audit and usage reporting<\/li>\n<\/ul>\n\n\n\n
                                      These are important topics, but they are better studied after the package lifecycle, authentication model, permissions, GHCR workflow, and CI publishing process are understood.<\/p>\n\n\n\n
                                      \n\n\n\n
                                      Part 13 \u2014 Wrap-Up<\/h2>\n\n\n\n
                                      25. Final Mental Model<\/h3>\n\n\n\n
                                      If you remember only one flow from this tutorial, remember this:<\/p>\n\n\n
                                      flowchart<\/span> LR<\/span>\n    A<\/span>[Source]<\/span> --<\/span>> B<\/span>[Build]<\/span>\n    B<\/span> --<\/span>> C<\/span>[Test]<\/span>\n    C<\/span> --<\/span>> D<\/span>[Package]<\/span>\n    D<\/span> --<\/span>> E<\/span>[Publish with least privilege]<\/span>\n    E<\/span> --<\/span>> F<\/span>[GitHub Packages]<\/span>\n    F<\/span> --<\/span>> G<\/span>[Authorized Consumer]<\/span>\n    G<\/span> --<\/span>> H<\/span>[Deploy exact version\/digest]<\/span>\n<\/code><\/span>Code language:<\/span> CSS<\/span> (<\/span>css<\/span>)<\/span><\/small><\/pre>\n\n\n
                                      And remember these four rules:<\/p>\n\n\n
                                      1.<\/span> Know the registry permission model.\n2.<\/span> Use the smallest required permission.\n3.<\/span> Publish from<\/span> trusted CI.\n4.<\/span> Promote immutable artifacts.\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
                                      If those four ideas are clear, you have the foundation needed to work safely and effectively with GitHub Packages.<\/p>\n\n\n\n
                                      \n\n\n\n
                                      26. Two-Hour Completion Checklist<\/h3>\n\n\n\n
                                      Before considering the Essentials session complete, verify that the student can answer Yes<\/strong> to the following:<\/p>\n\n\n\n
                                        \n
                                      • [ ] I can explain what GitHub Packages is.<\/li>\n\n\n\n
                                      • [ ] I know when to use Packages vs Releases vs Actions artifacts.<\/li>\n\n\n\n
                                      • [ ] I know the six supported package ecosystems.<\/li>\n\n\n\n
                                      • [ ] I know which registries are granular and which are repository scoped.<\/li>\n\n\n\n
                                      • [ ] I understand Read \/ Write \/ Admin package roles.<\/li>\n\n\n\n
                                      • [ ] I understand PAT classic vs\u00a0GITHUB_TOKEN<\/code>.<\/li>\n\n\n\n
                                      • [ ] I can log in to GHCR.<\/li>\n\n\n\n
                                      • [ ] I can build, tag, push, and pull an image.<\/li>\n\n\n\n
                                      • [ ] I can publish an image using GitHub Actions.<\/li>\n\n\n\n
                                      • [ ] I understand cross-repository package access.<\/li>\n\n\n\n
                                      • [ ] I understand why production should use immutable versions\/digests.<\/li>\n\n\n\n
                                      • [ ] I know the first checks to make when authentication or authorization fails.<\/li>\n<\/ul>\n\n\n\n
                                        \n\n\n\n
                                        27. Source<\/h3>\n\n\n\n
                                        This Essentials tutorial is a condensed learning path derived from the GitHub Packages \u2014 Complete Reference Guide & Hands-On Tutorial<\/strong>, last verified September 2026. It intentionally prioritizes foundational concepts and hands-on skills suitable for a two-hour study\/practice session rather than reproducing the complete advanced reference.<\/p>\n","protected":false},"excerpt":{"rendered":"
                                        Last Verified: September 2026Scope: GitHub.com \/ GitHub Enterprise Cloud unless explicitly stated otherwiseDuration: ~2 hours including hands-on practiceAudience: Developers, DevOps engineers, platform engineers, administrators, trainers, and studentsPrimary hands-on registry: GitHub Container Registry… <\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_joinchat":[],"footnotes":""},"categories":[11138],"tags":[],"class_list":["post-78748","post","type-post","status-publish","format-standard","hentry","category-best-tools"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/78748","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/comments?post=78748"}],"version-history":[{"count":1,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/78748\/revisions"}],"predecessor-version":[{"id":78749,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/78748\/revisions\/78749"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/media?parent=78748"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/categories?post=78748"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/tags?post=78748"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}