Artifact Registry
What does zop.dev create for Artifact Registry?
zop.dev creates 1 Artifact Registry repository per registries[] entry, grants the IAM members, and enables the required APIs; namespaces bind artifact_users for pull and push. Storage bills per GB and grows with every push. The artifact-policy resource type exists to set cleanup policies before that curve compounds.
| Field | Value |
|---|---|
| Cloud | gcp |
Artifact Registry stores container images for GCP deployments. zop.dev creates repositories with access already granted to the identities that need to pull and push.
Repositories built per registries[] entry
Repositories per registries[] entry, IAM members, and required API enablement.
Registry inputs: entries, tags, users
registries[] list; immutable_image_tags flag; artifact_users granted through namespace IAM bindings.The provisioner adds an artifact-policy type
The provisioner API adds an artifact-policy resource type for registry cleanup policies.
Access is IAM, not passwords
Nothing here mints a registry password. Repositories are created per registries[] entry with
IAM members granted at provisioning, and namespaces extend access to artifact_users through
IAM bindings. Pull and push rights are therefore properties of Google identities, revocable
and auditable like any other grant. The contrast with the Azure path (per-namespace service
principals with expiring passwords) is worth knowing on a multi-cloud team: on GCP there is no
registry credential to rotate, and “who can pull” is answered by an IAM policy read.
Cleanup is a resource, not a chore
Image storage bills per GB per month, and a CI pipeline pushing on every commit grows a
repository forever by default: every intermediate build and every abandoned branch’s images,
retained indefinitely. The artifact-policy resource type is the counterweight: cleanup
policies (expire untagged images, keep the last N versions) expressed as managed configuration
rather than a script someone runs. Setting one at repository creation costs a minute; setting
one two years in requires archaeology about which old images are still deployed somewhere.
Tag immutability changes failure modes
The immutable_image_tags flag decides whether a tag, once pushed, can be silently replaced.
Mutable tags allow the convenient pattern (repush latest, redeploy) and its failure mode:
the same tag meaning different bytes on different nodes, which is undebuggable by design.
Immutable tags force new tags for new builds, making every deployment reference exact and
reproducible. For repositories feeding production deploys, immutability plus a cleanup policy
is the configuration that ages well.
Enablement rides along
Repository creation also enables the required Google APIs on the project, so a fresh project does not fail on the first push. One ordering dependency between bootstrap and first deploy disappears.