Postman alternative after the Free plan dropped team collaboration

Why a small team needs a Postman alternative after the Free plan change

A small team that shared collections through Postman's free tier now faces a decision. Under the plans Postman introduced in March 2026, the Free plan supports one user and cannot create a team, according to Postman's plan documentation. The team has three realistic options: pay for Postman Team seats, move to Bruno with collections stored in Git, or run the free Hoppscotch Community Edition on a server it controls for shared workspaces.

The choice turns on where the team wants shared work to live. Postman keeps shared collections and environments in its cloud and requires a signed-in account, so collaboration stays inside Postman's hosted workspace. Bruno takes the opposite approach: each collection is a folder of files on the user's filesystem, so teammates share it through Git branches, reviews and merges, and the team needs no account to open it. Hoppscotch Community Edition sits between the two, offering a hosted-style shared workspace that the team installs, administers and updates in its own infrastructure with a PostgreSQL database.

Before choosing, confirm three things. First, check whether your team already reviews changes in Git, because that decides whether file-based collections fit your workflow. Second, decide who will run the Hoppscotch server and apply its updates, since the Community Edition is installed and maintained by the user. Third, list which sign-in method your team needs, because the Community Edition uses Email, GitHub, Google or Microsoft OAuth rather than SAML. Those answers determine which of the three paths costs less to operate and fits your controls.

What a team needs from its API client once shared workspaces are gone

Once Postman's Free plan stops covering team work, the choice depends on a few concrete requirements: where collections live, how colleagues review them, who can sign in, how existing collections move over, and whether tests run in CI. Confirm which of these your team uses today before comparing Postman Team seats, Bruno and self-hosted Hoppscotch.

Where collections are stored

Decide whether collections may live in a vendor cloud at all. Postman keeps shared collections in its cloud and requires a Postman account for collections and environments. Bruno stores each collection as files in a local folder, so the team's Git host becomes the shared store. Hoppscotch Community Edition keeps team workspaces in a PostgreSQL database that you run. Check whether any collection holds credentials, since those files go wherever the collection goes.

How teammates share and review changes

Real review of API requests needs a history of changes. With Bruno, the team uses Git branches, diffs and pull requests, and the Open Source edition covers clone, diffs, pull and commit, while push, branch operations and merge conflict resolution in the app's Git UI are paid features. Git itself still works outside the app. With Hoppscotch, shared workspaces are edited live on the server. Confirm whether your team already reviews changes through pull requests.

Sign-in and access control

Identify who must sign in and how accounts are removed. Hoppscotch Community Edition signs users in through Email, GitHub, Google and Microsoft OAuth providers that the administrator configures, and it needs SMTP settings for email. SAML SSO and SCIM provisioning are part of the Hoppscotch Enterprise Edition, which requires a license key. Bruno's paid editions cover SAML single sign-on and SCIM provisioning through a license portal. Confirm whether your identity provider must enforce sign-in.

Import of existing Postman collections

List the collections, environments and scripts you need to keep. Bruno imports Postman collections exported as Collection v2 or v2.1 JSON and translates common pm.test and pm.environment calls, but it flags packages such as postman-collection and newman as unsupported. Hoppscotch imports Postman collections and environments, with a 50 MB limit on self-hosted editions. Bulk import of a full Postman data dump is part of Bruno Ultimate. Test an export of your largest collection before deciding.

Running collections in CI

Check whether pipelines run Postman collections through Newman or the Postman CLI today. Bruno provides bru run with test reports, and the Hoppscotch CLI runs hopp test and can write JUnit XML reports. The Hoppscotch CLI is described as alpha and needs Node.js 22 or later, so pin versions in your pipeline. Confirm which report format your CI system reads before you change any job.

Which option fits a small team: Postman Team, Bruno or Hoppscotch Community Edition

This table compares Postman Team seats, Bruno with Git and self-hosted Hoppscotch Community Edition across storage, sharing, sign-in, SSO, CI and trade-offs. Read each row against your team's identity provider, CI setup and tolerance for running a server. Confirm Postman Team pricing and features on Postman's current plan page before deciding, since the plan structure changed in March 2026.

