# Lifecycle

Users can add additional repositories in a project in just a few clicks using the Console or using the RCTL CLI with a declarative, version-controlled spec for high levels of automation.

---

## Create Repository

- Login to the Console and navigate to your Project
- Click on Integrations and Select Repositories
- Click on New Repository
- Provide a "friendly name" and select "type" (Git or Helm)

---

## Configure Repository

Once a repository is created, it needs to be configured before it can be used.

- Provide the Endpoint URL: Two (2) types of Helm chart repositories are allowed  
  1. **Traditional Helm Repository (`https://`)** – A standard HTTP(S)-based repository that hosts Helm charts with an `index.yaml` file.  
     - **Example**: `https://charts.bitnami.com/bitnami`  
  2. **OCI-Based Helm Repository (`oci://`)**– A container registry-based repository that stores Helm charts in an OCI-compliant format, similar to container images.  
     - **Example**: `oci://c8n.io/demouser1/nginx`  
     
       > **Note**: In this example, `c8n.io` is a domain associated with a container registry service that allows users to store and manage Helm charts in an OCI-compliant format. The URL specifies a Helm chart (`nginx`) stored under the `demouser1` namespace in the `c8n.io` registry.

Both repository types can be used in **[workloads](https://docs.rafay.co/workloads/helm_charts/)** and **[catalogs](https://docs.rafay.co/catalog/manage_catalog/)**. Users can select the repository created with these Helm charts (of any type), specify the chart name, and define the version to deploy applications in workloads. In catalogs, users can create a catalog by linking a Helm repository and selecting charts for reuse across multiple deployments.

### Reachability

The **Reachability** setting determines how the repository can be accessed:

- **Internet**: Select this option if the repository is publicly accessible over the internet

- **Private Network**: Choose this option if the repository is within a private network and requires internal connectivity. For private repositories that are operating in private networks, behind a firewall, the use of an [agent](https://docs.rafay.co/integrations/repositories/agents/) is required.

**Note**
- Agents are listed in the drop-down only after they are created in the platform.
- If no agent is specified for an internet-accessible endpoint, the controller's hosted agents are used (not recommended for production). For production environments, configure dedicated agents while considering factors such as registry rate limits.

### CA Certificate

- Optionally, if using a private CA, copy/paste the CA certificate of the repository endpoint

### Credentials

Access credentials need to be provided so that the repository can be securely accessed by the Controller.

**UserPass Credential**
If the organization requires the use of **Username** and **Password/Token**,  
- Select "UserPassCredential" for Type  
- Enter a valid "Username" and "Password/Token"  
- Click "Save"

**SSH Private Key**
If the organization requires the use of a **SSH key** for access,  
- Select "SSHCredential" for Type  
- Copy/Paste the "sshPrivateKey" in PEM format  
- Click "Save"

**GitHub App Credential**
If the organization uses GitHub App-based authentication for secure repository access, provide the App ID, Installation ID, and Private Key generated from the GitHub App configuration.  
- Select "GitHubAppCredential" for Type  
- Enter a valid "App ID" and "Installation ID"  
- Copy/Paste the "Private Key" in PEM format  
- Click "Save"

> **Note**: The platform uses the App ID, Installation ID, and Private Key to generate short-lived tokens for secure GitHub transactions.

---

## Share Repositories

The existing Repositories can be shared with All/Specific/None projects. This helps to use the configured repo to infuse to the new pipeline if required or change the required resources

Make the required selection to share the agent and click **Save**

> **Note:** Users cannot edit/share/delete the repositories inherited from other projects

---

## Validate Access

Once a repository has been configured, it is good hygiene to validate access to verify that there is no accidental misconfiguration.

- Navigate to Integrations -> Repositories
- Click on Validate for your repository

The Controller will use the configured information to test access to the repository and report back. An illustrative example for successful validation is shown below.

---

## View/Update Repository

Existing repositories can be viewed and updated anytime.

- Navigate to Integrations -> Repositories
- Click on the repository you are interested in to view configuration details.
- If necessary update details and Save.

---

## Delete Repository

Existing repositories can be removed anytime. Note that this is a destruction action and cannot be undone.

- Navigate to Integrations -> Repositories
- Click on Delete, Confirm Yes when prompted

---