# Connecting repositories

A repository connects through the Switchboard GitHub App, with a **kind**
that decides how Switchboard treats it:

| Kind | What it is | Example |
|---|---|---|
| `app` | one installable product | `WilldanGroup/cortex` |
| `composition` | a StackSet of many components deployed as one | `lime-energy/direct-install` |
| `component` | a nested stack that ships inside a composition | `lime-energy/closer` |
| `config-as-code` | a repo whose releases are config bundles | `lime-energy/conf-allegro` |

Registration writes the repo's desired state — its archetype, the
environments it may deploy to — and the repo keeps its own CI. Build
stays in the repository: the shared publish workflows (one per
language/framework) run tests, package the artifact into the org devops
buckets, and cut the semantic-release version. Every publish lands a
**build** row in Switchboard and advances a **channel** head.

A connected repo feeds channels and deploys whether or not the app is
ever listed in the portal — the deployment machinery stands without the
marketplace.

Registration, builds and channels live on the GraphQL API the console
uses; the REST [API reference](/api) covers only releases and manifest
validation.