Self-hosted Postman alternative for air-gapped networks

Postman needs a signed-in cloud account for shared collections and environments, and its offline Scratch Pad was retired in 2023. Offline-only Bruno or a self-hosted Hoppscotch instance keep collections inside an isolated network.

Book a callTalk to us
On this page

Why teams in air-gapped networks need a self-hosted Postman alternative

Teams working in an isolated network need API collections, environments and embedded credentials to stay inside the boundary. Postman's collections and environments require a signed-in Postman account, and its offline Scratch Pad stopped working after September 15, 2023, so an isolated workstation cannot rely on Postman for everyday collection work. The short answer for most of these teams is one of two options: offline-only Bruno, which keeps collections as files on a local filesystem, or a self-hosted Hoppscotch Community Edition instance that runs on infrastructure you control and signs users in with local accounts.

The two options fit different working patterns. Bruno has no cloud sync and no account requirement, so each engineer's collection folder is a set of files that can be carried across an approved transfer path, reviewed and stored under your existing version control. Hoppscotch Community Edition runs as Docker containers backed by PostgreSQL through DATABASE_URL, so shared team workspaces live on a server inside the enclave. Its sign-in options are Email, GitHub, Google and Microsoft OAuth, so you must confirm which of these your isolated network can actually reach, and whether a local email path through SMTP is available for account messages.

Before choosing, ask your security and compliance owners where collection files and secrets may be stored, who may read them, and how each change is recorded. Confirm that every client binary, container image and package you bring across the boundary has been verified for integrity and authenticity, since this is the kind of vendor software control that NERC CIP-013-2 covers for supply chain procurement. Also check that your own operating system and package sources carry the tools you need, because Bruno and Hoppscotch both need updates to be moved in deliberately.

What an air-gapped boundary requires from an API client

An API client used inside an isolated network has to work without a cloud account, keep collections and credentials on hardware you control, and install from packages you can verify. The cards below set out these requirements and the checks to run before choosing Bruno or a self-hosted Hoppscotch instance.

No required outbound cloud account

Postman requires a signed-in Postman account for collections and environments, and its offline Scratch Pad stopped working after September 15, 2023. Bruno is offline-only with no cloud sync, so it needs no account to start. For Hoppscotch Community Edition, confirm that sign-in works with the authentication providers you can reach from inside the boundary, since OAuth providers such as GitHub or Google need outbound access unless you use email sign-in.

Collections kept on your infrastructure

Credentials embedded in requests, environments and test data should stay on storage you control. Bruno keeps each collection as files in a local folder that you can place on an encrypted volume. A self-hosted Hoppscotch instance keeps team workspaces in your own PostgreSQL database. Write down where each file or table lives, who can read it, and how backups are protected.

Offline installation of packages and images

A self-hosted Hoppscotch instance is built from Docker images and needs a build step with 4 CPU cores and 4 GB of RAM, followed by hosting on as little as 1 CPU core and 2 GB of RAM. Bruno ships as a desktop binary for macOS, Windows and Linux. Plan how each image, binary and Node.js runtime for the CLI reaches the enclave, and confirm that any build step can run without pulling from public registries.

Verified transfer of every package

Every installer, container image, npm package and collection file that crosses the boundary should have a recorded checksum and origin. NERC CIP-013-2 is one example of a supply chain control that asks for verification of software integrity and authenticity. Illustratively, a team in a regulated environment might hash each release artifact on the outside network and compare the hash after transfer. Confirm which controls apply to your own program with your compliance lead.

Remote access controls for electric utilities

If your environment is an electric utility or contains BES Cyber Systems, NERC CIP-005-7 governs Interactive Remote Access through an Intermediate System with encryption and multi-factor authentication. An API client on an operator workstation rarely changes that boundary, but any shared Hoppscotch server reached from outside it would. Confirm applicability with your compliance team before relying on this control.

Offline-capable CI test runs

Collections often run in pipelines that also sit inside the boundary. Bruno provides bru run with test reports, and the Hoppscotch CLI runs hopp test with JUnit XML output. Confirm that the runner, its dependencies and any test target can operate without internet access, and that test reports are stored in the same controlled location as the collections they cover.

