Leaving Postman Cloud: A Migration Story to Bruno and the Efficiency of Git-Native Workflow

Lately, I’ve felt that Postman is becoming increasingly cloud-centric, packed with additional features that, frankly, I don’t need in an API Client. The main issue arises when team collaboration becomes cumbersome due to workspace limitations or member caps on the Postman free tier. As an engineer who worships efficiency, I yearned for something that fits into our existing ecosystem: Git.

Then, I discovered Bruno.

One Request, One File

The first thing that impressed me about Bruno is its philosophy: Offline-first and Plain Text.

Unlike Postman, which stores collections in a single monolithic collection.json (requiring re-imports whenever changes occur) or within their cloud which limits members on the free tier, Bruno saves every request as a file with a .bru extension. Imagine: one request is one simple text file.

Because it is file-and-folder based, I no longer need a paid cloud subscription just to share API collections with teammates. I simply include the collection folder in the project’s Git repository. Want to share the latest API updates? Just git push. Teammates want to grab them? Just git pull.

Implementing a Single Source of Truth: OpenAPI to Bruno

This is the most technically satisfying part. As a backend engineer, I often use OpenAPI Specs (centered in a file named api.yml) as the primary documentation. The classic problem is: The YAML documentation has changed, but the API Client collection is still on an old version.

I decided to build an automation system using the Bruno CLI. I created a Centralized API Collection repository with the following workflow:

1. Centralized Repo: All Bruno collections for various services are stored here.
2. Automated Trigger: Within this repo, a GitHub Actions workflow monitors changes to the api.yml file (OpenAPI Spec).
3. Bruno Build: Every time the API specification changes, the workflow runs the Bruno CLI to automatically generate or update the collection.

“No more manual updates. If the API contract changes in the YAML file, our team’s Bruno collection will update automatically after the CI/CD process completes.”

Why Bruno Feels “Right” for Developers

After migrating, here are a few reasons why this transition felt so natural:

• Truly Git-Friendly: Since the format is plain text, I can clearly see what changed in an API (e.g., header changes or new parameters) directly through a diff on GitHub/GitLab during code reviews.
• Lightweight: Bruno doesn’t try to be everything. It focuses on being a fast API Client without the bloatware.
• Collaboration at No Extra Cost: As long as your team uses Git, you already have “cloud” collaboration for free.
• Flexible Scripting: Support for JavaScript in pre-request and post-response scripts is still there, making the transition from Postman feel very familiar.

Closing: Back to Basics

The journey of moving to Bruno taught me that sometimes, the best solution isn’t the tool with the most features, but the one that integrates best with our workflow. By putting API collection control back into the hands of Git, I’ve not only saved on operational costs but also ensured that our API knowledge base is always in sync with the source code.

For those looking to try a Git-friendly approach to managing APIs, Bruno is an exciting option to explore. Full documentation can be accessed here.