Edit

Repositories

A Repository (or “Repo”) is a workspace-level container that groups together one or more resources under a single API interface compatible with different APIs and SDKs.

From a client’s perspective, a Repo behaves like one logical endpoint:

  • you attach multiple resources (potentially multiple buckets and AI LLMs across providers),

  • you choose which cloud API endpoint type you want to expose (S3/GCS/Azure Blob for storage or OpenAI for AI LLMs),

  • you generate one or more API key/secret pairs for that Repo,

  • each key grants access—using the chosen API type—to all the compatible resources attached to that Repo, subject to policies and permissions. If you created an API key for AI LLMs, it will be only useable with AI LLM resources attached to the Repo.

Over time, Repos also become the place where you attach other resources (AI Machine Learning, SQL, Virtual Machine, etc.) and manage keys and policies around that bundle. For now, this section focuses on the Resources + Repo API Key behavior:

Properties

Each Repo card exposes the following properties:

Name

A human-readable label for the repository. Example: prod-eu-analytics, backup-multicloud-repo.

To avoid collisions and keep the Repo’s virtual namespace coherent, the following rules apply:

  • S3 & GCS

    • Bucket names within the same Repo must be unique across providers.

    • You cannot mix an S3 bucket named mybucket with a GCS bucket also named mybucket in the same Repo.

  • Azure Blob

    • Azure storage account names must not collide with any S3/GCS bucket names in the same Repo.

    • You cannot combine:

      • an S3 or GCS bucket called mystorage

      • with an Azure container under a storage account also called mystorage in the same Repo.

    • You may include multiple containers from the same Azure storage account within a single Repo.

Resources

You can select resources you want to add in the repository. You can also add more later from the settings of the repository. Once attached, these resources become accessible via the Repo’s chosen API interface, instead of directly via their cloud-specific endpoints. It becomes your unique endpoint for multiple cloud-specific endpoints.

To avoid collisions and keep the Repo’s virtual namespace coherent, the following rules apply:

  • S3 & GCS Storage Resources

    • Bucket names within the same Repo must be unique across providers.

    • You cannot mix an S3 bucket named mybucket with a GCS bucket also named mybucket in the same Repo.

  • Azure Blob Storage Resources

    • Azure storage account names must not collide with any S3/GCS bucket names in the same Repo.

    • You cannot combine:

      • an S3 or GCS bucket called mystorage

      • with an Azure container under a storage account also called mystorage in the same Repo.

    • You may include multiple containers from the same Azure storage account within a single Repo.

Repo API Keys

Repo API keys let you securely connect your applications, pipelines, or services with your favorite SDK to a specific Repo without sharing your main account credentials.

You can build with one SDK, and interact seamlessly with cloud resources of a competitors. It makes your code lightweighted and more efficient. No need to have an expertise for every cloud providers.

Each Repo can have multiple key/secret pairs, scoped to a particular API endpoint type (e.g., S3, GCS, Blob, OpenAI) and access mode (READ, WRITE, READ/WRITE, or N/A if not available for the specific resource) that applies to all resources attached to that Repo.

You generate and manage these keys from the Repo’s API Keys section, where you can add new keys, update their description or access mode, or delete them entirely. For security, the secret is shown only once at creation time—if you lose it, you’ll need to create a new key and update your clients.

Repo API Keys Creation and Management

Once a Repo is saved, you can add and manage Repo API keys from the API Keys section in the Repo details. A Repo can have multiple key/secret pairs. Each key:

  • is scoped to a select API endpoint type for that Repo, and

  • grants access (according to its access mode) to all resources attached to the Repo.

Creating and Managing Keys

  • Click Add API key to generate a new key/secret pair.

  • After creation, you can:

    • edit the Description,

    • change the Access Mode, or

    • delete the key entirely.

You cannot retrieve the secret again after leaving or reloading the page.

You cannot retrieve the secret again after leaving or reloading the page. Please, save secret information during the API Key creation. See details here.

Each API key entry shows:

  • Description Free-text description of the key’s purpose, e.g. Read-only key for data analytics pipeline.

  • Access Mode Depending on the API Endpoint Type:

    • READ

    • WRITE

    • READ/WRITE

    • N/A

  • Key and Secret (See Below)

  • Created Date & timestamp when the key was generated.

API Endpoint Type Compatibility with APIs and SDKs

Cloud Storage
AI LLM

S3 (AWS-compatible)

OPENAI (OpenAI-compatible)

GCS (GCP-compatible)

AZURE BLOB (MS-compatible)

This choice defines:

  • which SDK / client configuration your applications use, and

  • the shape of the Repo API keys shown below.

Key formats by API endpoint type

API endpoint type
Key
Secret

Cloud Storage

S3

API Key ID

API Secret

GCS

Client Email

Private Key

AZURE BLOB

Shown as empty

Credential

AI LLM

OPENAI

Secret Handling

  • The API secret is encrypted at rest in our database and can only be decrypted in-memory by Bridge Nodes when processing requests.

  • For security reasons, the full secret is displayed only once, right after key creation.

  • If you lose a secret or forget to copy it, you must generate a new API key and update your clients/backends accordingly.

PreviousBucketsNextInfrastructure Network

Last updated

Was this helpful?