Where Postman does not fit an isolated network

Postman's lightweight client keeps data on the local machine, but it does not work as an offline tool. Postman states that environments and collections require signing in to a Postman account, so a workstation on a network with no outbound path cannot use those features as designed. The earlier offline Scratch Pad mode stopped working after September 15, 2023, which removes the one mode that once allowed fully disconnected use. Teams with isolated networks should treat Postman as a cloud-account product for planning purposes, not as a tool that can run inside the boundary.

Postman's EU Data Residency instance in Frankfurt does not solve this problem. It is offered only to Enterprise customers, and it is still a hosted service, so it does not help a network that cannot reach any external endpoint. Ask Postman in writing which deployment options apply to your contract, whether any option runs without sign-in or outbound connectivity, and which features still need a Postman account. Record the answers as part of the procurement file, since the plan structure changed in March 2026 and product terms may differ between agreements.

For an isolated network, the practical check is whether the client can store collections and environments as local files or on a server inside the boundary, and whether it can sign in with accounts the organization manages. Bruno keeps collections as files in a local folder and has no cloud sync, so it can be used with no account. A self-hosted Hoppscotch Community Edition instance keeps data in PostgreSQL on your own infrastructure and signs users in through the providers you configure. Confirm the sign-in path and every outbound dependency with your own security team before choosing either option.

Which open-source clients meet an offline requirement

This table compares offline-only Bruno with a self-hosted Hoppscotch Community Edition for isolated networks, covering where collections live, what runs on your servers, and which features sit behind paid editions. Read each row as a question to confirm inside your own enclave before choosing a client.

RequirementBruno (offline-only)Self-hosted Hoppscotch Community Edition
LicenseMIT, with paid Pro and Ultimate editionsMIT, with a paid Enterprise Edition
Where collections livePlain files in a local folder, shared through Git or any version controlTeam workspaces in a PostgreSQL database set through DATABASE_URL
Cloud sync or outside callsNone by design, per Bruno's README; confirm no telemetry or update checks are blocked by policyNone required for core use; confirm sign-in and SMTP endpoints resolve inside the network
Deployment footprintDesktop binary for macOS, Windows and Linux, installed per workstationDocker containers on your servers, with a build step needing 4 CPU cores and 4 GB RAM
Sign-inNo account needed for collectionsEmail, GitHub, Google or Microsoft OAuth configured by you; email needs SMTP
Git operations in the appClone, pull, commit and diffs in Open Source; push, branches and merge conflicts need a paid editionNot applicable; team state sits in the database rather than Git
Postman importCollection v2 and v2.1 import; bulk data dump import needs a paid editionPostman collections and environments import; self-hosted import size limit is 50 MB
SAML SSO and SCIMPaid editions only, managed through a license portalEnterprise Edition only, with SAML, OIDC, SCIM and audit logs
Confirm in the isolated environmentInstaller source, package mirror, and Git server reachable from workstationsContainer registry mirror, PostgreSQL, SMTP relay, and OAuth providers reachable from the network

Choosing between Bruno and self-hosted Hoppscotch

If one engineer or a small team can share collections through a repository, Bruno usually needs the least infrastructure. Bruno is offline-only and stores collections as files in a local folder, so there is no server, database or sign-in to run inside the enclave. Collaboration happens through Git or any other version control system that the network already hosts.

  • Network footprint: Bruno installs as a desktop binary for macOS, Windows and Linux, with no service to expose or patch.
  • Review and versioning: Requests, environments and tests are plain files, so changes go through normal diffs and merge requests on your internal Git server.
  • Git UI limits: Clone, pull, commit and diffs are in the open-source edition, while push, branch operations and merge conflict resolution in the app's Git UI are paid features. Git itself still works outside the app.
  • CI runs: The bru run command runs collections from the repository and produces test reports for pipeline use.
  • Licensing: Bruno is MIT licensed, and open-source users need no license management.

