> ## Documentation Index
> Fetch the complete documentation index at: https://docs.glissando.dev/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> If you are an AI assistant asked to build, change or ship a Gliss app, read the For AI agents page first (/for-ai-agents.md on this site) and follow its steps.
> Inside an app's folder, the app's own AGENTS.md is the authority; `gliss guide` prints it. Never ask the user for a secret's value.

# How Gliss works

> What happens between your AI writing an app and the app running in your company's cloud.

Gliss has three parts, and your app's code passes through none of them on its way to your cloud.

| Part | Where it runs | What it does |
| - | - | - |
| **Gliss cloud** | Hosted by the Gliss team | Sign-in, the catalog, release signing, the console and the app registry. It holds no cloud credentials, no secret values and no logs. |
| **Your cluster** | Your company's AWS account | Runs your apps, their databases and storage. A small Gliss agent applies releases there. |
| **Your machine** | Your laptop | Your AI tool, the `gliss` client, and a copy of the app's repository. |

## From idea to live app

**1. You ask your AI for an app**

You describe what you need. Your AI writes the code and a short `gliss.yaml` that asks for what the app needs, such as a database or sign-in, from the [catalog](https://docs.glissando.dev/get-started/concepts.md#catalog) your IT team publishes.

**2. Gliss creates the repository**

You sign in with your company account. That is the only account you need: no GitHub seat, no AWS access, no Docker. Gliss creates the repository, and your AI works on your own branch.

**3. Your company's CI builds it**

Each push builds the app in your company's CI. CI holds no stored secrets: it proves who it is with short-lived tokens. Unchanged parts are not rebuilt or retested, which keeps every round fast.

**4. Gliss checks the request and signs a release**

Gliss checks `gliss.yaml` against the catalog. Anything off the menu is [refused](https://docs.glissando.dev/reference/refusals.md) with a message your AI can act on. Otherwise Gliss signs a release: a statement of exactly what may run, where.

**5. Your cluster applies it**

The Gliss agent in your cluster receives the signed release over a connection it opened itself, verifies the signature and applies it. Gliss cannot log in to your cluster. It can only sign releases that your cluster checks.

**6. Preview, Beta, Live**

You try the app in a private [Preview](https://docs.glissando.dev/build/stages.md), share it as a Beta, and press [Publish](https://docs.glissando.dev/build/share-and-publish.md) when it is ready. Live runs exactly the build that passed Beta.

## When something goes wrong

Your AI does not need you to copy error messages. After each push it receives a [diagnosis](https://docs.glissando.dev/build/diagnostics.md): what failed, whether it is the app's problem or the platform's, and what to do next. If it is the app's problem, your AI fixes it and pushes again.

## What Gliss can and cannot do in your account

Gliss **can** sign releases, which your cluster applies only if they verify and your IT team's policy allows them. It **cannot** log in to your AWS account or cluster, read your secret values, or run arbitrary commands. If Gliss cloud is unreachable, your apps keep running. See the [security model](https://docs.glissando.dev/administer/security-model.md) for details.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.