AWS ECR CI/CD Build and Push Docker Images to AWS Elastic Container Registry

Build a Docker image and publish it to Amazon Elastic Container Registry (ECR) in a single declarative Kestra flow, using a short-lived ECR authorization token instead of long-lived registry credentials. This blueprint solves a common CI gap for AWS teams: keeping container builds, registry login, tagging, and push in one auditable pipeline that any downstream service (ECS, EKS, or Kubernetes) can pull from, without wiring together shell scripts and aws ecr get-login-password calls.

How it works

1. The fetch_auth_token task (io.kestra.plugin.aws.ecr.GetAuthToken) calls the AWS ECR API to mint a temporary authorization token, authenticating with accessKeyId, secretKeyId, and region pulled from Kestra secrets.
2. The build task (io.kestra.plugin.docker.Build) builds an image from an inline dockerfile (here a python:3.10 base with kestra, requests, and polars[all] installed), tags it with the target ECR repository URL, and sets push: true.
3. The build authenticates to ECR through credentials, using username: AWS and password bound to {{ outputs.fetch_auth_token.token }}, so the freshly minted token flows straight from the first task into the push.

What you get

• A reproducible Docker image published to your private ECR repository on every run.
• Token-based registry login with no static Docker credentials to rotate.
• A single flow that covers authenticate, build, tag, and push.
• An image ready for downstream ECS, EKS, or Kubernetes deployment.

Who it's for

• Platform and DevOps engineers standardizing container builds on AWS.
• Data teams shipping custom Python or worker images for their pipelines.
• Cloud infrastructure teams that want CI image publishing as code.

Why orchestrate this with Kestra

ECR itself only stores images; it has no scheduler, no build step, and no way to chain authentication into a push. Kestra fills that gap with event-driven and scheduled triggers, automatic retries on transient registry or network failures, full execution lineage and logs for every build, and declarative YAML that keeps the entire pipeline version-controlled and reviewable. Token generation and image push become explicit, dependent tasks rather than fragile glue scripts.

Prerequisites

• An AWS account with an existing ECR repository and IAM permissions for ecr:GetAuthorizationToken and image push.
• A Kestra instance with the AWS and Docker plugins available, and a Docker daemon reachable by the worker.

Secrets

• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY
• AWS_DEFAULT_REGION

Quick start

1. Add the three secrets above to your Kestra instance.
2. Replace the example tag (123456789.dkr.ecr.eu-central-1.amazonaws.com/data-infastructure:latest) with your own ECR registry URL, repository, and tag.
3. Adjust the inline dockerfile to match the image you want to build.
4. Run the flow and confirm the new image lands in your ECR repository.

How to extend

• Swap the inline dockerfile for a file-based one checked out from Git earlier in the flow.
• Add a Git trigger so a push to your repository rebuilds and republishes the image automatically.
• Tag images with the execution ID or commit SHA instead of latest for traceable releases.
• Chain a deployment task (ECS, EKS, or Kubernetes) after the push to ship the new image.

Links

• AWS plugin docs
• Docker plugin docs
• AWS orchestration with Kestra
• Docker orchestration with Kestra