Bruno for Teams: Cloud Sync Alternatives and Workarounds

TL;DR

Bruno has no built-in cloud sync. Teams usually share collections through git repositories, shared network drives, dev containers, or manual copies. Each option works in a narrow case, but each adds operational overhead. Apidog now covers both sides of the workflow: Spec-First Git mode keeps your OpenAPI spec in your repo and moves changes through pull requests, while optional cloud sync adds live collaboration, role-based access, shared credentials, and a built-in mock server.

Try Apidog today

Introduction

Bruno’s local-only design is intentional. Your API collections stay on your machine. There is no cloud account, subscription dependency, or vendor-hosted collection store.

That design is useful for individual developers, but it creates a team coordination problem:

• How do five developers share the same API collection?
• How does QA get the latest request definitions?
• How does a new hire set up environments without someone sending files over Slack?
• How do you prevent secrets from being committed while still keeping setup fast?

This guide breaks down the practical Bruno sync workarounds, where they fail, and how Apidog’s Spec-First Git mode gives teams a repo-based workflow without giving up live collaboration. For a broader comparison, see this roundup of API tools that work with Git.

Option 1: Use git, Bruno’s intended sharing model

Bruno was designed around git. Collections are stored as .bru files, environments are JSON files, and everything is plain text.

How to set it up

1. Create a repository for your Bruno collection, or add a collection folder to an existing repo.
2. Push the collection to GitHub, GitLab, Bitbucket, or your self-hosted git server.
3. Ask team members to clone the repo.
4. Open the cloned folder in Bruno.
5. Commit and push collection changes.
6. Pull updates before editing.

Example layout:

api-collections/
  bruno.json
  environments/
    local.json
    staging.json
    production.json
  users-api/
    get-user.bru
    create-user.bru
  orders-api/
    create-order.bru
    list-orders.bru

What works well

• Every request has version history.
• API changes can go through pull requests.
• CI/CD is straightforward with bru run.
• You do not need a third-party API workspace.
• The workflow fits developer-only teams already using git.

What breaks down

• Non-git users struggle with cloning, branching, pulling, and resolving conflicts.
• Changes are not live. Someone must push, and everyone else must pull.
• Secrets should not be committed, so credentials need a separate process.
• Merge conflicts happen when two people edit the same request.
• Git repo permissions do not map cleanly to API workspace roles.

Best fit

Use this if your team is developer-only, git-fluent, and small enough that manual pull/push coordination does not slow people down. This pattern matches the broader OpenAPI version control with Git approach.

Option 2: Put the collection on a shared network drive

Some teams place the Bruno collection folder on a NAS, shared file server, Dropbox folder, or Google Drive folder.

How it works

Bruno can open a collection from any local folder path. If your shared drive is mounted locally, point Bruno at that folder.

What works

• Setup is simple.
• No git knowledge is required.
• Non-developers can access the same files.

What breaks down

• Version history is weak or missing.
• Two people editing the same files can overwrite or corrupt changes.
• Network drives are slower than local files.
• Access control is limited to filesystem permissions.
• Secrets still need separate management.
• Offline work is painful or impossible.

Best fit

This can work for 2-3 people who rarely edit at the same time. Avoid it for active API development teams.

Option 3: Use Gitpod or dev containers

Some teams keep Bruno collections inside a repository and load them in a Gitpod workspace or dev container.

How it works

The collection lives in the repo. A Gitpod workspace or dev container starts with the collection available, and the team runs Bruno CLI or local tooling against it.

What works

• Every developer gets a consistent environment.
• The API collection stays close to the codebase.
• Setup is repeatable.
• CI-style execution is easier to standardize.

What breaks down

• It is still a git-based workflow.
• Non-git users do not benefit much.
• The Bruno desktop GUI usually is not part of the cloud dev environment.
• Real-time collaboration still does not exist.

Best fit

Use this if your team already uses Gitpod or dev containers and wants API tests bundled into the development environment.

Option 4: Give every developer their own copy

This is the least structured pattern. Each developer keeps a local Bruno collection and updates it manually from docs, exports, or a teammate’s copy.

What works

• No coordination is needed.
• It is fast for one person.

What breaks down

• Collections diverge immediately.
• There is no source of truth.
• QA, backend, and frontend may test different request definitions.
• Maintenance overhead grows quickly.

Best fit

Solo development only. For teams, this creates technical debt almost immediately.

The common limits of every Bruno sync workaround

All Bruno sharing patterns hit the same limits.

1. No real-time collaboration

With Bruno plus git, everyone works from their last pull.

Example:

1. Alice adds a request.
2. Alice commits and pushes.
3. Bob sees nothing until he pulls.
4. If Bob edited the same file, someone resolves a conflict.

That is acceptable for normal code review, but it is friction during live API design or debugging sessions.

2. No role-based API access

Git permissions are usually repository-level read/write permissions. They do not express API workspace roles like:

• Viewer
• Editor
• Admin
• Contractor with access to one project
• Stakeholder who can run requests but not edit them

Bruno inherits the repo permission model.

3. No shared environment credentials

Bruno correctly avoids committing secret variables. But that means every teammate must configure secrets locally.

When a token rotates, someone needs to notify the team, update docs, or distribute the new value through another system.

4. No collection-level comments

GitHub or GitLab comments attach to commits and diffs. They do not attach naturally to the live API request inside the collection.

That makes review possible, but not the same as collaborative API work.

Apidog Spec-First Git mode: keep git, add collaboration

The usual tradeoff is “Bruno plus git” versus “cloud API workspace.” Apidog’s Spec-First Git mode reduces that tradeoff.

