Set defaults at creation, not later. In Amazon ECR, repository creation templates apply tag immutability, encryption, permissions, a lifecycle policy and resource tags when a repository is created on push, by pull through cache or by replication. Without a template, ECR uses defaults with no lifecycle policy.
The problem with defaults
Hygiene fails at the edges: the repository someone created in a hurry, the one that appeared automatically on first push. ECR documents that when no template matches a pull through cache rule or replicated repository, new repositories get default settings, including tag immutability off, AES-256 encryption and no repository or lifecycle policies. For create on push, ECR will not create a repository with default settings if no matching template exists.
That last detail is a useful guard: a push to an unknown name fails instead of creating an unmanaged repository.
What a template can set
Per the ECR documentation, a template defines a prefix, what it applies to (pull through cache, create on push or replication), image tag mutability, encryption, repository permissions, a lifecycle policy and resource tags. Settings apply only at creation and do not change existing repositories.
The prefix drives which template wins. A longer matching prefix applies over a shorter one, and ROOT can serve as a catch all.
A baseline worth applying
| Setting | Why |
|---|---|
| Immutable tags for release prefixes | A release tag cannot be silently replaced |
| A lifecycle policy per prefix | Cleanup exists from the first push |
| Owner resource tag | Someone is accountable for the repository |
| Least privilege permissions | Push rights stay narrow |
| Mutable tags for pull through cache prefixes | ECR recommends mutable for these so cached images can update |
Note the last row. A one size rule can break caching, so templates by prefix are better than one setting everywhere.
Other registries
Not every registry has creation templates. Where yours does not, achieve the same with a small provisioning script or infrastructure as code module that creates repositories, and a scheduled check that flags repositories lacking the baseline. Harbor works at the project level, so project settings and retention rules at the project give a similar effect.
Verify drift
Existing repositories keep their old settings. Run a periodic check that lists repositories and flags missing immutability, missing lifecycle policy or missing owner. Our quarterly registry hygiene review covers the cadence, and how to make Amazon ECR image tags immutable covers the immutability step.
Start with one prefix
You do not need a full template set on day one. Pick the prefix that holds your production releases, apply immutability, a lifecycle policy and an owner tag there, and watch it for a month. Then extend the same pattern to the next prefix. A small, working baseline beats a large one nobody trusts, and it gives you a real example to show other teams when they ask why pushes to unknown names now fail.
Quick check
Do templates fix repositories that already exist?
No. ECR states template settings apply only at creation, so existing repositories need a separate change.
Should all repositories be immutable?
No. ECR recommends mutable for repositories used by pull through cache. Set immutability by prefix.
Sources
Last reviewed: 19 October 2026.
