Skip to main content

Release Manifest & Distribution

Use your BigHammer reader role to mirror entitled container images, Helm charts, and code packages into your Azure Container Registry (ACR) and private artifact stores. Start with Step 1 — customer profile onboarding; then run the mirror workflow once per release.

Mirror — do not consume from BigHammer catalog long-term

BigHammer catalog artifacts may be archived or removed after a retention period. Always mirror into your ACR (and your private PyPI/npm repos if entitled) and treat those copies as your source of truth.


Step 1 — Customer profile registry (onboarding)

Before you can pull or mirror any artifact, BigHammer registers a customer profile for your organization. That profile defines who you are, what you are entitled to pull, and how your CI authenticates to the shared BigHammer release catalog.

BigHammer uses the profile to provision your dedicated IAM reader role:

arn:aws:iam::<bh-aws-account-id>:role/bh-artifact-reader-<customer_id>

You do not get a separate copy of the catalog at BigHammer. Access is scoped to entitled charts, images, and packages only.

What you submit

Send the following to your BigHammer contact. They map it to a CustomerProfile (apiVersion: bighammer.io/v1).

Organization and contacts

FieldExampleNotes
Customer ID<customer-id>Stable kebab-case name; becomes part of the reader role
Display nameExample CorpLegal or team name
Technical contactdevops@example.comHandoff and entitlement changes

Azure deployment

FieldExample
Primary cloudazure
Azure subscription ID00000000-0000-0000-0000-000000000000
Region(s)<your-azure-region>
AKS cluster name<your-aks-cluster> (if known)

CI trust (choose at least one)

MethodWhat you provide
GitHub Actions OIDCGitHub org + repo path(s)
GitLab CI OIDCGitLab project path
Azure DevOps OIDCOrganization, project, service connection details
AWS cross-accountYour AWS account ID for mirror jobs that assume the BH reader role

Artifact entitlements

FieldTypical value (Azure)
Version channelstable, rc, or lts
Helm charts (OCI)bighammer, bhrabbitmq, bh-gateway (optional)
Chart pathsazure/bh-helm-release/<chart>
Container imagesplatform_release (full chart image set) or named allowlist
Code packages (optional)Entitled PyPI / npm package names

Target registries (your Azure subscription)

ArtifactAzure formatExample name
Container imagesACR repositorybh-docker-public or customer-defined
Helm OCI chartsACR OCI artifactbh-helm-release
Python packagesPrivate feed / ArtifactsCustomer-defined
npm packagesPrivate feed / ArtifactsCustomer-defined

What BigHammer returns (handoff pack)

ItemExample
Reader role ARNarn:aws:iam::<bh-aws-account-id>:role/bh-artifact-reader-<customer-id>
AWS region<bh-catalog-aws-region>
Release manifestPinned chart versions, image tags, package versions
Entitlements summaryCharts, images, and packages in scope
Trust runbookGitHub OIDC, GitLab OIDC, or AWS AssumeRole + ExternalId
Source URIsBigHammer ECR and CodeArtifact endpoints (mirror pull only)

Store ExternalId in Key Vault — never commit it to Git.

Onboarding checklist

StepDone
Intake submitted (org, Azure subscription, CI trust, entitlements)
ACR created in your subscription (Docker + Helm OCI repos)
Handoff pack received (reader role ARN + release manifest)
Test assume-role from CI (dry pull or aws sts get-caller-identity)

Only after Step 1 is complete, proceed to mirror artifacts (Steps 2–4 below).

Mirrored URIs (examples):

<registry>.azurecr.io/bh-ui:<tag>
oci://<registry>.azurecr.io/bh-helm-release/bighammer:<version>

Steps 2–4 — Mirror workflow

StepEnvironmentAction
1You → BigHammerComplete customer profile intake; receive handoff pack
2Your CI ↔ BH AWSAssume bh-artifact-reader-<customer_id>
3Your CI ← BH catalogPull entitled images, charts, and code packages
4Your CI → Your ACRMirror to your Docker and Helm OCI repositories

Entitled Helm chart paths (Azure)

After mirror, install from your ACR, not BigHammer ECR:

ChartBigHammer source (mirror from)Your ACR OCI path
Platformoci://<bh-aws-account-id>.dkr.ecr.<bh-catalog-aws-region>.amazonaws.com/azure/bh-helm-release/bighammeroci://<registry>.azurecr.io/bh-helm-release/bighammer
RabbitMQ.../azure/bh-helm-release/bhrabbitmqoci://<registry>.azurecr.io/bh-helm-release/bhrabbitmq
Gateway (optional).../azure/bh-helm-release/bh-gatewayoci://<registry>.azurecr.io/bh-helm-release/bh-gateway

Pin versions from the release manifest BigHammer sends per upgrade.


Release manifest

BigHammer sends a release manifest per upgrade. Pin every version in your mirror CI — do not use floating tags.

# release-manifest.yaml (your repo)
release: "2026-06"
channel: stable

charts:
bighammer: "<chart-version>"
bhrabbitmq: "<chart-version>"

images:
bh-ui: "<tag-from-release-manifest>"
bh-catalog-api: "<tag-from-release-manifest>"
bh-audit-api: "<tag-from-release-manifest>"
bh-keycloak: "<tag-from-release-manifest>"
bh-ai-agent: "<tag-from-release-manifest>"

Update global.image.repository and per-service image.tag in values-<env>.yaml to match mirrored tags.


Deploy from mirrored ACR

az acr login --name <registry>

helm pull oci://<registry>.azurecr.io/bh-helm-release/bighammer \
--version <CHART_VERSION>

tar -xzf bighammer-<CHART_VERSION>.tgz
cp bighammer/values.yaml values.yaml
cp bighammer/values-release.yaml values-<env>.yaml # edit all placeholders

helm upgrade --install bighammer ./bighammer \
-f values.yaml \
-f values-<env>.yaml \
-n bh-control-plane \
--create-namespace

Full deploy steps: Platform Deployment.


Testing access (onboarding validation)

Once the customer profile is registered in Terraform and the Reader role is granted:

  1. Run a CI dry-run: assume BH reader role → pull one entitled image → push to ACR.
  2. Run helm pull for entitled chart from BH ECR → push OCI chart to ACR.
  3. Deploy a smoke-test namespace from mirrored artifacts only.

Document results in your runbook before production cutover.


TopicLink
Platform deployPlatform Deployment
Release notesHelm Chart Release Notes
GCP mirror (same BH reader role)GCP Release Manifest