Criteria	Postman Team seats	Bruno with Git	Self-hosted Hoppscotch Community Edition
Where collections live	Postman's cloud, under a signed-in account	Plain files in a local folder, versioned in Git	Team workspaces in your own PostgreSQL database
How the team shares them	Shared workspaces in Postman	Git clone, branch, pull and commit by the team	Shared team workspaces on your Hoppscotch instance
Sign-in options	Postman account sign-in	No account needed for the client	Email, GitHub, Google or Microsoft OAuth set by your admin
SSO and SCIM	SSO sits in a paid Postman add-on; confirm current terms on the plan page	SAML SSO and SCIM only in paid Bruno editions	SAML, OIDC and SCIM only in the paid Enterprise Edition
CI tooling	Newman or the Postman CLI	bru run with test reports	hopp test with JUnit XML reports (alpha CLI)
Who runs the infrastructure	Postman hosts the service	No server needed; your team manages Git	Your team installs, administers and upgrades the server
Main trade-off	Least setup, but per-seat cost and data in Postman's cloud	Lowest running cost, but Git skills and Git UI features may need a paid edition	Keeps data on your servers, but you carry hosting, SMTP and upgrade work

How Bruno with Git replaces shared Postman workspaces

Bruno does not replace Postman's shared cloud workspace with a server-side sync layer. It is offline-only, and its README states there are no plans to add cloud sync. Each collection is a folder on a filesystem, and the team shares that folder through Git or any other version control system. For a team that has lost shared Postman collaboration on the Free plan, the decision is whether its members are comfortable making commits, pulls and merges in a repository rather than clicking a shared workspace. Git itself works with any edition, so the question is mostly about which steps the Bruno app handles for you.

The Open Source edition's Git UI covers clone, initialize, diffs, pull and commit. Push, branch operations, remote connections and merge conflict resolution in the app are paid features, according to Bruno's pricing page. A team that wants everyone to work inside the app with pushes, branches and conflict resolution needs Pro or Ultimate seats, which are billed per user per month. A team that is comfortable running git push, branching and resolving conflicts in a terminal or another Git client can keep the free edition. Confirm with Bruno which edition covers the Git workflow you intend to use before you plan the seat count.

Two limits on the Open Source edition apply to this plan: it allows 2 workspaces and 5 OpenAPI syncs per month, according to Bruno's pricing page. Plan the workspace layout for the team's repositories before migration. Bulk import of a full Postman data dump is included only in Bruno Ultimate Edition. Single-collection imports in Collection v2 or v2.1 JSON work on the free edition. Bruno translates common Postman script APIs such as pm.test and pm.environment during import and flags packages such as postman-collection and newman as unsupported, so review the translated tests in a pull request before anyone relies on them.

Choosing by team situation: Git-comfortable teams, teams that want a web workspace, and teams needing SSO

If your developers already review changes in pull requests and keep project files under version control, Bruno fits the way the team works. Bruno is MIT-licensed, works offline, and stores each collection as files in a local folder, so the collection travels with the code and follows the same review and branching habits. There is no hosted workspace to administer and no database to run for the API collections themselves.

Collections in the repository: Commit the collection folder next to the service it tests, so requests change in the same pull request as the code.
Free editions cover the core loop: The Open Source edition includes clone, initialize, diffs, pull and commit in the Git UI. Git itself works outside the app on any edition.
Paid Git UI features: Push, branch operations, remote connections and merge conflict resolution in the app are paid features, so check whether your team needs them in the app or can use the command line.
Command-line runs: The Bruno CLI runs collections in CI with bru run and can produce test reports.
Limits to plan for: The Open Source edition is limited to 2 workspaces and 5 OpenAPI syncs per month.

Confirm with your Git-comfortable developers whether they will accept terminal-based Git for push and merge, since that determines whether a paid Bruno edition is needed.

How to move a small team off Postman without losing collections

This sequence takes a small team from Postman's cloud workspaces to either offline Bruno collections in Git or a self-hosted Hoppscotch instance, with each collection checked and each step confirmed in your own environment before the old workspace is retired.

