GitHub Actions Production Workflow Vault

Production-ready GitHub Actions without starting from a blank YAML file.

Build, test, scan, package, release and deploy with a practical vault of documented GitHub Actions workflows for applications, containers, infrastructure and cloud platforms. Every file starts read-only, pins its actions to verified commit SHAs, guards against publishing from pull requests, and marks exactly what you need to change.

$19.99 — one-time purchase · instant digital download · no subscription

Workflow Vault

$19.99one-time

Every workflow file in the Vault, for one engineer.

• Twenty workflows: Python, Node.js, Go, Java and .NET CI; Docker build-and-test, GHCR and multi-arch publishing
• Terraform pull request validation and Ansible CI with Molecule
• CodeQL, dependency review, secret scanning, SBOM and build attestation
• Tag-based release with approval, GitHub Pages, Kubernetes deployment by digest
• AWS, Azure and Google Cloud OIDC examples with trust-policy files
• Three reusable workflows, a composite action and caller examples
• README, quick start, customization checklist, security model, pin-update guide
• Updates to 1.x included

Single engineer. Use and modify in unlimited personal and employer repositories.

Get Workflow Vault

Note

Every lesson on this site stays free, including the GitHub Actions lessons that explain each of these files. The Vault is the implementation-ready versions — assembled, pinned, documented and validated — for engineers who would rather adapt than re-derive.

What is in the Vault

Fifty-seven files. Twenty workflows, three reusable workflows, one composite action, examples, fixtures and documentation. Version 1.0.0.

Continuous integration — workflows/continuous-integration/

• Python — ruff, pytest with JUnit and coverage artifacts, 3.11–3.13 matrix
• Node.js — npm cache, lint, test, build, 20/22/24 matrix
• Go — gofmt, vet, go mod tidy check, race-enabled tests, 1.24/1.25 matrix
• Java — Maven with dependency cache, Surefire reports, package artifact, 17/21/25 matrix (Gradle notes)
• .NET — restore, build, test (TRX + coverage), publish, hand-written NuGet cache, 8/9/10 matrix

Each ends in a single … CI passed job to require in a ruleset, so adding a matrix entry never means editing branch protection.

Containers — workflows/containers/

• Docker build and test — Buildx, GitHub Actions layer cache, the Dockerfile’s test stage as a required gate, Trivy image scan; never publishes
• GHCR publish — branch, short-SHA and semver tags, OCI labels, provenance attestation, packages permission on one job only, no push from pull requests or forks
• Multi-architecture — linux/amd64 + linux/arm64 manifest list, QEMU, registry cache, release tags only

Infrastructure as code — workflows/infrastructure/

• Terraform PR validation — fmt, init, validate, Checkov, plan with a read-only OIDC role; plan uploaded as a short-lived artifact rather than a PR comment; fork PRs get no credentials; no apply
• Ansible CI — syntax check, ansible-lint with SARIF, Molecule scenario with the Docker driver, logs uploaded

Security — workflows/security/

• CodeQL — language matrix with build modes, pull request and weekly scans
• Dependency review — severity threshold, licence deny/allow lists, summary comment on failure
• Secret scanning — gitleaks over the full history, SARIF artifact, secure failure
• SBOM and attestation — Syft CycloneDX SBOM, signed build provenance and SBOM attestation, checksums, attached to the GitHub Release

Releases and deployment — workflows/releases/, workflows/deployment/

• Automated release — semver tag validation, build, checksums, then a release environment gate before gh release create
• GitHub Pages — build and deploy jobs separated, exact Pages permissions, non-cancelling concurrency
• Kubernetes — build and publish, deploy by immutable digest into a protected environment, kubeconfig never logged, rollback documented

Cloud authentication with OIDC — workflows/cloud-authentication/

• AWS — configure-aws-credentials with a sample IAM trust policy restricted to one repository and environment
• Azure — azure/login with a federated credential guide and subject formats
• Google Cloud — Workload Identity Federation with a pool/provider setup script and attribute condition

No long-lived cloud keys anywhere. Each example states plainly that it is only as safe as the trust policy you write, and shows the restrictive form.

Reusable automation — reusable-workflows/, composite-actions/, examples/

• Reusable CI (Node or Python; commands as inputs, executed safely through env)
• Reusable Docker build and publish (push guard the caller cannot override; provenance)
• Reusable security scan (gitleaks, Trivy filesystem, dependency review)
• Composite action setup-node-project (detects npm/pnpm/yarn from the lockfile, caches, installs)
• A caller example for each, plus a multi-stage Dockerfile, an Ansible/Molecule example and Node and Python fixture projects the CI workflows run unchanged against

Documentation

