Skip to main content
Coming in the first release. This page describes behaviour being built for the first Gliss release. Details may change before it ships.
This is the path the first Gliss release supports: you have an app with a gliss.yaml in a Git repository, and you release it from your machine. Steps that are still being built are listed at the end, under Coming later.
Building with an AI tool? Tell it: Read https://docs.glissando.dev/for-ai-agents.md, then build me a Gliss app that <your idea>. For AI agents takes it through these steps.

​
Before you start

  • Windows 10 or 11, macOS 13 or later, or Linux, on x64 or Arm. On Windows, WSL works if the repository sits on the WSL filesystem.
  • Git 2.30 or later.
  • Your company has installed Gliss. Your app exists already, or you create it below with gliss create.
  • For now, to release from your machine: Docker with buildx, and the AWS CLI with a profile that may only push to your cluster’s image registry. Ask your IT team for one; don’t use an administrator profile. Building without these is planned.
  • Optional: an AI tool that supports MCP, such as Claude Code, Claude Desktop, Cursor or Codex.
1

Install the gliss client

Install gliss for your user; it needs no admin rights. The script checks the release’s signature before installing.
The address will move to get.glissando.dev. To read the script before running it, see Install and update. gliss update keeps the client current. The console’s Create app page shows the same commands.
2

Sign in

Your browser opens on the Gliss console. Type the code shown in your terminal and approve. gliss whoami shows who you are signed in as.
3

Find or create your app

This lists the apps you can see, with their stages and health. Commands take the app’s name; there are no ids to look up. If you belong to several organizations, see App names.To start a new app:
Gliss makes the app’s repository in your company’s GitHub organization, from the Gliss template, with your own work branch gliss/u/<handle>, and builds a Preview of the starter app. To start from the template in a local folder instead, with the guidance for your AI, run gliss init <name>.
4

Release to your Preview

In the app’s folder, with your changes committed:
It builds the images, pushes them, asks Gliss to release them, and follows the release until it runs. If Gliss declines the release, it says why in plain language; fix gliss.yaml and run it again. The app runs in mock mode until its secrets are set.
5

Check it

gliss status shows each stage’s health and URL. gliss diagnose says what is wrong and whether it is the app’s problem or the platform’s.
6

Connect your AI

In Claude Code:
Your AI can then read status, diagnoses and logs. To let it release too, start the server with --allow-release; it then asks you before every release. See gliss mcp.
7

Share to Beta, then publish

When the Preview looks right, gliss release <app> --stage beta releases it to Beta for your testers. Live is published from the console; see Share and publish.

​
Coming later

These parts of the path are designed but not available yet:
  • Setting up a new app’s repository on your machine by itself, on your own branch, with Git access that needs no GitHub account; then each push to your branch builds your Preview.
  • Building in your app’s CI or in Gliss, so you need no Docker or cloud credentials on your machine.
  • gliss dev, to sync saved changes to your Preview in seconds.
  • Requesting secrets from the people who hold them, from your AI.
The full list of commands is in the CLI reference.