Replace Newman in CI: Bruno and Hoppscotch CLI

Replacing Newman in CI: the short answer for Postman-driven pipelines

If your pipeline runs Postman collections through Newman or the Postman CLI, and a March 2026 plan change or an EU data residency requirement is forcing a review, the short answer is that Bruno's `bru run` and the Hoppscotch CLI's `hopp test` can both replace the collection runs, but they differ in where collections are stored and how results are reported. Bruno keeps each collection as plain files in a Git repository and produces test reports from the command line. Hoppscotch's CLI reads a collection file or pulls from a self-hosted instance and can write JUnit XML reports, but it is labeled alpha, so treat it as a component to pilot before you depend on it in a release gate.

Newman is licensed under Apache-2.0, so it can stay in your pipeline without a license decision. The reason to move is the surrounding stack: Postman's newer Postman CLI is Postman's official tool for quality gates, and it requires you to sign in with postman login before runs, which ties your pipeline to a Postman account and its plan limits. Confirm with your Postman administrator which plan and seat model your runners would need, and whether a service identity is available for unattended runs. Bruno's CLI and the Hoppscotch CLI do not need a Postman account to run tests, since the collections live in your repository or on your instance.

Before you pick a runner, check three things in your own environment: whether your pipeline needs a JUnit or other report format your CI server already parses, whether collections and environments must stay in your own repository or instance for data residency, and whether your scripts use Postman-specific packages such as postman-collection or newman, which Bruno flags as unsupported during import. The Bruno CLI documentation covers the run command and its reporting options, and the Hoppscotch CLI documentation covers the alpha hopp test workflow. Run one representative collection through each candidate in a non-production pipeline and compare the reports before you change any release gate.

Which CI capabilities map to Bruno CLI and Hoppscotch CLI

This table compares what Newman and the Postman CLI do in a pipeline with the Bruno CLI and the Hoppscotch CLI. Read each row as a question to answer for your own collections before you change a pipeline. The main takeaway is that the Hoppscotch CLI is alpha, so reporter and secret handling details need confirming against current docs before you commit to it.

Capability	Bruno CLI (bru run)	Hoppscotch CLI (hopp test)
Collection execution	Runs a collection folder from the command line with bru run, using the same files kept in Git	Runs collection tests from a file or from a cloud or self-hosted instance with hopp test
Environment variables	Environment files are stored with the collection; confirm how to pass or override values per CI job	Environments can be read from a file or instance; confirm the flag set for overriding values in CI
Script assertions	pm.test and related pm calls are translated on import; review translated tests after migration	Postman scripts must be rewritten to the Hoppscotch script API; plan time for test rewrites
Postman-only packages	postman-collection and newman are flagged as unsupported on import and need manual replacement	Confirm which Postman script dependencies the importer handles before relying on existing tests
JUnit or other reporters	Bruno provides test reports from bru run; confirm the exact report formats in the current CLI docs	Writes JUnit XML reports; confirm the report flag and output path against the current CLI docs
Runner authentication	Secrets are supplied through the CI secret store as environment values; confirm the recommended pattern	Runs against a self-hosted instance need an access token from the CI secret store; confirm the supported method
Collection storage in Git	Collections are plain files in a folder, so the pipeline and the collection share one repository	Collections live in the instance database unless exported, so a Git copy must be maintained deliberately
Import of existing Postman collections	Imports Collection v2 and v2.1 JSON exports; bulk import of a full data dump is a paid Ultimate feature	Imports Postman collections and environments; self-hosted import size limit is 50 MB
Node.js requirement	Confirm the Node.js version the current Bruno CLI requires before updating runner images	Current versions need Node.js 22 or later, so older runner images must be upgraded

Bruno CLI or Hoppscotch CLI: which runner fits which pipeline

Both runners replace Newman in CI, but they differ in where collections live and how mature the command-line tool is. The cards below compare the two runners and the checks to make before moving a pipeline, since the collection source and the report format shape most of the changes.

Bruno CLI with collections in Git

The Bruno CLI runs bru run against a collection folder that is already in the repository, so the pipeline and the tests are versioned together. Bruno is MIT-licensed, and the collection is plain files, which makes review and rollback work the same way as code. Check that your pipeline image can install the CLI and that the test reports produced by bru run match what your existing dashboards and gates read.

Hoppscotch CLI with a self-hosted source

