Skip to main content
Banking OS 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. Construct GitHub URLs from the organization name and the track. The following table lists the applications-live URL for each track: Some pages use the generic name gc-applications-live because the GitHub organization and exact repository name differ for each installation. Substitute the URL for your installation from the preceding table.

The two tracks

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

Connector types and tracks

Each connector type belongs to one track. The track determines who builds the connector and who operates it after deployment. The following table shows how each connector type maps to a track: For more information about connector types, see Banking OS Connectivity.

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:
  • Banking OS 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.

Who does what

The Backbase platform team hosts and runs the infrastructure and runtime for every connector, whether it’s managed or custom. Operational support of a connector sits with whoever owns it: the Backbase implementation team for managed connectors, and you for custom connectors. The following table lists responsibilities for workloads in the DevHub track: You control everything you create in DevHub. Keep the following in mind when you work with subscription keys and delivery:
  • To use one subscription key for both Backbase-managed and custom connectors, ask the Backbase implementation team. Managed products live in the managed applications-live repository.
  • To deploy your own API and connector, see Deploy a custom API and connector.

Access enforcement

Repository names and prefixes don’t control access. Instead, GitHub team membership and Banking OS roles grant access per user in self-service.tfvars:
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 and Configure connectors.