For years, running Postman collections outside the desktop app meant one tool: Newman. Then Postman released its own official command-line tool, the Postman CLI, and now there are two ways to do roughly the same thing. Both run collections without the GUI, both fit into CI/CD pipelines, and both execute the same test scripts. So why two tools, and which one belongs in your pipeline?
The short version: Newman is the open-source, account-free runner that has been the community standard since the early days. Postman CLI is the newer, account-linked tool that connects runs back to the Postman cloud and reports results there. The right choice depends on whether you want results stored in Postman’s platform or prefer a runner that needs nothing but a collection file. This article compares them honestly so you can decide.
What Newman is
Newman is Postman’s original command-line collection runner. It is open source, distributed as an npm package, and completely free. It runs collection files exported from Postman, executes every request and every pm.test assertion, and reports the outcome through its exit code.
Newman’s defining trait is independence. It does not require a Postman account, an API key, or a network connection to Postman’s servers. You hand it a JSON collection file and it runs. That makes it predictable and easy to reason about in locked-down environments.
npm install -g newman
newman run checkout-api.postman_collection.json \
--environment staging.postman_environment.json
Newman is also lightweight and extensible. It ships with CLI and JUnit reporters, and the community maintains additional reporters such as newman-reporter-htmlextra for rich HTML output. Because it is a Node.js package, you can also call it programmatically from a script. Our guide on the difference between Newman and Postman covers how it relates to the desktop app.
What Postman CLI is
Postman CLI is the official command-line tool Postman built and now recommends. It is a single binary you install with a script, not an npm package, and it is tied to your Postman account through an API key.
# install (example for macOS/Linux)
curl -o- "https://dl-cli.pstmn.io/install/osx_64.sh" | sh
# authenticate, then run
postman login --with-api-key YOUR_API_KEY
postman collection run checkout-api
The key difference is the cloud link. When you run a collection with Postman CLI, it can pull the collection directly from your Postman workspace by ID, and it pushes the run results back to the Postman platform, where they appear in the workspace history and dashboards. The big selling point is API governance and security checks: Postman CLI can run linting against your API definitions during a pipeline, surfacing schema and rule violations as part of the build.
So Postman CLI is less of a pure collection runner and more of a pipeline agent for the Postman platform. If your team works inside Postman’s cloud and wants run history and governance centralized there, that integration is the reason to choose it.
Side-by-side comparison
| Aspect | Postman CLI | Newman |
|---|---|---|
| Source | Closed source, official Postman tool | Open source |
| Install | Install script, single binary | npm package |
| Postman account | Required (API key login) | Not required |
| Collection source | Pulls from Postman cloud by ID, or local file | Local JSON file |
| Run results | Reported back to Postman platform | Terminal output and reporter files |
| API governance/linting | Built in | Not included |
| Reporters | Limited, results live in Postman | CLI, JUnit, plus community HTML reporters |
| Offline use | Limited, designed around the cloud | Fully offline once the file is local |
| Maturity | Newer | Long-established community standard |
| Cost | Free, but tied to a Postman plan’s limits | Free, no account |
The deciding axis is the Postman cloud. Postman CLI is built to feed results and governance into the Postman platform. Newman is built to run a file and report locally, with no dependency on Postman’s servers.
How they fit in CI/CD
Both tools work in any CI provider, including Jenkins, GitHub Actions, GitLab CI, and CircleCI. The mechanics differ.
With Newman, you commit the collection and environment JSON files to your repository, install Newman in the job, run it, and let the non-zero exit code fail the build on a test failure. Everything is self-contained in the repo and the pipeline. Our guides on automating API tests in CI/CD and API test automation with GitHub Actions show this pattern.
With Postman CLI, you store a Postman API key as a secret in the CI provider, authenticate, and run the collection by its ID. The collection is pulled from the Postman cloud rather than the repo, and results post back to the workspace. This keeps the source of truth in Postman, which some teams prefer and others find limiting.
A practical difference: Newman keeps tests versioned with your code, since the collection JSON sits in the repo. Postman CLI keeps tests versioned in Postman’s platform, since it pulls by ID. Decide which source of truth your team wants before choosing.
The governance angle
The single feature that most clearly separates the two tools is API governance. Postman CLI can run a postman api lint style check against an API definition stored in your Postman workspace, evaluating it against rules for naming, security, schema completeness, and consistency. When that check runs inside a pipeline, a definition that violates a rule fails the build before the change ever merges.
Newman has no equivalent. It runs collections and reports test results, and that is the boundary of its job. If your organization cares about enforcing API design standards automatically, that capability lives only in Postman CLI, and it is a real reason to choose it. If you do not enforce design rules in the pipeline, the feature is irrelevant and Newman’s simplicity wins.
This is worth being honest about because it reframes the comparison. Postman CLI is not just “Newman, but newer.” It is a different kind of tool: a pipeline agent for the Postman platform that happens to include a collection runner. Newman is, and only is, a collection runner. Once you see it that way, the choice becomes less about features and more about whether you want your testing tied to Postman’s platform at all.
Migration considerations
Teams already running Newman sometimes ask whether they should switch to Postman CLI. There is rarely a strong reason to. Newman is still maintained, still free, and still works in every CI provider. Switching means adding an API key as a CI secret, changing how collections are sourced, and accepting a dependency on Postman’s cloud. Unless you specifically want centralized run history or governance checks, the migration costs more than it returns.
Teams starting fresh face the more interesting choice. If the team is committed to Postman as its primary tool and pays for a plan, Postman CLI keeps everything in one ecosystem and is the natural pick. If the team wants flexibility, repo-versioned tests, and freedom from a single vendor’s cloud, Newman, or a non-Postman tool entirely, makes more sense. There is no universal right answer; there is only the answer that matches how your team already works.
Which one should you choose
Choose Newman if you want a runner with no account dependency, if you want tests versioned in your repository, if you need rich HTML reporting through community reporters, or if you run in restricted environments where calling out to Postman’s cloud is not allowed. Newman’s independence and maturity make it the safe default for most pipelines.
Choose Postman CLI if your team lives inside the Postman platform, if you want run history and dashboards centralized there, or if API governance and definition linting in the pipeline is valuable to you. Its tight cloud integration is a genuine advantage for Postman-centric teams.
If you are weighing this decision, it is worth asking whether you want to be tied to the Postman ecosystem at all. For other approaches, see our guide on running Postman collections in CI without Newman and our broader look at API testing without Postman.
A single-tool alternative: Apidog
Both Postman CLI and Newman assume you authored your tests in Postman. Apidog removes that split. You design APIs, debug requests, and build automated test scenarios with visual assertions in one application, then run those scenarios in CI/CD with the built-in command-line runner. There is no export step and no separate runner package, because the test definitions and the execution engine are the same product.
Apidog also folds in API design, mock servers, and performance testing, so a team can cover the full API lifecycle without stitching tools together. You can download Apidog and use its testing features for free, including the CLI runner for pipelines.
Frequently asked questions
Is Postman CLI replacing Newman?
Postman positions Postman CLI as its officially recommended command-line tool, but Newman is still maintained and widely used. Newman remains the better choice when you want an account-free, repo-versioned runner. Both will likely coexist for some time, so there is no urgent need to migrate.
Does Postman CLI require a Postman account?
Yes. Postman CLI authenticates with a Postman API key and is designed to connect runs back to your Postman workspace. Newman, by contrast, needs no account and runs purely from a local collection file.
Which tool gives better reports?
Newman has more flexible reporting through community reporters, especially newman-reporter-htmlextra for detailed HTML output and JUnit XML for CI dashboards. Postman CLI reports results into the Postman platform itself, which is convenient if your team works there but less flexible for standalone report files.
Can Postman CLI run a local collection file?
Postman CLI can run collections from local files, but it is built around pulling collections from the Postman cloud by ID and reporting results back. If you want a tool that treats a local JSON file as the source of truth with no cloud involvement, Newman fits that model more naturally.
Which is faster in CI?
For pure collection execution, the difference is small and depends on collection size and network conditions. Newman has a smaller footprint and no cloud round-trips. Postman CLI adds the overhead of authenticating and syncing results to the platform. For most pipelines, choose based on workflow fit rather than raw speed.