frostmoln_container_registry (Data Source)

Reads this tenant's container registry WITHOUT creating one.

Use this when the registry is managed elsewhere — the portal, fm registry enable, or another Terraform state — and this configuration only needs its endpoint and namespace. The frostmoln_container_registry RESOURCE would opt the tenant in and start its billable storage; this never writes anything.

For a tenant that has not opted in, enabled is false and namespace is null. That is the answer, not an error — check enabled before building an image reference.

Example Usage

# Read the tenant's registry WITHOUT creating one.
#
# The frostmoln_container_registry RESOURCE is the opt-in: against a tenant that
# has not opted in it creates the registry and starts its billable storage. Use
# this data source when the registry is managed elsewhere (the portal,
# `fm registry enable`, or another Terraform state) and you only need to know
# where to push.
data "frostmoln_container_registry" "current" {}

# `enabled` is false rather than an error for a tenant that has not opted in, so
# check it before building an image reference.
output "image_prefix" {
  value = data.frostmoln_container_registry.current.enabled ? format(
    "%s/%s",
    data.frostmoln_container_registry.current.endpoint,
    data.frostmoln_container_registry.current.namespace,
  ) : null
}

Schema

Read-Only

• enabled (Boolean) Whether this tenant has opted in.
• endpoint (String) The host to docker login to. Present whether or not the registry is enabled.
• id (String) The tenant id. A tenant has exactly one registry and its id is the tenant's.
• namespace (String) The tenant's namespace at that endpoint — the first path segment of every image reference. Null while the registry is not enabled, because advertising a pull path that 404s reads as a working registry.
• storage_limit_bytes (Number) The SUM of the hard storage caps enforced across every namespace this tenant owns — the repository namespace and every pull-through cache. Read this before you render it: the registry caps PER NAMESPACE and there is no aggregate cap anywhere, so this is total headroom and not a single enforced threshold. A tenant holding a repository namespace and two caches, each capped at 10 GiB, reports 30 GiB here and can still be refused with 9 GiB of it unused — frostmoln_container_registry_cache.used_bytes is what says which namespace is close. The value also MOVES as caches are created and destroyed. A push that would cross ITS OWN namespace's cap is refused with a 403 whose message states the cap, the usage and the size that would not fit — as prose, and only once the push has failed. Null when any one namespace's cap was not usable, which is several causes with the same result: a namespace reports no cap at all; a namespace reports a hard cap of exactly 0, which refuses every push and is the one null that is worse than it looks, not better; or the quota read itself failed. Being disabled is not a reason here — a registry that stops being enabled is removed from state rather than nulled. The platform re-checks and resets caps on a later sweep, which repairs the first two; it never repairs a failed read, so that one can persist for as long as the outage lasts and the value can go null and back between refreshes with no configuration change. A cap of 0 and an unlimited -1 both arrive as null rather than as a value, so null — not a zero or negative number — is the only state to check for. Null means the limit was not reported, and never that it is unlimited.
• storage_used_bytes (Number) Storage stored ACROSS EVERY NAMESPACE this tenant owns — the repository namespace and every pull-through cache, summed. This is the figure the tenant is metered on: the platform's usage meter sums exactly this set, so this attribute and the invoice describe the same set of namespaces. Not, strictly, the same bytes at the same instant: the meter aborts a whole window on any unreadable quota, so a window can be lost while this reports normally. OBSERVATIONAL: it changes with every push and with every cached pull, so expect it to differ on each refresh — a cache fills on PULL, so it moves without anyone pushing. It counts deduplicated bytes per namespace and then adds the namespaces up, so the same layer held in two namespaces is counted twice, and that is also how it is billed. It does not equal the sum of your local image sizes. It is the registry's accounting rather than an audited ledger, so treat it as what you are metered on rather than as an invoice line — billing keeps its own copy of the same reading.