# ECR

> zop.dev provisions ECR repositories for container images, and deployments authenticate to them automatically from the cloud account already connected. No separate registry credential is created or stored. Image storage is billed per GB and accumulates unless a lifecycle policy removes old tags.

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

---

Amazon ECR stores the container images your deployments pull. zop.dev creates one repository per service so image ownership maps cleanly to the service catalog.

## One ECR repository per service

One aws_ecr_repository per service.

## immutable_image_tags defaults to true

```text
immutable_image_tags default true.
```

## image_tag_mutability and the deploy picker

The provisioner API exposes image_tag_mutability on the ecr resource type; backend-api also lists ECR images for deploy pickers.

## No credential to manage

This is the practical difference between ECR and an external registry. Because ECR lives in the
same account zop.dev already connected, registry authentication is minted on demand rather than
stored. There is no token to rotate and no secret to leak.

Teams routinely add a registry credential for ECR anyway. It is unnecessary work, and it creates
a credential that then needs managing.

## Lifecycle policy is the setting that matters

ECR bills per GB of image storage per month. Without a lifecycle policy, every image ever pushed
is retained indefinitely, including every intermediate build, every failed deploy, and every tag
from a service that no longer exists.

A CI pipeline pushing on each commit produces a repository that grows linearly and forever. The
storage cost is small per image and unbounded in aggregate, which is exactly the shape that goes
unnoticed for a year.

A policy expiring untagged images after a few days, and keeping the last N tagged images, covers
almost every case.

## Scan on push

ECR can scan images for known vulnerabilities as they are pushed. Basic scanning is free and
worth enabling by default. Basic scanning costs nothing and surfaces a critical CVE in a base
image at push time rather than in a quarterly audit.

Enhanced scanning is continuous and priced per image, which is worth it for images running in
production and rarely worth it for every development build.

## Immutable tags

Tag immutability prevents overwriting an existing tag. It is off by default, and turning it on
means `latest` behaves predictably and a deployed digest cannot be silently replaced by a
different image under the same tag. That silent replacement is the failure mode that makes
"it works in staging" impossible to debug.