Inventory Postman workspaces, collections and environments
A team admin or the person who owns the Postman account lists every workspace, collection and environment the team uses, marks which ones are shared, and notes which requests depend on secrets, mock servers or monitors. Confirm who holds access to each workspace, because after the March 2026 plan change the Free plan supports one user and cannot create a team. The step is done when the list names each collection, its owner and the environments it needs, and every item has a decision: migrate, archive or drop.
Export collections as Collection v2 or v2.1 JSON
Export each collection to JSON from Postman, choosing the Collection v2 or v2.1 format, and export the matching environments. Bruno imports both versions and Hoppscotch imports collections and environments from Postman, so these files are the common handoff. If you want every collection and environment in one file, note that a full account-wide bulk export is requested by a team admin and is downloadable for a limited window, so plan that request in advance. The step is done when each exported file opens as valid JSON and the file count matches your inventory.
Choose Bruno or a self-hosted Hoppscotch instance
Decide between Bruno, which keeps collections as files in a folder for Git collaboration with no cloud sync, and a self-hosted Hoppscotch Community Edition, which stores team workspaces in your own PostgreSQL database and needs a server, SMTP settings and sign-in providers. Check whether your team needs Git-based review or a shared server, and confirm which paid Bruno features or Hoppscotch Enterprise features, if any, your governance requires. The step is done when the team has a written choice and an owner for the chosen tool.
Import collections and review script translation
Import the JSON files into Bruno or Hoppscotch. Bruno translates common Postman script APIs such as pm.test, pm.environment, pm.globals, pm.collectionVariables and pm.response and flags Postman-specific packages such as postman-collection and newman as unsupported, so each flagged script needs a manual rewrite. Hoppscotch needs its own script review as well. Run a sample request from each collection against a non-production endpoint to confirm the responses match. The step is done when every collection imports, every flagged script has an owner and a rewrite, and sample requests pass.
Commit Bruno folders to Git or set up Hoppscotch workspaces
For Bruno, place the collection folders in a Git repository, commit them and have teammates clone the repository and pull changes. Keep environment files that contain secrets out of the repository and use the secret handling your organization already approves. For Hoppscotch, create team workspaces on the self-hosted instance, invite members through the sign-in provider you configured and assign access per workspace. The step is done when each team member can open the collections, and a test change made by one person appears for another.
Keep secrets out of Git and workspace exports
Review every environment and collection for API keys, tokens, passwords and certificates before the first commit or workspace import. Move them into a secret store or into local, uncommitted environment settings, and add ignore rules so they cannot be committed by accident. Confirm with your security team how the chosen tool stores its own local data, since this is an area to check in your own environment rather than assume. The step is done when a scan of the repository or workspace finds no live credentials and a named person has signed off.
Wire the CLI into CI pipelines
Replace Newman or the Postman CLI in your pipeline with the Bruno CLI, which runs with bru run and can produce test reports, or with the Hoppscotch CLI, which runs hopp test from a file or a self-hosted instance and can write JUnit XML. Note that the Hoppscotch CLI is described as alpha and needs Node.js 22 or later for current versions. Store the collections next to the pipeline definition and pass any secrets from the CI secret store. The step is done when a pipeline run passes on a known-good collection and fails on a deliberately broken test in a test branch.
Confirm the cutover and retire the Postman workspace
Run the migrated collections alongside Postman for a short parallel period agreed by your team, compare results for the same requests, and confirm each team member has moved their own work. Then archive the Postman workspace according to your records policy and remove team members from it. Record who approved the cutover and where the collections now live. The step is done when every collection has been verified, the owner has signed off and the old workspace is archived.

Questions small teams ask before changing their API client

How much does it cost to keep Postman Team seats compared with self-hosted options?

