New to Kestra?
Use blueprints to kickstart your first workflows.
Pull a container image from Amazon ECR registry and run a Python script
Authenticate with Amazon ECR, pull a private image, and run Python inside it with Kestra. Fresh tokens on every run, no manual ECR login.
Categories
id: python-aws-ecr
namespace: company.team
tasks:
- id: ecr
type: io.kestra.plugin.aws.ecr.GetAuthToken
accessKeyId: "{{ secret('AWS_ACCESS_KEY_ID') }}"
secretKeyId: "{{ secret('AWS_SECRET_ACCESS_KEY') }}"
region: eu-central-1
- id: py
type: io.kestra.plugin.scripts.python.Commands
taskRunner:
type: io.kestra.plugin.scripts.runner.docker.Docker
credentials:
username: AWS
password: "{{ outputs.ecr.token }}"
containerImage: 123456789.dkr.ecr.eu-central-1.amazonaws.com/data-infastructure:latest
commands:
- python --version
Run Python (or any command) inside a private container image stored in Amazon Elastic Container Registry (ECR), without manually managing short-lived registry credentials. This blueprint fetches a fresh ECR authorization token, uses it to authenticate the Docker task runner against your private ECR registry, pulls the specified image, and executes your Python commands inside it. It solves the recurring problem of ECR tokens expiring every 12 hours: instead of caching stale credentials or wiring up a custom login step, Kestra mints a valid token on every run.
How it works
- The
ecrtask (io.kestra.plugin.aws.ecr.GetAuthToken) calls Amazon ECR with your AWS access key and secret key in regioneu-central-1and returns a short-lived authorization token. - The
pytask (io.kestra.plugin.scripts.python.Commands) runs on the Docker task runner (io.kestra.plugin.scripts.runner.docker.Docker). Itscredentialsblock authenticates to ECR using usernameAWSand the password{{ outputs.ecr.token }}piped straight from the first task. - The runner pulls
containerImagefrom your private ECR registry and runs thecommandslist (here,python --version) inside that container.
What you get
- Always-valid ECR authentication, generated fresh on each execution.
- Your own private, dependency-baked image as the Python runtime, so there is no pip install step at run time.
- A clean separation between credential retrieval and code execution.
- Full execution logs, outputs, and retry history captured in Kestra.
Who it's for
- Data and ML engineers running Python jobs from internal container images.
- Platform teams standardizing on ECR for private image distribution.
- Anyone wiring private-registry workloads into a wider pipeline.
Why orchestrate this with Kestra
ECR has no scheduler or workflow engine of its own: it stores images and hands out tokens, nothing more. Kestra adds event and schedule triggers, automatic retries, end-to-end execution lineage, and a declarative YAML definition you can version control. The token-then-run handoff via {{ outputs.ecr.token }} is exactly the kind of step-to-step wiring ECR alone cannot express.
Prerequisites
- An AWS account with an ECR repository and a pushed image.
- IAM permissions for
ecr:GetAuthorizationTokenand pull access to the repository. - A Docker-capable task runner.
Secrets
AWS_ACCESS_KEY_IDAWS_SECRET_ACCESS_KEY
Quick start
- Add the
AWS_ACCESS_KEY_IDandAWS_SECRET_ACCESS_KEYsecrets to your namespace. - Set
regionto match your ECR registry. - Replace
containerImagewith your own ECR image URI. - Edit the
commandslist to run your script. - Execute the flow and check the logs.
How to extend
- Swap
python --versionfor a real script, or mount inputs and capture outputs. - Add a
Scheduleor event trigger to run the job on a cadence. - Chain downstream tasks that consume the Python output.
- Parameterize the image tag with an input to promote builds across environments.
Links
Orchestrate with Kestra
Orchestrate AWS with KestraShare this Blueprint
Create a Blueprint
Go to the developer platformMore Cloud Blueprints
More Infrastructure Blueprints