Confirm with your Git platform team whether the enclave allows local-only Git workflows or requires merges through a central server, and decide whether your team will pay for a Bruno edition to get the in-app Git operations.

How to deploy either option inside an isolated network

This sequence moves Bruno or a self-hosted Hoppscotch instance across an isolation boundary, installs it from verified artifacts, and ends with Postman collections and OpenAPI specs stored in an internal Git repository that your team controls.

  1. Inventory every artifact before the transfer

    The platform team lists what the isolated network must receive: Bruno desktop binaries or the package sources used for them, Hoppscotch Community Edition container images and their build inputs, PostgreSQL, Node.js 22 or later if the Hoppscotch CLI will run tests, and the Postman collection and OpenAPI files to import. Record the exact versions in a manifest held by the security team. The step is done when the manifest is approved and each item has a named owner and a source it was downloaded from.

  2. Transfer and verify artifacts across the boundary

    Staff download the artifacts on a connected machine, compute checksums for each file, and move them through your approved transfer process into the isolated zone. Internal mirrors for container images and packages are preferred over ad hoc file copies. Inside the boundary, the team recomputes the checksums and compares them with the manifest. The step is done when every checksum matches and the mismatches, if any, are logged and resolved before installation. Ask your security team how they want supply chain verification evidenced, since NERC CIP-013-2 is one example of a control that requires it in energy environments.

  3. Install Hoppscotch with Docker and a database URL

    Operators build or load the Hoppscotch Community Edition images and start the containers on hosts that meet the documented prerequisites: 4 CPU cores and 4 GB of RAM for the build image, and as little as 1 CPU core and 2 GB of RAM to host the output. Point the backend at PostgreSQL with the DATABASE_URL setting. Bruno needs no server, so this step applies only to the Hoppscotch path. The step is done when the containers start and the admin interface loads from an internal address without any outbound connection.

  4. Configure local sign-in and an internal mail relay

    The administrator enables an authentication method that works inside the network. The Community Edition offers Email, GitHub, Google and Microsoft OAuth providers, so confirm which of these can run without reaching external identity services, and use the Email option only with an identity source your team controls. Configure SMTP to an internal relay so invitations and sign-in emails route inside the boundary. The step is done when a test user can sign in and receive email through the internal relay only. Confirm with your identity team whether the Community Edition meets your sign-in requirements or whether a different approach is needed.

  5. Import Postman collections and OpenAPI specifications

    Export each collection and environment from Postman as Collection v2 or v2.1 JSON, then import them into Bruno or into Hoppscotch. Hoppscotch's importer also accepts Postman collections and environments, and both tools accept OpenAPI specifications. Bruno flags Postman-specific packages such as postman-collection and newman as unsupported, so review those requests after import. The step is done when each imported collection runs a representative request and the team has a list of scripts that still need rewriting.

  6. Commit collections to an internal Git server

    Bruno keeps collections as files in a local folder, so the team initializes a repository on the internal Git server and commits the collection folders with reviewed history. Hoppscotch users export or script their collections into the same repository so that both paths share one source of truth. Keep credentials out of committed files and load them from environment files or your secret store. The step is done when a second engineer clones the repository inside the isolated network and runs a request successfully. Confirm with your Git administrator whether the server's access controls and backups meet your retention rules.

  7. Record the deployment and the update path

    The team documents the artifact manifest, checksums, versions, configuration, database location and the procedure for importing future releases from newer verified media or internal mirrors. For Hoppscotch, the Community Edition is installed, administered and updated by your team, so assign an owner for quarterly upgrades. For Bruno, assign an owner for version checks and approved package updates. The step is done when the runbook is stored with the Git repository and an owner has signed the update schedule.

Evidence to keep for an assessor or security reviewer

An assessor reviewing an isolated Postman replacement will want to see what was installed, how it crossed the boundary, how it is configured, and how collections changed over time. The cards below list the records that connect those answers. DeployOpen prepares this evidence, but independent auditors and certification bodies issue any audit report or certification.

Installed version and checksum record

