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

# GitHub organization and repository structure

> How Grand Central organizes repositories per installation, and the difference between the managed and DevHub tracks.

Grand Central provisions each installation with a dedicated GitHub organization named `bb-ecos-{installation}`, such as `bb-ecos-ecos`. Within that organization, the platform repositories are organized into one or two parallel **tracks**. Understanding the tracks explains why you may see two sets of similarly named repositories in the same organization.

## The two tracks

| Track       | Repositories                                                                              | Operated by                                  | Intended audience                                               |
| ----------- | ----------------------------------------------------------------------------------------- | -------------------------------------------- | --------------------------------------------------------------- |
| **Managed** | `gc-{installation}-applications-live`<br />`gc-{installation}-self-service`               | Backbase Professional Services and GC DevOps | Customers who acquire a managed, productized connector          |
| **DevHub**  | `gc-devhub-{installation}-applications-live`<br />`gc-devhub-{installation}-self-service` | Customer developers                          | Customers who acquire a custom connector build, known as a slot |

<Note>
  An installation has the track that matches what the customer acquires. The managed track is present for managed, productized connectors, and the DevHub track is present for custom connector builds, also known as slots. An installation can have one track or both.
</Note>

The `gc-devhub-` prefix denotes the **DevHub** track, which customer developers operate. Repositories with the `gc-` prefix alone are the **managed** track that Backbase operates.

## What each repository contains

Both tracks use the same two repository types. The difference is who operates them, not what they do.

### `*-applications-live`

This repository holds the runtime and deployment configuration for the installation, which ArgoCD controllers consume to manage cluster state. The exact runtimes and namespaces vary per installation, depending on how the customer sets them up. Common runtimes include `dev`, `stg`, `test`, and `uat`. Each runtime contains:

* **Grand Central app**: deploys the connectors for that runtime.
* **Secrets app**: SOPS-encrypted Kubernetes Secrets and ConfigMaps stored in Git.
* **Istio app**: networking configuration.

The repository references built connector images but doesn't contain connector source code. You deploy by opening a pull request against `main`.

### `*-self-service`

The GitOps control plane for the installation. The desired state lives in the `self-service.tfvars` file at the root of the repository, and you apply changes by opening a pull request against `main`. Through this repository you:

* Provision user access to the organization and runtimes through the `team_members` section.
* Manage the `self-service`, `development`, and `applications-live` GitHub teams.
* Manage additional infrastructure and GitHub secrets.
* Override default `applications-live` runtime reviewers.

## Access enforcement

Repository names and prefixes don't control access. Instead, **GitHub team membership and Grand Central roles** grant access per user in `self-service.tfvars`:

```hcl theme={"system"}
team_members = {
  "developer@example.com" = {
    grandcentral = {
      roles = ["dev-rw", "dev-ro", "dev-apim-rw"]
    }
    github = {
      github_teams = ["self-service", "development", "applications-live"]
    }
  }
}
```

The `gc-` versus `gc-devhub-` prefix is an **ownership and operating-model convention, not a security boundary**. A user can reach whichever repositories their team grants allow. To verify who can access a given track, inspect the `team_members` grants in that track's `self-service.tfvars`.

## Where connector code lives

Neither the managed nor the DevHub `applications-live` repository contains connector source code. Connector implementations live in **separate connector repositories** that you create from a template through `self-service.tfvars`. Each connector repository holds the Apache Camel routes, the Maven project, and the connector configuration.

For managed connectors, Backbase owns the connector repository and the published artifact, and the `applications-live` repository only references the built image. For more information, see [Get started](/platform/developer-guides/get-started/overview) and [Configure connectors](/connectors/configure/connector-configuration).