Your OpenAPI spec lives in your own GitHub, GitLab, or self-hosted repository. Apidog then adds a collaborative workspace on top of that repo-backed source of truth.

What changes compared to Bruno plus git?

The API spec stays in your repo

You connect an Apidog project to a git repository. The OpenAPI definition syncs as files.

A practical workflow looks like this:

1. Create or update an API endpoint in a feature branch.
2. Commit the OpenAPI spec change.
3. Open a pull request.
4. Review the API contract diff.
5. Merge the branch.
6. Sync the updated spec into the Apidog workspace.

This keeps the same review model Bruno users like, but applies it to a full OpenAPI document instead of separate .bru request files. For the design-first reasoning, see What is spec-first API development?.

Docs, tests, mocks, and examples derive from one definition

With a spec-first workflow, the OpenAPI document becomes the central artifact.

When the spec changes, related API assets can stay aligned:

• API documentation
• Example responses
• Mock behavior
• Test cases
• Contract review

This follows the spec-as-code model: one API definition drives the workflow instead of maintaining separate tools and duplicated request data.

You keep git and add live collaboration

Git remains the system of record for review and history.

The shared Apidog workspace adds the live collaboration layer that git alone does not provide. Team members can work in the app and see updates without waiting for manual pull/push cycles.

Role-based access sits above the repository

Apidog workspace roles let teams separate access more clearly than repo-level git permissions.

For example:

• A stakeholder can view or run requests without editing them.
• A contractor can be scoped to specific projects.
• Admins can manage workspace-level settings.

Shared credentials are managed centrally

Instead of asking each developer to maintain local secret files, cloud environments can store shared variables centrally.

That makes token rotation simpler:

1. Update the shared environment value once.
2. Team members continue using the same variable name.
3. No one commits secret files.
4. No one distributes credentials through chat.

Mock server support is built in

Bruno has no built-in mock server, which is why teams often look for a Bruno mock server alternative.

In Apidog, mocks come from the API spec, so frontend developers can start building against realistic responses before the backend is complete.

It can run in CI

Apidog includes a CLI runner, so tests tied to the synced spec can run in your pipeline, similar to how a Bruno workflow might use bru run.

Bruno plus git vs Apidog Spec-First Git mode

Capability	Bruno + git	Apidog Spec-First Git mode
Files in your own repo	Yes (.bru)	Yes, OpenAPI spec
Branch + pull-request review	Yes	Yes
CI runner	Yes, with bru run	Yes, with Apidog CLI
Self-hosted / GitLab support	Yes	Yes
Live multi-user editing	No	Yes
Role-based access	No	Yes
Central shared credentials	No	Yes
Mock server from the spec	No	Yes
Docs + tests derived from one definition	No	Yes

Spec-First Git mode is in beta, so validate it with your own GitHub or GitLab setup before migrating a full team.

For setup details, see:

• Apidog’s Git integration and sync
• Spec-First mode guide
• Stoplight + Postman vs Apidog

When to stay with Bruno

Stay with Bruno if:

• Your team is mostly or entirely developers.
• Everyone is comfortable with git.
• Pull/push coordination is acceptable.
• You do not need live sync.
• Repository-level permissions are enough.
• You already have a good secret-management process.

For small developer-only teams, Bruno plus git can be simple and effective.

When to switch to Apidog Spec-First Git mode

Move to Apidog when:

• Non-developers need API access without learning git.
• Your team has 5+ people and git-only coordination has become daily friction.
• You need live collaboration during API design or debugging.
• You need viewer/editor/admin roles.
• You want centralized environment credentials.
• You need a mock server next to your API client.
• You want docs, tests, examples, and mocks connected to one OpenAPI definition.

Because the spec still lives in your repo, this is not a move away from version control. It is a way to keep git while adding a team workspace.

If you stay with Bruno: use a clean git workflow

If Bruno is still the right fit, use a repository structure that makes onboarding and secret handling explicit.

Recommended repository structure

api-collections/
  .gitignore
  README.md
  environments/
    local.json
    staging.json
    production.json
  users-api/
    get-user.bru
    create-user.bru
  orders-api/
    create-order.bru
    list-orders.bru
  bruno.json

Example .gitignore

# Local secrets
*.secret.json
.env
.env.*

# OS/editor noise
.DS_Store
.vscode/
.idea/

Environment template

Keep non-secret variable names in committed environment files:

{
  "baseUrl": "https://api.example.com",
  "accessToken": "",
  "tenantId": ""
}

Then ask developers to create a local secret file, for example:

environments/production.secret.json

Do not commit that file.

README onboarding checklist

Add clear setup instructions:

# API Collections

## Setup

1. Clone this repository.
2. Open this folder in Bruno.
3. Copy `environments/production.json` to `environments/production.secret.json`.
4. Fill in secret values from the team vault.
5. Pull latest changes before editing requests.
6. Commit request changes through a pull request.

CI/CD pattern

Inject secrets at runtime instead of storing them in the repo.

Example flow:

export API_BASE_URL="https://api.example.com"
export API_TOKEN="$CI_API_TOKEN"

bru run users-api --env production

This keeps the repository clean while still allowing repeatable test execution.

Final recommendation

Bruno’s no-cloud model is useful when your team wants local files, plain text, and git-based ownership. The workarounds are manageable for small developer-only teams.

But once you need live collaboration, scoped access, central credentials, mocks, or non-developer participation, git alone is not enough.

Apidog’s Spec-First Git mode gives you a middle path: keep the API spec in your repo, keep pull-request review, and add the collaboration layer Bruno does not provide. Download Apidog and connect it to an existing repository to test the workflow on your own API.