> ## 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.

# Install Gliss

> Installing Gliss into your company's AWS account from one CloudFormation form.

> [!NOTE]
>
> **Coming in the first release.** This page describes behaviour being built for the first Gliss release. Details may change before it ships.

Gliss installs into your AWS account from a single CloudFormation stack. You fill in one form:

| Field | What it is |
| - | - |
| Cluster name | 2 to 17 characters, unique in the account |
| Domain | The domain apps live under, and how its DNS is managed |
| Git organisation | The GitHub organisation where app repositories are created |
| Ingress exposure | Whether apps are reachable from the internet or only internally |
| Node size and count | The cluster's starting capacity |
| Join token | A single-use token from the Gliss console that connects the cluster to Gliss |

The stack builds the cluster and installs the Gliss agent. The agent connects out to Gliss over port 443; your cluster needs no inbound access from Gliss. When it finishes, a conformance check reports on the install.

## After the install

* **The catalog.** The cluster uses the catalog you chose when you registered it, the [default catalog](https://docs.glissando.dev/administer/catalog.md#the-default-catalog) unless you edited it.
* **Apps find the cluster by themselves.** When your organisation has one cluster, every new app is assigned to it, and apps registered before the cluster are assigned when it is registered. With several clusters, an organisation admin chooses one on the app's page. If an admin removes an app from its cluster, Gliss never assigns it again on its own.

## Release keys

Gliss signs every release with one key per Gliss environment. The verified launch script from the Gliss console prints the fingerprint of the key it checks the release with (`Release key SHA-256 fingerprint: …`) before it uses anything. Compare it with the one below for your environment. If they differ, don't run the rest: stop and contact Gliss.

| Environment | Release key SHA-256 fingerprint |
| - | - |
| Preprod | `493ba36e105a82e6d02c8b8b45d0e1501dab7feebee6cfdade9c54f716e49121` |
| Production | Not published yet |

The line the script prints comes from the same console as the script, so check the key yourself before you run it. Copy the value of `release_key='…'` near the top of the script and run `printf %s '<that value>' | base64 -d | sha256sum`. The result must be the fingerprint above. (From a key file: `openssl pkey -pubin -in <key file> -outform DER | sha256sum`.)

Every field, with its rules and CloudFormation parameter: [Install parameters](https://docs.glissando.dev/reference/install-parameters.md). The full requirements and permission list will be published here.


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