Skip to content

Manage the registry

Four provider objects cover the registry:

Object Kind What it manages
kupe_registry Resource The tenant’s registry: its storage limit and deletion protection
kupe_registry_binding Resource A cluster connection: whole-cluster pull, and optional push namespaces
kupe_registry_token Resource An access token for CI and other automation
kupe_registry Data source Reads the tenant’s registry

A tenant has one registry, always named registry, so none of these takes a name you choose. The resource pages, kupe_registry, kupe_registry_binding and kupe_registry_token, list every argument and attribute.

A registry, two connections and a CI token

Section titled “A registry, two connections and a CI token”
resource "kupe_registry" "this" {
storage_limit = "20Gi"
}
resource "kupe_registry_binding" "prod" {
registry = kupe_registry.this.name
cluster = kupe_cluster.prod.name
}
resource "kupe_registry_binding" "build" {
registry = kupe_registry.this.name
cluster = kupe_cluster.build.name
push_namespaces = ["ci"]
}
resource "kupe_registry_token" "ci" {
registry = kupe_registry.this.name
display_name = "github-actions"
access = "push"
expires_in_days = 30
}
output "registry_endpoint" {
value = kupe_registry.this.endpoint
}
output "ci_registry_username" {
value = kupe_registry_token.ci.username
}

Referencing kupe_registry.this.name orders each connection and token after the registry. Create and update wait until the registry is Running and each connection is Ready, and a token create waits until the platform has issued the token.

storage_limit takes Mi, Gi or Ti and changes in place. Leave it out to use your plan’s cap; storage_limit_bytes shows the limit in force, -1 for unlimited. A value above your plan’s cap is refused at apply. See Limits.

push_namespaces changes in place, up to 10 per connection and 20 across the registry’s connections. A namespace you remove loses its push Secret, and the push credential is replaced, so build jobs in the remaining push namespaces must restart to read the new Secret. Pulls keep working throughout. Changing cluster, registry or secret_name replaces the connection: it is deleted and created again, and its pull and push credentials are issued anew.

Pods that were running before the connection was made pick up the pull credential only when they are recreated. See Connect a cluster.

A token never changes: changing any argument replaces it with a new token and a new secret. It stops working when it expires, when it is revoked, and when the member who created it leaves the tenant (or, for a push token, stops being an admin). Once the platform has removed an expired token, the next plan creates it again. To renew one early, run terraform apply -replace=kupe_registry_token.ci.

The token’s secret is stored in Terraform state in plain text. Marking it sensitive hides it from plan and apply output only. Keep state in an encrypted backend with restricted access, or create the token with kupe registry token create and keep its secret in your CI system’s secret store instead. See Access tokens and CI.

Deleting the registry deletes every image in it, and they cannot be restored. While deletion_protection is true, the default, the platform refuses the delete and the registry stays in state. To delete it:

  1. Set deletion_protection = false on kupe_registry and run terraform apply.
  2. Run terraform destroy, or remove the resource and apply.

Add lifecycle { prevent_destroy = true } to stop Terraform planning the destroy at all.

data "kupe_registry" "this" {}
output "registry_storage_used_bytes" {
value = data.kupe_registry.this.storage_used_bytes
}

The data source fails when the tenant has no registry. kupe_plan also reports registry_max_storage and registry_included_storage for each plan.

Terminal window
terraform import kupe_registry.this registry
terraform import kupe_registry_binding.prod registry/prod
terraform import kupe_registry_token.ci registry/rt-0a1b2c3d4e5f6a7b

An imported token has no secret: it is returned only when the token is created.