Record the exact client or server version, the source it came from, and a checksum for every artifact installed on the isolated network, including the Bruno desktop binary or the Hoppscotch Community Edition container images. Compare each checksum against the value published by the project before installation. Keep the record with the change ticket so a reviewer can match what runs today to what was approved.

Transfer and verification log

Log each package, image and rule set carried across the boundary, who approved the transfer, the scan or hash check performed on the media, and when it was imported. Treat this as the core supply chain record for the isolated network. Confirm with your security team which verification steps they require before anything enters the enclave.

Sign-in and SMTP configuration

For self-hosted Hoppscotch, keep the exported settings for the sign-in providers the administrator enabled, the email (SMTP) relay and the access rules for workspaces. Show which accounts can sign in, how local credentials are managed, and that no external identity provider is reached from the isolated network. Note any setting that differs from the documented defaults and why.

Collection and storage inventory

List every collection, environment and workspace, the folder or database where each one lives, and the owner responsible for it. For Bruno, this is the local folder tree. For Hoppscotch, it is the workspaces held in the self-hosted PostgreSQL database. Mark any collection that holds credentials so reviewers can confirm those secrets are stored under the controls you describe.

Git history of collection changes

Keep collection folders in Git on the isolated network and retain the commit history, reviewer approvals and branch protection settings. This shows who changed a request, a test or a variable, and when. Git operations such as push and merge run outside the Bruno app on any edition, so confirm which tooling your team uses to record approvals.

Excluded Postman-specific packages

Bruno flags Postman-specific packages such as postman-collection and newman as unsupported during import. Record each flagged package, the script or test it appeared in, the replacement chosen, and the person who accepted the change. This gives a reviewer a clear trail showing that no unsupported dependency was silently carried into the new environment.

Questions teams ask before moving an air-gapped API client

What does the total cost look like by component?

The Bruno Open Source edition and the Hoppscotch Community Edition both carry a $0 license, so the recurring cost sits in the parts you run yourself. Bruno's pricing page lists Pro at $6 and Ultimate at $11 per user per month, billed annually, and Hoppscotch's pricing page lists Enterprise at $11 per user per month, billed annually. Those seat fees are optional. For Hoppscotch Community Edition, the other components are a server sized for the build and hosting tasks, a PostgreSQL database, SMTP for email sign-in, and staff time for installs, upgrades and backups. Ask your team to price each of these in its own line, and to separate one-time setup from recurring operations before comparing against your current Postman seats.

How long does the move take, and what drives it?

The duration depends mainly on the number of collections, how many scripts use Postman-specific APIs, and how many people need access on day one. Bruno imports Collection v2 and v2.1 JSON files directly, so a small set of collections is usually a short exercise, while a large estate needs review of translated scripts and of any packages Bruno flags as unsupported. Hoppscotch adds server installation, OAuth or local sign-in setup, and a import limit of 50 MB on self-hosted editions. No duration figure is supplied for this work, so ask any provider, including your own team, to base the estimate on a written inventory of collections, scripts and users.

What does the team need to supply before the work starts?

Start with an inventory of every collection, environment and script, plus the Postman export files. Next, list who uses each workspace and which roles they need. For a self-hosted Hoppscotch instance, you also need a host inside your network, a PostgreSQL database set through DATABASE_URL, the OAuth or email sign-in method your policy allows, and SMTP settings. For Bruno, you need a Git repository inside your network, a decision on where secret values live, and a list of any Postman packages such as newman or postman-collection that the scripts depend on. Confirm each item with your own security and platform owners before the scope is agreed.

Can our own engineers do this without outside help?

Yes, a team with API and Git experience can move simple collections in-house, especially with Bruno, which runs as a desktop binary and imports Postman files without a server. Bruno's pricing page and documentation describe the Open Source edition as free, and Hoppscotch Community Edition is free to use under the MIT License. The harder parts are script rewriting, air-gapped package delivery, Hoppscotch installation and upgrades, and documenting controls for an assessment. If those skills are thin, a provider can take on part of the work under a written scope while your team keeps ownership of the collections.