The Hoppscotch CLI, run as hopp test, can read a collection file or pull it from a Hoppscotch instance. If your team already edits collections in a self-hosted Hoppscotch Community Edition, the pipeline can point at that instance rather than a file in Git. Confirm that the CI runner can reach the instance, that its credentials are stored in the CI secret store, and that the team accepts that the collection source of truth sits in the database.

JUnit XML reports from Hoppscotch

The Hoppscotch CLI can write JUnit XML reports, which most CI systems parse natively for test results and trend views. If your current gates rely on Newman's reporters, map each one to a JUnit field before cutover. Bruno's CLI reports are the other output to verify, since the exact format your pipeline expects should be tested with a sample run instead of assumed.

Alpha maturity of the Hoppscotch CLI

The Hoppscotch CLI is published on npm as @hoppscotch/cli and is described as alpha, so flags and output can change between releases. Pin the exact version in the pipeline, record it in the build log, and run the same collection through the old and new runners for a trial period. Bruno's CLI sits on the same file-based workflow that the team already uses for Git, which lowers the change-management risk for the test code itself.

Runtime requirements for the pipeline

The current Hoppscotch CLI needs Node.js 22 or later, which may require updating base images that pin older Node versions. Bruno runs on the runner through its own install path, so check that the chosen package source is permitted in your build network. Both tools add a version to manage in the image, so put the runner version and Node version in the same change record.

Choosing between the two runners

Choose Bruno when the collections should live in Git next to the code and the team accepts file-based review. Choose Hoppscotch when collections must stay in a self-hosted instance that other people edit and the pipeline must read from it. Before deciding, confirm the feature set each edition needs, including any Git UI or SSO functions that sit in paid tiers, and ask the vendors which features the CLI supports today.

What changes in scripts, reporters and pipeline steps

Most Postman collections carry assertions in the Tests and Pre-request Script tabs, written against the pm object. Bruno translates the common calls during import, including pm.test, pm.environment, pm.globals, pm.collectionVariables and pm.response, so many simple assertions arrive in working form. Translation is not the same as verification, because the converted script can run without error and still check a different value than the original.

Assertions: Compare each pm.test block with its Bruno equivalent and confirm the same status codes, body fields and headers are checked.
Environment writes: Confirm that values set by pm.environment.set or pm.collectionVariables.set are read back by later requests in the same run.
Chained requests: Check any flow where one response feeds the next request, since ordering and variable scope are the usual failure points.
Custom JavaScript: Helper functions, loops and data parsing need manual review and, usually, rewriting.
Pass counts: Record the number of assertions passing in Postman before migration and match it in Bruno.

Check that every converted test fails when the API returns a wrong value, not only when it passes.

Bruno flags Postman-specific packages such as postman-collection and newman as unsupported during import. Any script that requires these packages, or that depends on Newman's runtime objects, will not run in Bruno without changes. The flag is useful because it marks code that needs human attention rather than silently failing in CI.

Flagged requires: Search your scripts for require('postman-collection') and require('newman') before the first run.
Replacement logic: Rewrite the logic with standard JavaScript or a helper module stored in the collection folder.
Data files: Confirm that CSV or JSON data files used by Newman's iteration option are still available to the Bruno run.
Third-party libraries: Check which npm packages a script loads and whether each is available in the CI runner image.
Ownership: Assign a named person to sign off each rewritten script, since the original author may no longer be on the team.

Any rewritten helper should be covered by a test that proves its output matches the old behavior.

Newman and the Postman CLI accept their own flags for environments, iterations, timeouts and reporters. Bruno's CLI, bru run, and the Hoppscotch CLI, hopp test, use different option names, and their reporting outputs differ. Pipelines that parse Newman's reporter output or depend on a specific exit behavior need changes in the step that reads the report, not only in the command.

Command mapping: Build a table from each Newman or postman flag to its bru run or hopp test equivalent, and mark flags with no match.
Reporters: Hoppscotch's CLI can write JUnit XML reports, and Bruno's documentation describes test reports from bru run. Confirm the report format your CI system ingests before changing the parser.
Exit codes: Verify that a failed assertion produces a non-zero exit code in the new tool, so the pipeline fails as before.
Environment selection: Confirm how each tool selects an environment file in a headless run.
Tool maturity: The Hoppscotch CLI is described as alpha, so pin its version and retest after each upgrade.

Run both tools against the same failing request to confirm that the failure is reported the same way.

The CI job YAML is where the migration becomes operational. The job must install the new CLI, provide the collection and any environment files from Git, supply secrets from the pipeline store, and publish the report artifact. Node.js is needed for the Hoppscotch CLI, and current versions need Node.js 22 or later, so the runner image may also need updating.

