Skip to main content
The catalog is the menu IT publishes for one Gliss organisation or cluster: which capabilities, sizes and runtimes apps may ask for, how many of each, who an app may be shown to, how Preview and Beta behave when idle, and what Publish to Live requires. Every gliss.yaml is checked against it before anything is built, and refusals name it as <metadata.name>@<metadata.revision>, for example acme@3. Charts, chart versions and the Postgres major version are not in the catalog: they are pinned by the platform release, which IT approves separately. Some values are fixed and appear here as constants so that IT can see them; changing them needs a new contract version, not an edit. Email (SES), connections to SaaS accounts and managed Postgres (RDS) are not offered in v1.

Sections

metadata

string
required
Short name of the catalog, usually the customer, for example acme. Refusals cite it.
integer
required
Increases by one on every published edit. Refusals cite it (acme@3), so a builder’s LLM can tell which menu it was checked against. The control plane rejects a document whose revision is not greater than the one it holds.At least 1.
string
At most 500 characters.

capabilities

Every capability type gliss.yaml v1 can name, and whether this catalog offers it. A type that is not offered is refused with the list of offered ones. Each entry carries the catalog entry’s own version (postgres@1); a platform release that deprecates a version raises a capability-version-eol finding.
object
required
object
required
An in-cluster Redis cache per stage. Not durable.
object
required
object
required
object
required
object
required

secrets

Limits on declared secrets and secret requests.
integer
required
From 0 to 100.
Whether a request link may be forwarded to a guest outside the organisation. Guests may only ever set credential secrets; endpoint secrets always need a signed-in member.
How long a single-use request link works. sets 72 hours; IT may shorten it, not lengthen it.From 1 to 72.

config

Limits on gliss.yaml config values, per stage after overrides are applied.
integer
required
How many config values one stage of an app may have.From 0 to 100.
integer
required
Total size of one stage’s config, counting names and values.From 1024 to 65536.

egress

Rules for the hostnames apps list under gliss.yaml egress. The platform enforces the result with network policy.
integer
required
From 0 to 50.
boolean
required
Whether an app may list *.example.com.
boolean
required
Whether an app may list IP addresses or ranges.
array | null
required
null: any public hostname not blocked is approved. A list: only these hostnames, or hostnames under a listed *.domain, are approved.
string[]
required
Hostnames, or *.domain patterns, no app may list.

runtimes

Runtimes a component may name. A runtime with a dev variant reloads in Preview through Git-backed sync; one without rebuilds on each change. Each entry in runtimes has:
string
required
any
required

quotas

integer
required
From 1 to 20.
integer
Optional cap on live Preview namespaces per builder, across apps.At least 1.
object
required
The ResourceQuota each stage namespace gets.

stages

Lifecycle defaults per stage. Scale-to-zero for Preview and Beta is mandatory and cannot be switched off, only tuned.
object
required
object
required
object
required

publish

What Publish (Beta to Live) requires. The gates marked const are fixed. The approval policy is the organisation default; IT can tighten or loosen it per app in the console.
object
required
object
required

levels

Which levels projects may use. Level 0 (gliss.yaml only) is always on.
object
required
Level 1: gliss.yaml plus garden.yml using Gliss action types. Validated against this same catalog.
object
required
Level 2: the team’s own charts, checked against IT’s policy instead of the catalog. Post-MVP. Off by default, and enabled per project by IT or a system owner.

maintenance

Which maintenance tier the customer has. Set from the subscription; IT cannot raise it by editing the catalog.
self-maintained | managed
required
self-maintained: IT’s LLM or people act on findings. managed: Gliss maintenance bots do. The healer level auto needs managed.

Example

The example catalog acme@3, which every gliss.yaml example in these docs is checked against.
example.catalog.json