ECR
What does zop.dev create for 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.
| Field | Value |
|---|---|
| Cloud | aws |
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
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.