README with a selection guide and troubleshooting table · five-minute quick start · customization checklist (branch, versions, cache keys, registries, cloud identity, environments, reviewers, variables, secrets, permissions, rulesets, retention, runners, pins) · security model · pinned-actions table with the verification method and a Dependabot config · reusable-workflows guide (workflow_call, inputs, secrets, permissions, outputs, versioning, cross-repository reuse) · OIDC guide per provider · validation record.

Supported technologies

Area	Covered
Languages	Python · Node.js · Go · Java · .NET
Containers	Docker (BuildKit/Buildx) · GitHub Container Registry · amd64 + arm64
Infrastructure	Terraform · Ansible (Molecule)
Security tooling	CodeQL · dependency review · gitleaks · Trivy · Checkov · Syft · GitHub attestations
Delivery	GitHub Releases · GitHub Pages · Kubernetes
Cloud	AWS · Microsoft Azure · Google Cloud (OIDC)
Runners	GitHub-hosted (Ubuntu); notes for Windows and self-hosted

Security features

• permissions: contents: read at the top of every workflow; widened per job only where needed
• Every third-party action pinned to a full commit SHA with the release version beside it — 31 pins, each verified against the upstream tag on 13 September 2026
• Nothing privileged on pull_request; no pull_request_target anywhere
• Publish and deploy gated by event and by repository, so forks cannot reach a registry or a cluster
• Context values passed through env, never interpolated into shell — no script injection from branch names or inputs
• persist-credentials: false on every checkout
• Protected environments on release, Kubernetes, Pages and the cloud examples
• Concurrency that cancels superseded CI runs and never cancels a deployment mid-rollout

Who this is for

Developers and DevOps engineers who set up CI/CD for more than one repository, know what a job and a step are, and want a reviewed baseline that already has the permissions block, the cache key and the fork guard right.

Who this is not for

If you have never written a workflow, start with the free GitHub Actions fundamentals — the Vault assumes you can read one. If you run one repository with one language, the free CI lesson for it contains a complete workflow already. If your organisation has a platform team publishing reusable workflows, use theirs.

Requirements

A GitHub repository on any plan; a project with build and test commands; a Dockerfile for the container workflows; for cloud deployment, an AWS, Azure or Google Cloud account where you can create an OIDC trust configuration. Nothing to install locally beyond Git.

Delivery, licence and updates

Delivery — a ZIP archive (github-actions-production-workflow-vault-1.0.0.zip, about 75 KB) from your download page, which opens the moment Stripe confirms payment. Bookmark it; it keeps working. Licence — one engineer; use and modify in unlimited personal and employer repositories; no redistribution, resale or competing template product; provided without warranty. The full text is LICENSE.md in the bundle and the Terms apply. Updates — 1.x updates included, from the same download page. Refunds — 14 days, on request, per the Terms.

Sample: the GHCR publish workflow

The publishing job, as shipped — with its own header, customization markers and the comments that explain each security decision:

# Publish to GitHub Container Registry — GitHub Actions Production Workflow Vault v1.0.0
#
# Build on every push and pull request, publish only from the default branch and
# tags — never from a pull request. Git-derived and semver tags, OCI labels,
# provenance attestation, least-privilege packages permission.

name: Publish container to GHCR

on:
  push:
    branches: [main]            # CUSTOMIZE: your default branch
    tags: ["v*.*.*"]
  pull_request:

# Default is read-only; the publish job alone widens to packages/id-token/attestations.
permissions:
  contents: read

jobs:
  build:
    runs-on: ubuntu-latest
    # Publishing needs write on packages; provenance needs id-token + attestations.
    # These are granted to this job only, and the push itself is gated below so a
    # pull request — including from a fork — never reaches the registry.
    permissions:
      contents: read
      packages: write
      id-token: write
      attestations: write
    steps:
      - name: Check out
        uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
        with:
          persist-credentials: false

      - name: Log in to GHCR
        if: github.event_name != 'pull_request'
        uses: docker/login-action@dbcb813823bdd20940b903addbd779551569679f # v4.6.0
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Build and push
        id: build
        uses: docker/build-push-action@53b7df96c91f9c12dcc8a07bcb9ccacbed38856a # v7.3.0
        with:
          context: .
          push: ${{ github.event_name != 'pull_request' }}
          tags: ${{ steps.meta.outputs.tags }}
          cache-from: type=gha
          cache-to: type=gha,mode=max
          provenance: mode=max

Frequently asked questions

What files are included?