Can Bruno replace the scripts we wrote in Postman?

Bruno translates common Postman script APIs during import, including pm.test, pm.environment, pm.globals, pm.collectionVariables and pm.response. It flags Postman-specific packages such as postman-collection and newman as unsupported, so those scripts need manual rewriting. Plan a review of every test script, because translation covers the common APIs but not every custom helper. Run the translated tests against a known response before you retire the Postman copy, and keep the reviewed versions in Git.

Is the Hoppscotch CLI ready for production CI?

Treat it as an early-stage tool until your own tests prove it works in your pipeline. Hoppscotch describes its CLI, installed from npm as @hoppscotch/cli, as alpha. It runs collection tests with hopp test from a file or from a self-hosted instance and can write JUnit XML reports, and current versions need Node.js 22 or later. If your pipelines depend on stable reporting, run the same collections through Bruno's bru run, which provides test reports, and compare the results before you choose a runner.

Can DeployOpen run the migration under a fixed written scope?

Yes. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, including air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, so a quote follows from the written scope. Ongoing support and upgrades are available as retainers. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications, which independent auditors and certification bodies handle.

What a fixed-scope air-gapped rollout covers

A fixed-scope rollout inside an isolated network starts with planning the artifact transfer, because every container image, npm package, Bruno binary and collection file that crosses the boundary must be listed, verified and recorded. DeployOpen plans that transfer with the client, then installs and hardens the chosen tool: Hoppscotch Community Edition on the client's own Docker hosts and PostgreSQL database, with OAuth providers and SMTP configured to match the local identity setup, or Bruno on managed workstations with its collection folders placed in internal Git repositories. Migration of existing Postman collections and environments follows, using the importer or Bruno's Postman converter, with a review of script translations and of any packages flagged as unsupported. Scope also covers the CI runs (bru run or hopp test), the procedure documents, and the evidence an internal assessor or compliance team will ask for. Retainers for upgrades and future offline updates are available as a separate agreement.

Before any work begins, the scope, deliverables and timelines are agreed in writing. Ask the implementer to name each artifact in the transfer list, the owner of each approval step, and what happens if a Hoppscotch release or Bruno version needs to cross the boundary during the engagement. The written scope should also state which network zone hosts the Hoppscotch instance, who holds administrator rights, and where secrets referenced in environments are kept. DeployOpen does not publish a price list. A quote follows from the written scope, so the reader should compare quotes against the same list of components: installation, hardening, migration, CI configuration, documentation and any retainer. Confirm also whether the engagement needs an independent assessor's involvement, since DeployOpen prepares controls and evidence but does not issue audit reports or certifications.

How DeployOpen deploys API clients under air-gap constraints

DeployOpen plans, installs and hands over self-hosted API clients inside your own isolated network, whether that is Bruno with Git-managed collection folders or a self-hosted Hoppscotch instance with local sign-in. Each step is written down in a fixed scope before work starts, so you know what is delivered and what you must confirm in your own environment.

How we scope

  • Written scope lists which clients, editions and collections are in and out of the engagement.
  • We map where collections, environments and embedded credentials will live inside your network.
  • We confirm which Postman collections and scripts must be imported and which packages need rewriting.

How we build

  • We install Bruno from the release artifacts you approve, verified against checksums you record.
  • For Hoppscotch, we deploy the Community Edition containers with PostgreSQL on your own infrastructure.
  • We configure local sign-in and test that no outbound calls are needed for normal collection work.

How we hand over

  • You receive installation records, configuration notes and the collection folder structure stored in Git.
  • We document the offline update path, including how new client versions are transferred across the boundary.
  • We walk your team through importing, running tests with the command line tools and storing secrets outside Git.

How we support

  • Ongoing support, upgrades and continuous testing are available as a retainer agreed in writing.
  • Supported upgrades are scoped as separate written work, so changes to your isolated environment stay controlled.
  • Quotes follow from the written scope, and we ask you to confirm your network boundary before pricing.

Related

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.
Book a callhello@deployopen.com