Skip to main content
The catalog is the menu you publish. Every gliss.yaml is checked against it before anything is built, and refusals name it with its revision, for example acme@3, so a builder’s AI knows which menu it was checked against.

​
The default catalog

A new cluster starts with the default catalog, gliss-default@1, unless you edit it when you register the cluster. It suits simple apps as they are:
  • a Postgres database, a Redis-compatible cache, up to three storage buckets, one web address, and sign-in for your organisation, a group, or (with your approval at Publish) the public;
  • Preview and Beta sleep after 30 idle minutes, and an idle Preview is deleted after 7 days;
  • publishing to Live needs the app owner’s approval, and yours for a public app;
  • apps may reach any public hostname except a short blocklist (see Outbound access), unless you turn on lockdown;
  • the first labels secrets, www, mail, admin, login, auth, sso and api are reserved, so no app takes them as its web address.

​
Lockdown

Lockdown is one switch for your whole organisation, on the Approvals page. It applies stricter defaults on top of every cluster’s catalog, without changing the catalog itself:
  • outbound internet is denied unless you approve domains in the catalog;
  • no app can be published to the public; sign-in is for your organisation or its groups.
A change applies to releases from then on. Apps already running keep their outbound internet and audience until their next release, which is checked against the new rules. Org admins and IT approvers can turn it on. Turning it off is deliberately harder:
  • only an IT approver who has held the role for at least 24 hours can do it (in an organisation of one person, that person);
  • you sign in again with your identity provider to confirm it;
  • every org admin and IT approver is emailed when it happens;
  • Gliss staff can never turn off your lockdown.
Every change is recorded on the same page. Each cluster’s page shows its catalog with lockdown applied.

​
Upgrading the default

The cluster keeps the catalog it was registered with. When a newer default appears, nothing changes on its own: compare it with yours in the console and publish the parts you want as your next revision.

​
What you decide

  • Capabilities: which of Postgres, Redis, buckets, hostnames, sign-in and healers are offered, in which sizes, and how many per app.
  • Audiences: whether apps may be public, or only for your organisation or its groups.
  • Secrets: how many per app, whether guest links are allowed, and how long a request link lasts (at most 72 hours).
  • Runtimes components may use.
  • Outbound access: which outside hostnames apps may call. See Outbound access.
  • Quotas for each stage, and how many components an app may have.
  • Preview and Beta lifecycle: when idle stages sleep, and when idle Previews are deleted.
  • Publish: how long Beta must stay healthy, and when IT must approve. See Approvals.
  • Levels: whether projects may use level 1, and which projects may use level 2.
Some values are fixed by Gliss and appear in the catalog so you can see them, for example that Live always requests every secret. Every field: catalog reference.