Install step: Replace the npm install of postman-cli or newman with the install step for @hoppscotch/cli or Bruno's CLI, pinned to a version.
Runtime: Confirm the runner provides Node.js 22 or later for Hoppscotch.
Secrets: Pass credentials as CI variables, not as values committed in environment files.
Artifacts: Keep the existing report artifact step and point it at the new report path.
Parallel run: Run the old and new jobs side by side on the same commits for a set period, and compare results before removing the Postman job.

Before cutover, ask the CI platform team to confirm the runner image, secret handling and report ingestion in writing.

Keeping collections in Git next to the pipeline

Bruno stores each collection as plain files in a folder on disk, which means the collection can sit in the same Git repository as the pipeline code and be versioned, branched and reviewed with it. Requests, folders and tests change through ordinary commits, so a change to an assertion is reviewed in the same merge request as the service change it checks. Since Bruno 3.0.0, request data can also be saved as OpenCollection YAML files, an open specification created by Bruno, as an alternative to the plain-text .bru format. Confirm which format your team's Bruno version writes by default and whether a documented migration from .bru is needed before you commit the first collection, because mixing formats in one repository complicates diffs.

Git itself works with any Bruno edition, so branch creation, pull requests and review in your existing forge do not depend on a paid license. The Bruno app's own Git UI is different: according to Bruno's pricing page, Git push, branch operations, remote connections and merge conflict resolution inside the app are paid features, while the Open Source edition covers clone, initialize, diffs, pull and commit. Decide before rollout whether developers will use the command line or the app for these operations, and budget for paid seats only where the app's Git features are actually needed. Your CI job needs no Bruno license at all to run bru run.

Secrets must stay out of the repository. Keep base URLs and non-sensitive variables in committed environment files, and load tokens and passwords from the CI system's secret store as environment variables at run time. Review the repository for credentials embedded in collections exported from Postman, since those can be carried into Git during migration. Hoppscotch takes a different route: the hopp test command can run a collection from a file or against a self-hosted Hoppscotch instance, so the collections stay in that instance's PostgreSQL database instead of Git. Choose that path only if your team accepts that collection history and review live in Hoppscotch rather than in your forge, and confirm the current CLI options in the Hoppscotch CLI documentation.

Moving Newman and Postman CLI runs to a new runner

This sequence moves your collection runs out of Newman or the Postman CLI and into Bruno or Hoppscotch without a gap in test coverage. Each step ends with a check you can verify before the old job is switched off.

Inventory collections and pipeline jobs
Platform or DevOps engineers list every pipeline job that calls newman or the postman CLI, and for each job record the collection, environment files, data files, reporter flags and the secrets it reads. Include jobs in other repositories and scheduled jobs that run outside the main pipeline. The output is a table with one row per job that you can check off during the migration. Confirm the list with the team that owns each API, because jobs are often copied between projects and forgotten.
Export collections as Collection v2 or v2.1 JSON
The owners of each collection export it from Postman in Collection v2 or v2.1 JSON format, along with the environments that the pipeline uses. Store the exports in a temporary working folder, not in the repository, until they have been reviewed. The output is a set of JSON files whose names match the inventory. Check that each file opens and that the request count matches what Postman shows, since a partial export produces a silent coverage gap.
Import into Bruno or Hoppscotch
Import each export into Bruno, which writes the collection as a folder of files, or into a self-hosted Hoppscotch instance, which stores it in its database. Bruno's documented migration guide and Hoppscotch's importer both accept Postman collections and environments. The output is a working collection in the new client for each entry in the inventory. Run a few requests by hand against a non-production environment to confirm that authentication and base URLs resolve before you go further.
Review translated scripts and flagged packages
Read every pre-request and test script that the importer changed, and review every item the importer marked as unsupported. Bruno translates common Postman script APIs such as pm.test and pm.environment, but packages such as postman-collection and newman are flagged for manual work. Rewrite the flagged logic in the target client's script API, then rerun the requests. The output is a list of rewritten scripts with a note on each change, reviewed by someone other than the author.
Rebuild environment and secret injection for CI
Replace Postman environments and any vault references with variables that the CI runner injects from its own secret store, so no credentials are committed to Git. In Bruno, this usually means environment files that refer to variables and a secret source configured for the runner. In Hoppscotch, it means environment variables supplied to the CLI invocation. Confirm with your security team which secret store the runner may read and how access is logged. The output is a pipeline definition that runs without any value stored in the repository.
Set up the reporter and pipeline step
Add a pipeline step that runs bru run for Bruno or hopp test for Hoppscotch, and configure it to write a JUnit-style XML report that your CI system already reads. Confirm the exact flags and report options against the current CLI documentation for the version you install, and pin that version in the pipeline. Check that a failing request fails the job, and that the report appears in the test summary view. The output is a passing and a deliberately failing test run that both show up in your CI dashboard.
Run both pipelines in parallel
Keep the existing Newman or Postman CLI job running alongside the new job for a period agreed by the team, and compare the pass and fail results for each run. Investigate every difference, because a difference usually means a script was not translated correctly or a variable was not injected. Ask the team that owns each API to confirm that the results match their expectations. The output is a short comparison record per collection showing where results agreed and what was fixed.
Retire the Newman or Postman CLI job
Once the parallel results agree, remove the Newman or Postman CLI step from each pipeline, and revoke the Postman API key that the job used. Move the collection files into the Git repository beside the pipeline definition so changes are reviewed like code. Record the removal in the migration log. The output is a pipeline with no Postman dependency and a repository that holds the collections, with the previous job kept in history for reference.

