Skip to main content
Bridge CLI is open source under AGPL-3.0-only, and we actively welcome contributions to the CLI itself. The best contribution path today is the open-source CLI project: providers, commands, tests, architecture, performance, and implementation-backed documentation.
The public docs site and marketing website are maintained by the Bridge team. External contributions are most valuable when they improve the CLI and the technical docs that stay close to that implementation.

What we would love help with

The highest-value contribution areas right now are:
  • new providers
  • bug fixes
  • tests and reliability improvements
  • CLI ergonomics
  • documentation updates tied directly to implemented behavior
Examples:
  • adding a new backend under src/provider/
  • tightening error handling or timeout behavior
  • improving command output consistency
  • expanding test coverage for filesystem or Postgres behavior
  • updating docs in the same PR as a CLI change

Good first contribution areas

If you are looking for a practical starting point, these are usually strong first contributions:
  • small command UX improvements
  • test gaps
  • docs corrections that are clearly backed by code
  • provider edge cases
  • implementation cleanup that makes the codebase easier to extend
If you are adding functionality, try to keep the change scoped and well-tested.

Contribution workflow

The current flow is straightforward:
  1. Fork the repository
  2. Create a branch for your change
  3. Build and test the CLI locally
  4. Make the implementation change
  5. Update any affected docs in the same PR
  6. Open a pull request against main
For the local development workflow, see Development.

Local setup

Bridge is a Rust project with a provider-oriented architecture. The quickest local setup flow is:
git clone https://github.com/usebridgeai/cli.git
cd cli
cargo run -- --help
cargo test
If you are working from this monorepo checkout, the Rust crate lives in the cli/ directory.

Project areas contributors should know

The main CLI code lives in:
  • src/cli.rs for the command-line definition
  • src/commands/ for command implementations
  • src/config.rs for bridge.yaml loading and env var expansion
  • src/provider/ for provider implementations
  • tests/ for CLI and provider integration tests
If you are adding a provider, see the current architecture and provider shape in ARCHITECTURE.md.

Expectations for pull requests

A strong Bridge PR usually includes:
  • one clear goal
  • implementation changes that are easy to review
  • tests for behavior changes
  • docs updates when command, provider, or config behavior changes
If your change affects:
  • command syntax
  • config behavior
  • provider semantics
  • output shape
  • errors or timeouts
please update the matching docs page in the same pull request when possible.

CLA and licensing

Before your first PR is merged, you must sign the Bridge CLA. The canonical CLA is here: In short:
  • you keep copyright to your own contribution
  • you grant the project the rights needed for AGPL-3.0-only and commercial licensing
  • you only need to sign once
Bridge CLI licensing details live here:

Security issues

If you discover a security issue, do not open a public GitHub issue with exploit details. Report it privately to:
  • hello@bridge.ls
Security-sensitive areas currently include:
  • filesystem path traversal
  • SQL injection and identifier handling
  • credential exposure in output or logs
  • dependency and CI supply-chain risk

Docs contributions

Docs contributions are welcome when they stay close to the CLI implementation. The most useful docs contributions are:
  • correcting command behavior
  • updating config examples after a CLI change
  • documenting a new provider
  • clarifying real runtime limits or edge cases
The Bridge team handles the broader public docs presentation, navigation, and website positioning.

Development

Build Bridge locally, run tests, and understand the codebase layout.

Commands

See the command surface you may be improving when you work on the CLI.

Providers

See the current provider model and the behavior of filesystem and Postgres.

View the source

Open the repository, issues, releases, and project files on GitHub.