Twenty workflow files under `workflows/` (CI for Python, Node.js, Go, Java and .NET; Docker build-and-test, GHCR and multi-arch publishing; Terraform PR validation; Ansible CI; CodeQL, dependency review, secret scanning, SBOM and attestation; release, GitHub Pages, Kubernetes; AWS, Azure and Google Cloud OIDC), three reusable workflows, one composite action, four caller examples, a multi-stage Dockerfile, an Ansible/Molecule example, two fixture projects, and the README, quick start, customization checklist, licence, changelog and five documentation guides. Fifty-seven files; plain YAML, Markdown, JSON and shell.

Is this a subscription?

No. One payment of $19.99, and the files are yours. There is no recurring charge, no account, and nothing to cancel.

Do I need a GitHub paid plan?

No for most of it: CI, containers, Pages, releases, OIDC and Kubernetes work on free plans, public or private. Three features depend on GitHub's plans, not on this product: dependency review and CodeQL on private repositories need GitHub Advanced Security, and artifact attestations on private repositories need GitHub Enterprise Cloud. Each affected file says so in its header.

Can I use the workflows for commercial projects?

Yes. The licence covers any purpose, commercial included, in unlimited repositories.

Can my employer use them?

You can use them in your employer's repositories — that is the normal case. A workflow file committed to a project you work on is use, not redistribution. If several engineers each want the bundle as their own starting point, each needs a purchase; teams standardising across a group should look at the team products.

May I redistribute or resell the templates?

No. You may not share the archive or your download link, publish the bundle, or build a competing template product from it. Committing workflows to your repositories, public or private, is fine.

Are the workflows ready without customization?

No workflow is. Every file marks what you must change with `CUSTOMIZE` — the default branch, runtime versions, commands, image names, cloud identifiers, environment names — and the checklist covers the repository settings around them. Expect the first run in your repository to be the integration test; the quick start walks through doing that on a branch where nothing can be published or deployed.

How are updates delivered?

Through the download page you land on after purchase, which stays valid. Updates within version 1.x are included — pinned action SHAs, GitHub feature changes, corrections. The changelog in the bundle records what changed.

Which languages and platforms are covered?

CI: Python, Node.js, Go, Java (Maven, with Gradle notes) and .NET. Containers: Docker with BuildKit, GitHub Container Registry, amd64 and arm64. Infrastructure: Terraform and Ansible. Security: CodeQL, dependency review, gitleaks, Trivy, Checkov, Syft SBOMs and GitHub attestations. Deployment: GitHub Releases, GitHub Pages, Kubernetes. Cloud: AWS, Microsoft Azure and Google Cloud through OIDC.

Are cloud credentials included?

No — nothing in the product is a secret, and the cloud examples are designed so you never store one. They use GitHub's OIDC tokens with a trust policy you create in your own AWS, Azure or Google Cloud account; sample policy files and setup commands are included, with the restrictions that make them safe spelled out.

Are the workflows guaranteed to work with every repository?

No. They were validated with actionlint and ShellCheck, run against fixture projects, and the Docker workflow's test stage was built — but they were not run against your repository, your cluster or your cloud account. Projects differ; the customization checklist and the troubleshooting sections exist because of that. What is guaranteed is that the files are correct, current GitHub Actions syntax with verified action pins, and that errors in them get corrected.

What is the refund policy for a downloadable product?

The Terms state it: a full refund within 14 days of purchase, on request. Because it is a download, the request is on trust — delete the files and ask.

How is this different from the Professional Toolkit?

The Vault is entirely GitHub Actions: twenty workflows plus reusable workflows and the documentation to run them. The Professional Toolkit is broader and shallower on Actions — five workflow templates alongside Git decision guides, CODEOWNERS and PR templates, GitHub API scripts, security checklists, AI review checklists and DevOps repository templates. If your problem is pipelines, buy the Vault; if it is setting up whole repositories, the Toolkit; both fit together and neither repeats the other.

Related free lessons

Least-privilege permissionsWhy every workflow here starts read-only, and the one org setting that matters most.

Pinning actionsSHA pins, version comments and Dependabot — the policy the Vault applies.

Workflow securityScript injection, pull_request_target and forks: the attacks the guards prevent.

OIDC for cloud deploymentsThe concept behind the three cloud examples.

CI per languagePython, Node.js, Go, Java, .NET, Docker, Terraform and Ansible, each explained step by step.

Lab: secure an unsafe workflowFind the mistakes the Vault's files are written to avoid.

The broader set: Professional Toolkit

The Vault is GitHub Actions only. For the rest of a repository — Git decision guides, annotated CODEOWNERS and pull request templates, GitHub API automation scripts, security and AI review checklists, GitOps and infrastructure repository templates — the Professional Toolkit is the broader product. Its five Actions templates are the starting points; the Vault is the full implementation set.

Implementation-readyProfessional ToolkitTwenty-nine templates, checklists and scripts across Git, GitHub, the GitHub API, Actions, security, AI and DevOps.