# ECR

> ZopDay creates 1 ECR repository for every EKS cluster, named after the cluster. Tag mutability, scan on push, encryption and lifecycle rules stay at the AWS defaults. Cluster nodes pull images through a read-only ECR policy on the node role. Deleting the cluster job also deletes the repository and every image in it.

Source: https://zop.dev/integrations/provision/aws/ecr
Updated: 2026-08-19

---

Amazon ECR stores the container images your workloads pull. You cannot create ECR on its own from
the Provision screen. Instead, ZopDay creates one repository as part of every EKS cluster job, named
after the cluster.

## How does ZopDay create one ECR repository per cluster

The cluster job creates the repository after the cluster is ready. If you supplied a domain, this
happens after the DNS zone is set up. It happens before the cluster is registered as a deployment
space. The repository takes the cluster's name and gets two tags: `provisioner=zopdev`, and
`cluster-name` set to the cluster's name. A cluster called shop gets a repository called `shop`
tagged `cluster-name=shop`.

If creating the repository fails, the job marks the step as skipped and carries on without a
registry. This happens, for example, when a repository with that name already exists or the
connected account lacks ECR permissions. Nothing else in the cluster job depends on the repository.

## What is left at the AWS defaults

ZopDay sets only the name and tags. Everything else is whatever ECR applies by default:

- **Image tag mutability**: not set, so AWS uses its default, `MUTABLE`.
- **Scan on push**: not set, so AWS leaves it off.
- **Encryption**: not set, so AWS applies its default encryption.
- **Lifecycle policy**: none.
- **Repository policy**: none.

If you want immutable tags, scanning, a customer-managed KMS key or image expiry, set them on the
repository in the ECR console or with your own tooling. ZopDay does not change them later.

## How images are pulled and pushed

ZopDay creates an EKS node role named after the cluster (a cluster called shop gets
`shop-eks-node-role`). That role has the AWS managed policy `AmazonEC2ContainerRegistryReadOnly`
attached. Pods on the cluster's nodes can therefore pull from ECR in the account without an image
pull secret.

When ZopDay needs to sign in to a private ECR registry, it uses the connected cloud account's AWS
credentials to request a short-lived token with `ecr:GetAuthorizationToken`. It builds a Docker
login config from that token. No long-lived registry credential is created or stored.

## Storage keeps growing unless you add a rule

No lifecycle policy is set, so every image pushed to the repository is kept until someone deletes
it. That includes untagged layers left behind by re-tagging. ECR bills for the storage the
repository holds. A CI pipeline that pushes on every commit therefore grows the bill with every
build. The usual fix is a lifecycle policy that expires untagged images and keeps a fixed number of
tagged ones. Adding it is up to you.

## What happens to ECR images when the cluster is deleted

Deleting the cluster job deletes the repository first, and forces the delete. Every image in it is
removed along with the repository. Copy any image you want to keep to another registry before you
delete the cluster.