Risks that slow a CI migration

Moving collection runs out of Newman or the Postman CLI touches scripts, reporters, tooling versions and the files that hold credentials. Each risk below is manageable if you check it before the pipeline cutover rather than after the first failed build.

Postman-specific packages

Scripts that require postman-collection or newman do not run unchanged. Bruno's importer translates common script APIs such as pm.test, pm.environment and pm.response, but it flags Postman-specific packages as unsupported. Before cutover, search every pre-request and test script for require( calls, list each flagged item, and rewrite those checks in plain JavaScript or move them into the pipeline itself.

Alpha status of the Hoppscotch CLI

The Hoppscotch CLI, installed from npm as @hoppscotch/cli, is described as alpha. Its command set and output may change between releases, so pin an exact version in your pipeline image and test upgrades in a branch before merging them. If your pipeline depends on a stable reporter contract for audit evidence, confirm with the Hoppscotch project how the alpha label affects that use before you commit to the CLI.

Node.js version requirements

Current Hoppscotch CLI versions need Node.js 22 or later, while older Newman setups on a shared runner may still pin an earlier runtime. Mixing the two in one job image causes failures that look like test failures. Check the Node.js version on every runner image that will execute hopp test, update the base image explicitly, and record the version in the pipeline definition so it does not drift with the runner.

Reporter format differences

Dashboards and merge gates often parse the report output of Newman or the Postman CLI, and the Bruno CLI and Hoppscotch CLI write their results in their own shapes. Hoppscotch writes JUnit XML, so a parser built for another format will fail silently. Run the old and new pipelines side by side for a few builds, compare the parsed results, and update the parser or the dashboard query before you remove the old job.

Secrets leaking into Git

Once collections live as files in a repository, any API key, token or password typed into a request or environment file is committed to version history. Postman kept those values in its cloud, so teams often never reviewed them. Keep secrets in the CI secret store or a vault, reference them through environment variables, add a pre-commit or pipeline scan for credential patterns, and review the existing Postman exports before the first commit.

How long, how much effort and what the team must do

Can our team move Newman pipelines to Bruno or Hoppscotch without outside help?

Yes, a team with CI experience can usually do the move in-house, because the collections are plain JSON or files in Git and both clients have documented importers. The work that is hard to estimate is in the scripts, not the tooling. Outside help is most useful when the collection count is high, the pre-request and test scripts depend on Postman-only packages, or the pipeline must be cut over without a gap in test coverage. Ask an implementation partner to put the scope in writing before work starts, so your team knows what is included.

What drives the effort of replacing Newman in CI?

Effort rises with a few measurable factors:

The number of collections and environments in use
How much logic sits in pm.test and other Postman script APIs, and whether scripts call postman-collection or newman directly
The number of pipelines and stages that call Newman, and any custom reporters they depend on
Whether test data, tokens or secrets are fetched at run time

Bruno translates common pm.* calls during import and flags unsupported packages, so the flagged list is the best early signal of how much rewriting remains.

Which costs are one-time and which recur when we switch to Bruno?

The migration itself is one-time: converting collections, rewriting scripts, updating pipeline steps and reviewing results. The Bruno Open Source edition is free, and its CLI runs bru run in CI. Recurring costs appear only if your team buys Bruno Pro at $6 per user per month or Ultimate at $11 per user per month, both billed annually, for features such as Git push and branch operations in the app or bulk Postman import. Git itself works outside the app on every edition. Confirm which features your team actually needs before counting seats.

