Quickstart¶

Drop the snippet below into your bitbucket-pipelines.yml. It uses OIDC so no AWS access keys ever land in your pipeline. The IAM trust policy that pairs with it lives in the OIDC setup guide.

image: atlassian/default-image:4

pipelines:
  branches:
    main:
      - step:
          name: Deploy to EKS
          deployment: production
          oidc: true                                     # Bitbucket sets BITBUCKET_STEP_OIDC_TOKEN
          script:
            - pipe: docker://ghcr.io/yves-vogl/aws-eks-helm-deploy:2
              variables:
                OIDC_AUDIENCE: $OIDC_AUDIENCE            # ari:cloud:bitbucket::workspace/<UUID>
                ROLE_ARN: $DEPLOY_ROLE_ARN
                AWS_REGION: eu-central-1
                CLUSTER_NAME: my-eks-cluster
                CHART: repo://bitnami/nginx
                REPO_URL: https://charts.bitnami.com/bitnami
                CHART_VERSION: 18.2.0
                RELEASE_NAME: nginx
                NAMESPACE: production
                WAIT: "true"
                TIMEOUT: 10m

Image pinning

Pin the pipe to :2 (rolling major) or to a specific version like :2.0.0. :latest is also published but pinning to a major is the recommended pattern — you get patch + minor updates automatically while a major-version bump always requires an explicit migration step.

Need static AWS keys for now?¶

If OIDC isn't an option yet, the examples/basic/ snippet has the same shape with AWS_ACCESS_KEY_ID + AWS_SECRET_ACCESS_KEY instead. When you're ready to migrate, follow the Migrating from static keys walkthrough.

More copy-paste-ready snippets¶

Scenario	Path
Static keys + local chart	`examples/basic/`
OIDC + Helm repo chart	`examples/oidc-only/`
OIDC + OCI chart from GHCR	`examples/oci-chart/`
Multi-env with `ACTION=diff` PR comments	`examples/multi-env/`
v1 → v2 line-by-line migration diff	`examples/migration-v1-to-v2/`

All five bitbucket-pipelines.yml files in examples/ are schema-validated in CI via check-jsonschema --builtin-schema vendor.bitbucket-pipelines.

Variables¶

The full, autogenerated reference is at reference/variables. For an at-a-glance summary of the most common variables — auth, cluster + chart, action + behaviour — see the README.

Verifying releases¶

Every release is signed (Cosign keyless) and ships SPDX + CycloneDX SBOMs. The exact cosign verify and cosign verify-attestation commands live in the README "Verifying releases" section.