QoL Feature: Remote Git-Linked Collections & Workspace Repositories

[youssef-hsn]

In microservices architectures, API collections are ideally colocated inside individual service repositories to keep spec changes in sync with code PRs. However, this creates significant developer friction across large engineering organizations:

• Disk Overhead & Setup Fatigue: Engineers and QA teams must clone dozens of full service repositories to local disk just to view and execute .bru files.
• Sync Drift: Keeping dozens of local clones up to date requires constant manual git pull commands across separate directories.
• Lack of Central Discovery: There is no single place in the Bruno UI to view all organizational APIs without opening each local folder individually.

This is a personal opinion that Bruno collections are better stored per service, I am aware that you can also keep an updated central repo for this but I feel like this makes for duplicate unnecessary effort that can be prevented with a simple and easy to implement feature on the Bruno app.

---

Solution I am willing to own:

We propose introducing Git-Linked Collections and Workspace Repositories to allow on-demand collection loading directly from Git sources without requiring local service clones.

1. Remote Git-Linked Collections

Allow users to add a collection by providing a Git repository URL (HTTPS or SSH).

• Bruno fetches and caches .bru files in an isolated app data directory on demand.
• Supports both public and private repositories (leveraging system SSH keys, ssh-agent, or PATs).
• Enables a "Pull / Sync" action in the UI to fetch the latest changes without touching local source code directories.

2. Workspace Manifest Repositories

Introduce an organization-wide workspace config (e.g., bruno-workspace.json) stored in a lightweight central repository (e.g., api-catalog).

Opening this single manifest repo in Bruno instructs the app to load linked collections dynamically from remote service repositories:

{
  "version": "1",
  "name": "Acme Platform Workspace",
  "collections": [
    {
      "name": "Payments Service",
      "repository": "git@github.com:acme/payment-service.git",
      "path": "/bruno"
    },
    {
      "name": "User Service",
      "repository": "git@github.com:acme/user-service.git",
      "path": "/bruno"
    }
  ]
}

Workflow Impact: A developer clones one lightweight api-catalog repository, opens it in Bruno, and instantly gains access to every microservice API collection across the company on demand.

The workspace repo will idealy also allow for having common collections defined there like for services similar to keycloak that people may self host to handle auth without necessarily having a repo for the service or 3rd party service

---

Alternatives I have considered:

• Git Submodules: Requires developers to clone and sync entire codebases locally, consuming disk space and requiring complex submodule commands.
• Central Collections Repo: Separates .bru files from service codebases, leading to specification drift and breaking single-PR feature workflows.

---

Additional context

This capability would make Bruno the ideal choice for microservice-heavy enterprises by combining colocated API specs (in service repos) with centralized discovery (in developer workspaces).

I am fully open to be the person that owns this feature and implement it then open a pull request 🙌