Writing gliss.yaml

apiVersion: gliss.dev/v1
app: expense-tracker
owner: dana@customer.com
components:
  web: { build: ./frontend, port: 8080, runtime: vite }
  api: { build: ./backend, port: 8000, runtime: python, migrate: "alembic upgrade head" }
capabilities:
  database: { type: postgres, size: small }
  auth:     { type: sso, audience: org }
  hostname: { type: hostname, name: expenses }
  secrets:  { SALESFORCE_TOKEN: credential }
config:
  LOG_LEVEL: info
egress: [login.salesforce.com]

​

The parts

• app and owner: the app’s name, which becomes part of its addresses, and the owner’s work email.
• components: each one is a folder with a Dockerfile that becomes a container. Give it a port if it serves web traffic.
• capabilities: what the app needs from the platform. Each key is a name your AI chooses, and type picks the catalog entry. See the capability pages under Capabilities.
• config: plain, non-secret settings the app reads as environment variables.
• egress: the outside services the app may call. Everything else is blocked.
• stages: optional per-stage overrides. See Preview, Beta and Live.

​

What never goes in gliss.yaml

• Secret values. Declare the name and type under capabilities.secrets; a person sets the value through a secret request.
• Scripts, kubectl, Helm charts or Kubernetes objects. Charts belong to the catalog. Fields such as env, helm and manifests are refused.
• Database passwords or AWS keys. The platform creates them and hands them to the app.

​

When Gliss says no

capabilities.cache: type 'redis' is not offered in catalog acme@3; offered: postgres, bucket, hostname, sso