What recurs if we run Hoppscotch Community Edition for CI tests?

Hoppscotch Community Edition has no license fee, but it is installed, administered and updated by your team. Recurring costs include the server that hosts the application, a PostgreSQL database set through DATABASE_URL, SMTP for email sign-in, and staff time for quarterly upgrades. The prerequisites page lists the build and hosting resource figures, so size the build host and the runtime host separately. The hopp test CLI is described as alpha, which is a factor to weigh against your CI reliability needs.

Can Newman stay in place while we move collections to Bruno or Hoppscotch?

Yes, the safest transition runs both tools in parallel for a period. Keep the existing Newman jobs as the gate, add bru run or hopp test as a non-blocking job that writes its own report, and compare results collection by collection. Switch the gate only when the new job matches the old one on the agreed collections. Keep the Postman export in a separate folder so you can roll back a pipeline without losing tests.

What should we ask for in a written scope before starting?

Ask for a scope that lists each deliverable, not only the effort. A useful scope names:

The collections and environments in scope, with a count and a list of any Postman-only packages
The target tool for each pipeline, and the reporter format the CI system must read
The Git repository layout, branch rules and who reviews changes to tests
How secrets are supplied to CI and kept out of files
The parallel-run period, cutover criteria and rollback steps
Training for your engineers and the handover documents

DeployOpen agrees scope, deliverables and timelines in writing before work starts, and quotes follow from that scope.

Does an ongoing support arrangement make sense after the cutover?

It depends on how often your collections and pipelines change. A team that adds endpoints every sprint may handle upkeep in-house, while a team with few changes may prefer occasional help with upgrades. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, which are separate from the fixed-scope migration. Ask for the retainer terms in writing and check which tasks it covers, such as Bruno or Hoppscotch version upgrades and CI pipeline changes.

Official sources for the runners and migration steps

Start with the vendor documentation for each runner before you change any pipeline file, because the flags, exit codes and report options are what your build depends on. For the Bruno side, the Bruno CLI docs cover how bru run is invoked, how environments are selected and which report formats are available. For the Hoppscotch side, the Hoppscotch CLI docs describe hopp test, its input sources and JUnit XML output. Check both against the exact version you pin in CI, since the Hoppscotch CLI is documented as alpha and both projects change quickly. Keep the Newman repository and the Postman CLI overview open as well, so your team can confirm which reporters and quality gate behavior you rely on today and what each one does not cover.

For the collection conversion itself, the Bruno migrating from Postman guide is the authoritative list of what imports cleanly and what gets flagged. Run a conversion on one representative collection first, then compare the test results against your last green Newman or Postman CLI run before you switch the pipeline. Ask your engineers to record which Postman script APIs and packages appear in the existing collections, because those are the items that need manual rework. Confirm the current import behavior in the version you deploy, since converter coverage changes between releases.

How DeployOpen scopes and delivers a CI test migration

DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure. For a move from Newman or the Postman CLI to the Bruno CLI or the Hoppscotch CLI, the work starts with a written scope that names your pipelines, collections and reporters before any changes are made.

How we scope

Inventory every pipeline step that calls Newman or the Postman CLI, including the collection and environment files each job uses.
Record which pm scripts, reporters and quality gates the current jobs depend on, so the target CLI covers the same checks.
Agree deliverables, timelines and the runner environment in writing before work begins, since most engagements are fixed-scope.

How we build

Convert Postman collections into Bruno folders or Hoppscotch collections, then review translated scripts and flag unsupported packages.
Rewrite pipeline jobs to call bru run or hopp test and confirm JUnit or other report output reaches your existing test dashboard.
Store collections and environments in Git beside the pipeline, with secrets kept in CI variables or a secrets manager rather than in files.

How we hand over

Deliver the updated pipeline definitions, collection repository layout and a short runbook for adding or changing requests.
Document the differences between the Newman and CLI outputs so reviewers know which assertions and reports have changed.
Walk your engineers through a parallel run that compares results from the old and new jobs before the old job is retired.

How we support

Ongoing support, upgrades and continuous testing are available as retainers once the migration is live.
Plan CLI version upgrades, such as Node.js requirements for the Hoppscotch CLI, as part of routine maintenance.
Confirm with your team which support terms, response expectations and upgrade cadence apply before the retainer is signed.

Replace Newman and the Postman CLI in CI pipelines