The answer depends on seats, support and staff time more than on the software licence, because Bruno and Hoppscotch Community Edition are both MIT-licensed and free to use. Postman Team is billed per seat, so its cost recurs with headcount. Bruno's Open Source edition costs $0, while its paid Pro and Ultimate editions are listed at $6 and $11 per user per month, billed annually, and are optional. Hoppscotch Community Edition has no seat fee, but it needs a server, a PostgreSQL database, SMTP for email and someone to run upgrades. Ask any vendor or partner for a written quote that separates one-time setup from recurring hosting, seats and maintenance.

Which costs recur after a move away from Postman Team?

Recurring costs fall into four groups, and each one is driven by different factors:

Seats: only if you choose a paid Bruno edition or Postman Team, and driven by headcount.
Server and database: Hoppscotch Community Edition runs as Docker containers and stores data in PostgreSQL, so hosting capacity and backups recur.
SMTP and sign-in: email delivery and the OAuth providers you configure for Email, GitHub, Google or Microsoft sign-in recur with use.
Staff time: upgrades, backups, access reviews and user support. The Hoppscotch Community Edition is updated by you on quarterly releases, so this effort grows with the number of environments you run.

Bruno's offline model removes the server line entirely, since collections are files in Git. Confirm your own hosting and staff rates before comparing totals.

How long does a migration from Postman take?

No duration is stated here because it depends on how many collections, environments and scripts your team has, and on whether scripts need rewriting. Bruno imports Postman Collection v2 and v2.1 JSON and translates common pm script calls, but it flags packages such as newman as unsupported, so those scripts need manual work. Hoppscotch's importer accepts Postman collections and environments, with a 50 MB limit on self-hosted editions. Ask a partner for a scoped plan that lists the collections in scope, the script rework, the team training and the cutover date in a written quote.

Can a small team migrate by itself?

Yes for Bruno, and it is usually the simpler path. Bruno runs as a desktop app on macOS, Windows and Linux, and collections live in a folder that you commit to Git. A team can export its Postman collections, import them, review the translated scripts and commit the folders without a server. A self-hosted Hoppscotch Community Edition is more involved because someone must install and maintain the Docker deployment, configure PostgreSQL, set up OAuth and SMTP, and plan upgrades. Teams without that skill set often bring in a partner for the server work and keep collection migration in-house.

What does the migration need from our team?

The work needs named owners and some time from people who know the APIs. Typically this means someone who can export collections and environments from Postman, someone who can review scripts that call pm.test, pm.environment or other Postman-specific APIs, and an admin who can set up Git repositories and access rules. If you choose Hoppscotch, you also need an operator for the server, a PostgreSQL owner and someone who can configure the sign-in providers. Agree on who signs off each collection before the Postman account is closed, and keep secrets out of Git from the start.

Do Postman exports keep our collections intact?

Exports keep the request structure, but you should verify the result rather than assume it. Postman exports collections as Collection v2 or v2.1 JSON, and both Bruno and Hoppscotch import those formats. Requests, folders and environments generally carry over, while pre-request and test scripts may need translation, and Postman-only packages do not run unchanged. Environment secrets may not export as values, so check every variable after import. Compare request counts and run a sample of tests against the original API before you retire the Postman workspace.

Evidence that shows the team controls its API collections

Once collections live in Git, files, and a self-hosted server, the team holds the evidence itself rather than relying on a vendor's cloud. The cards below cover the records a reviewer or auditor would ask to see, and each one names what to check before the migration is called complete.

Git history of collection folders

Bruno stores each collection as a folder of files, so the commit log becomes the change record for requests, scripts and environments. Check that changes to collections go through pull requests with a named reviewer, and that the main branch is protected from direct pushes. Confirm where Git hosting lives and who holds administrator rights. Git push, branch and merge conflict operations in the Bruno app are paid features, so confirm how your team will do them if it stays on the Open Source edition.

Client and server versions in use

Record the exact Bruno version on each workstation and the Hoppscotch Community Edition image tag on the server. Bruno's current release is v4.2.1 and Hoppscotch's is 2026.9.0, but confirm the newest tags on the GitHub release pages on the day you sign off. Keep the upgrade history with dates, so you can show which versions handled which collections.

Sign-in and access configuration

On a self-hosted Hoppscotch instance, document which sign-in providers are enabled (Email, GitHub, Google or Microsoft OAuth), who administers them, and how SMTP is configured for email. Record which team members hold workspace roles. Confirm whether SAML SSO or SCIM is needed, because those are part of the paid Enterprise Edition rather than the Community Edition.

PostgreSQL backup and restore records

Hoppscotch Community Edition keeps team workspaces in PostgreSQL, set through DATABASE_URL, so that database is the primary record of shared requests and environments. Keep a schedule for backups, the retention period, and the location of copies. Run and log at least one restore test into a separate instance, because an untested backup is not evidence that data can be recovered.

CI test reports from the CLI

Run collections in the pipeline with bru run for Bruno or hopp test for Hoppscotch, and save the JUnit XML output with each build. The reports show which requests passed on a given commit and link test results to the collection version that produced them. Note that the Hoppscotch CLI is labeled alpha, so record the npm package version and the Node.js version used, which must be 22 or later.

Register of where secrets are kept

Keep a short register that lists every API key, token and client secret used by collections, the system that stores it, and the people allowed to read it. Confirm that no secret appears in committed .bru or YAML files, environment exports or Hoppscotch environment values that others can read. Review the register at each collection change and when someone leaves the team.

What to confirm with Postman, Bruno and Hoppscotch before deciding

Start with Postman's current pricing, because the case for leaving depends on what a Team seat and its add-ons cost today. Confirm the Team seat price, whether the Simple Security add-on is still needed for single sign-on, and how AI credit overages are billed for your expected usage. Read the plan limits in Postman's About plans documentation and get the figures in writing from Postman's sales team, since plan terms can change. Ask for a quote that lists each seat, add-on and renewal term separately so you can compare it with the other two options line by line.

Next, confirm which Bruno edition your team needs. The Open Source edition covers clone, pull, commit and diffs, but Git push, branch operations, remote connections and merge conflict resolution in the app are paid features, and bulk Postman import sits in the Ultimate edition. Git itself works outside the app on any edition, so a team that is comfortable with the command line may need only the free edition. Check Bruno's pricing page for the current seat prices and workspace limits, and test the import and Git workflow with one real collection before buying seats.

For Hoppscotch Community Edition, confirm the install requirements against your own environment: CPU and memory for the build step, PostgreSQL reachable through DATABASE_URL, SMTP settings for email sign-in, and the OAuth providers your identity policy allows. Your team also needs an upgrade plan, since the Community Edition is installed and updated by you. Treat the Hoppscotch CLI as alpha: run hopp test against a copy of your collections in a staging pipeline before relying on it for gating, and confirm the JUnit XML output your CI system reads. Start with the Community Edition install guide.

How DeployOpen deploys a self-hosted API client for a team

DeployOpen plans, implements and hands over self-hosted API clients inside your own infrastructure, whether that means offline Bruno collections in Git or a Hoppscotch Community Edition instance on your servers. Each engagement starts with a written scope, so you know what is migrated, tested and documented before work begins.

How we scope

We inventory which Postman workspaces, collections, environments and scripts your team actually uses today.
We agree which client path fits your team: Bruno with Git, a self-hosted Hoppscotch instance, or a mix of both.
We define in writing which secrets, environments and data stay on infrastructure you control, and where they are stored.

How we build

We import collections through the documented Postman and OpenAPI routes, then review each rewritten script and flagged package.
We set up the Hoppscotch Community Edition containers, PostgreSQL database, OAuth sign-in and SMTP settings in your environment.
We wire collections into your CI pipeline, with test runs and reports checked against the existing Newman or Postman CLI jobs.

How we hand over

We deliver a documented repository layout, team conventions for branches and reviews, and written runbooks for each client.
We test the migrated collections against the original Postman results and record gaps as agreed follow-up items.
We train the team on the new workflow and document how to upgrade Bruno or Hoppscotch releases safely in your environment.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Your quote follows from the written scope. Ask for line items covering setup, migration, CI work and training separately.
Confirm with your team which edition features you need, such as SSO or Git UI operations, before you commit to paid seats.