Where Postman Vault secrets go once Postman is gone
If a renewal, a plan change or a residency rule is forcing you off Postman, the first question is where your API keys and tokens will live afterward. There is no single open-source drop-in for Postman Vault. The practical options are three: Bruno's local collection files, with secrets pulled from an external secret manager at run time; a self-hosted Hoppscotch environment store on infrastructure you control; and a written rule that keeps credentials out of Git and out of exported collection files altogether. Postman's Local Vault is included on every plan, while Shared Vault is available on Solo, Team and Enterprise but not on Free, so a Free-plan team has never had a shared vault to migrate. Confirm which vault features your current plan actually uses before you design the replacement.
Both open-source options keep data on infrastructure you control. Bruno stores each collection as files in a folder on the user's filesystem, and its README states that it is offline-only with no plans for cloud sync, so credentials stay wherever that folder and its environment files are kept. Hoppscotch Community Edition stores team workspaces and environments in your own PostgreSQL database, reached through DATABASE_URL, which makes database access controls and backups the main protection for stored values. Ask your team which secrets were held in Postman's vault, which were typed into plain environment variables, and which were embedded in request bodies, because each category needs a different home. Reference the Bruno documentation index when you check which secret manager integrations your Bruno version supports.
Postman Vault capabilities mapped to open-source options
This table maps Postman's Local Vault and Shared Vault, environment variables, secret masking, access control and audit to Bruno, self-hosted Hoppscotch and an external secret manager such as HashiCorp Vault or OpenBao. Where the current documentation does not confirm a capability, the cell says so, and you should verify it before planning a migration. The main takeaway is that open-source clients keep collections on your systems but do not replace a dedicated secrets manager.
| Capability | Bruno | Hoppscotch (Community and Enterprise) | HashiCorp Vault or OpenBao |
|---|---|---|---|
| Local Vault (Postman: all plans) | Collections are plain files, so keep secrets out of committed folders. Confirm the current secret handling in Bruno's docs. | Community Edition stores environments in your PostgreSQL database on your server. Confirm which fields are treated as secret. | Not a client vault. Stores and serves secrets to approved clients through its API. |
| Shared Vault (Postman: Solo, Team, Enterprise) | No cloud shared vault. Teams share files through Git, and Git push needs a paid Bruno edition in the app. | Team workspaces live on your server, so shared secrets stay on your infrastructure. Confirm per-variable visibility. | Central store with policies and tokens. Your team must design access and distribution for client tools. |
| Environment variables and secret references | Environment files hold variables. Confirm whether Bruno resolves references from external managers in your version. | Environment variables sit in PostgreSQL set through DATABASE_URL. Protect the database and its backups. | Serves static and dynamic secrets. Client integration with collections must be built or confirmed. |
| Secret masking in UI, exports and logs | Confirm masking in the app, exports and CLI reports for your Bruno version. | Confirm masking in the UI and in exported JSON or YAML before sharing files. | Masking is handled by clients and CI logs, not by Vault itself. Test your pipelines. |
| Access control | Controlled by file permissions and Git repository access. Confirm any in-app roles in the paid editions. | Community sign-in uses Email, GitHub, Google or Microsoft OAuth. Enterprise adds SAML SSO, SCIM and user groups. | Policies and tokens control access. Enterprise adds namespaces and Sentinel policy as code, under a license. |
| Audit trail | Git history records file changes, not who ran a request. Confirm any run logging with the CLI. | Confirm audit coverage in Community Edition. Activity and audit logs are documented for Enterprise. | Audit devices record requests when enabled. Configure and test one before relying on it. |
| Moving existing Postman secrets | Postman environments import, and pm.environment scripts translate. Check that secret values carry over. | The Postman importer accepts environments. Review secret values before import and remove them from shared files. | The OpenBao migration guide was tested only against Vault 1.14.1 Community, not Enterprise. |
Which secret store fits which team
Each option keeps API keys and tokens somewhere different, and that location decides who can read them, how they reach CI, and what you must operate yourself. Use the cards below to match your team's size, identity setup and existing secret infrastructure before you move any collection.
Bruno with a secret manager integration
Bruno is offline-only and keeps collections as files in a folder, so secrets belong in a secret manager that Bruno reads at run time rather than in the collection itself. Bruno's documentation describes integrations for HashiCorp Vault, AWS, Azure and Google Cloud. This fits teams that already run one of these and want credentials out of Git. The trade-off is that each developer needs access to the secret store. Confirm the exact integration list and version in Bruno's documentation before you rely on one.
Bruno with local environment files
Without a secret manager, Bruno environment values stay on each user's device, and only non-secret variables go into the Git-tracked collection. This suits small teams with few credentials and no cloud secret store. The risk is drift: each person maintains their own copy of tokens, and rotation depends on individuals. Add a rule that nothing sensitive is committed, and check that your Git ignore settings cover environment files before the first commit.
Hoppscotch Community Edition environments
A self-hosted Hoppscotch Community Edition stores team workspaces and environments in your PostgreSQL database, set through DATABASE_URL, so secrets stay on servers you run. This fits teams that need shared environments without a cloud service. You become responsible for database access controls, backups and encryption at rest, and for the sign-in providers you configure. Confirm with Hoppscotch's self-hosting documentation how environment values are protected in the database.
Hoppscotch Enterprise for SSO and audit logs
Hoppscotch Enterprise Edition adds SAML-based SSO, OpenID Connect, SCIM provisioning, user groups and activity and audit logs, and requires a license key. This fits regulated teams that must tie API access to central identity and show who changed a shared environment. The cost is a paid license on top of your hosting, and the audit logs record activity rather than replacing a secret manager. Ask the vendor which secret types are covered and how logs are retained.
Vault-backed secrets for CI runs
When collections run in CI with bru run, the pipeline needs credentials without a developer's laptop. Pulling values from a secret manager at run time keeps tokens out of pipeline definitions and the repository. Scope each pipeline identity to the one API it tests, and rotate those credentials on a schedule you document. Confirm how your CI system authenticates to the chosen store before you wire it up.
Ownership of the secret store
Whichever store you choose, someone must own its availability, access reviews and key rotation. A self-managed Vault deployment has its own storage, unsealing and upgrade work, and HashiCorp's Vault documentation lists separate commercial editions. Decide who runs that service before the API client team depends on it, and ask any implementation partner to write that ownership into the scope.
How secrets are stored in each client
A single developer using Bruno keeps each collection as a folder on the local filesystem. Environment files and any credentials you type into them are plain files on that machine, so the protection is the operating system account, disk encryption and the laptop's own access controls. There is no Bruno account to sign in to and no cloud copy to revoke, which keeps the secret store small and easy to reason about.
- Location: environment values sit in files inside the collection folder on the laptop.
- Readers: anyone with access to that user account or a copy of the folder can read the values.
- Departure: the person keeps a local copy unless the team deletes it, so remove the folder and rotate the credentials they could read.
- Backups: operating system backups and sync tools may copy the folder, so check what they include.
- Hosted Hoppscotch: a single developer on a self-hosted instance stores environments in the server database instead, so the server administrator becomes the relevant reader.
Confirm with your security team whether laptop disk encryption and screen lock policies meet your internal standard before any production token goes into a local environment.
A Git-based team using Bruno stores the collection in a repository, and anything written into the collection's files is versioned with it. This is where accidental leaks happen most often, because a committed token stays in history even after it is deleted from the latest commit. The safer pattern keeps only variable names in the repository and resolves the values from each person's local environment or from a secret manager at run time.
- Location: the repository holds collection files, and values are either in the repo or referenced from outside it.
- Readers: everyone with repository read access, plus every clone and fork that already exists.
- Departure: removing a person from the repository does not remove their clones, so rotate any value they could have read.
- Rules: add local environment files and any file holding real values to
.gitignore, and scan commits with a secret detection tool. - Secret managers: Bruno's integrations for HashiCorp Vault, AWS, Azure and Google Cloud let collections resolve values at run time, which keeps the repository free of them.
Before you rely on a .gitignore rule, check the git history of the existing repository for committed values and confirm that your hosting platform's secret scanning covers the files your team uses.
A team running a self-hosted Hoppscotch Community Edition instance keeps team workspaces, collections and environments in the PostgreSQL database set through DATABASE_URL. Values in shared environments are therefore visible to whoever the workspace grants access to, and to anyone with database or backup access. The team controls the server, which means access decisions, encryption at rest and backup retention are the team's own responsibility.
- Location: environments and collections sit in the PostgreSQL database on infrastructure you operate.
- Readers: workspace members with access, plus database administrators and anyone who can read database backups.
- Sign-in: users sign in through the Email, GitHub, Google or Microsoft OAuth providers you configure, so removing a user at the identity provider stops their sign-in.
- Departure: removing the user from the workspace stops new access, but values they saw in the past must still be rotated.
- Enterprise features: SCIM provisioning and audit logs are part of the paid Hoppscotch Enterprise Edition, so confirm whether you need them before you choose the edition.
Ask the people who run your database and backups who can read them, and confirm whether backups are encrypted before any production credential is stored in a shared environment.
Rules for keeping API secrets out of Git
A collection folder committed to Git can carry credentials, because Bruno stores requests as plain files and any header, auth block, or environment value written into those files travels with every clone and every branch. Once a token lands in history, deleting it from the latest commit does not remove it from earlier commits, so the safe pattern is to keep secret values out of the collection from the start. Before the first commit, decide which files are shared and which are local, and write those rules down for the team.
The practical rules are short. Keep secret values in environment files that your ignore rules exclude from version control, and commit only the non-secret variable names and sample values. Reference secrets by name inside requests, so a request reads a variable such as a token placeholder rather than a literal value. At run time, load the value from a secret manager, such as HashiCorp Vault or a cloud secret service, through the secret manager integrations Bruno supports, or supply it from the environment of your CI job. Bruno's paid Git UI features do not change any of this. Git itself works outside the app on every edition, so the same ignore rules apply whether a developer uses Open Source or a paid edition, or the command line.
Test your own ignore rules before the first commit. Create a dummy secret in a local environment file, run git status and git check-ignore against it, and confirm the file does not appear as a staged change. Repeat the check in CI, because a secret file that is ignored on one laptop can still be added by a teammate who uses a different path or a forced add. Confirm with your security team how a leaked value is rotated and reported, and check the Bruno documentation for the current behavior of any secret manager integration in the version your team installs.
Moving Postman Vault values into your chosen store
This sequence moves the API keys and tokens that Postman held in its vaults into a store you control, and leaves collection files free of live credentials. The result is a Bruno or Hoppscotch workspace that runs in CI with no secret values stored in Git.
Inventory every secret Postman holds
Before exporting anything, list each variable in Postman's Local Vault and Shared Vault, along with the environments and collections that reference it. Mark which values are live credentials, such as API keys, bearer tokens, client secrets and passwords, and which are plain configuration like base URLs. Have the owner of each upstream service confirm which credentials are still in use. You are done when every secret has a named owner and a target location in your chosen store.
Export collections and environments from Postman
Export each collection as Collection v2 or v2.1 JSON and export each environment separately, following the export steps in the sibling Postman data export page. Confirm the export limits and download windows in that page and in Postman's own documentation before you start, since team admins may need to request a bulk export. You are done when every collection and environment you inventoried is saved in a secure, access-limited folder outside Git.
Import into Bruno or Hoppscotch
Import the Postman JSON into Bruno using its Postman importer, or into a self-hosted Hoppscotch instance using its Postman importer, which accepts collections and environments. Bruno flags Postman-specific packages such as newman as unsupported, so review those flags in the import output. You are done when each collection opens with its requests, folders and environment names intact and nothing has been silently dropped.
Separate secret values from collection files
Open each imported environment and replace every literal secret with a variable reference, so that request files contain only names such as an API key placeholder. In Bruno, keep the environment files free of values and point them at your secret manager integration for HashiCorp Vault, AWS, Azure or Google Cloud. In Hoppscotch, keep secret values in the environment stored in the instance database and not in exported files. Run a search across the collection folder for known key prefixes and high-entropy strings. You are done when the search returns no live values.
Load secret values into the chosen store
Write each secret into its target store, such as a HashiCorp Vault path, a cloud secret service, or the Hoppscotch environment on your instance, with access limited to the people and CI identities that need it. Grant read access by role rather than by individual where your store supports it. Record which path or key holds each secret in your internal runbook, without the values themselves. You are done when a test user can resolve every variable from the store and no one else can.
Rotate every exported credential
Treat every credential that appeared in a Postman export as exposed, because the exported JSON and any copies of it may have left your control. Issue new keys or tokens at each upstream service, update the store with the new values, and revoke the old ones. Confirm with each service owner that the old credential no longer authenticates. You are done when the revocation is confirmed in writing for every credential on your inventory list.
Verify runs in CI with bru run or hopp test
Run each collection from the command line with the Bruno CLI using bru run, or with the Hoppscotch CLI using hopp test, pointing it at the store-backed environment. Generate the JUnit-style report each tool supports and confirm the pipeline reads the secrets at runtime without printing them to logs. Check that the Node.js version on your runners meets the Hoppscotch CLI requirement. You are done when a clean CI run passes against the new credentials and the logs contain no secret values.
Running alongside an existing secret manager
Many teams already run HashiCorp Vault or a cloud secret service, so the simplest path is to keep that system as the source of truth and have API clients fetch credentials from it at run time. The cards below cover the integration choices, the licensing questions that decide which Vault build you can run, and the checks to make before you commit.
Fetch secrets from Vault at run time
Bruno's secret manager integrations let a request read its credentials from HashiCorp Vault, so the collection file holds only a reference and never the token itself. This keeps one audited copy of each API key in Vault and removes the need to copy it into a desktop client or a shared export. Confirm which authentication method your Vault cluster exposes to developer laptops and CI runners, and whether those clients can reach the Vault address from outside the corporate network.
Check the Vault license before choosing
Vault moved to the Business Source License 1.1 for releases from 1.15.0 onward, and the license names IBM as licensor. Community Edition binaries are free to run, but features such as performance replication, HSM support, namespaces and Sentinel policy as code need a Vault Enterprise license applied to the cluster. Ask your Vault owner which edition is deployed, and read the license terms with legal before you rely on a feature in a collection workflow.
Weigh OpenBao as a fork
OpenBao is a community fork of Vault under MPL-2.0 that is managed under the Linux Foundation's OpenSSF. Its migration guide was tested only against Vault 1.14.1 community edition, not Vault Enterprise, so an Enterprise cluster or a newer Community release may need its own validation. Before choosing a fork, confirm the exact Vault version in your environment, the features your API clients depend on, and whether your team can test the migration on a non-production cluster.
Use cloud secret services where they already run
If your APIs sit in AWS, Azure or Google Cloud, the platform's secret service may already hold the credentials that clients need. Bruno documents integrations for each of these services, so a request can resolve a secret from the provider's store under the caller's cloud identity. Confirm which identities your engineers and CI jobs can assume, how rotation is handled, and whether the cloud audit logs capture each secret read.
Confirm the current Vault release
Vault releases move quickly, and the version you test against should match the one your platform team runs. The current HashiCorp release at the time of writing is Vault 2.2.0, released on October 15, 2026, so check the release list before you pin a version in your runbook. Record the version, the edition and the storage backend in your decision note, since integrated storage (Raft) is the officially supported backend for most deployments.
Questions buyers ask before replacing Postman Vault
Can Bruno read secrets from HashiCorp Vault and cloud secret managers?
Yes, Bruno includes secret manager integrations for HashiCorp Vault, AWS, Azure and Google Cloud, so requests can pull values at run time instead of storing them in the collection. Confirm the exact integration set, authentication methods and which edition supports each one against Bruno's current documentation and your own environment before you commit to a design. Keep in mind that the Bruno client is offline-only, so the secret source you choose becomes the single place where rotation happens for everyone who runs the collection.
What does Hoppscotch Community Edition need to store secrets safely?
Hoppscotch Community Edition keeps workspace data, including environments, in a PostgreSQL database that you point to with DATABASE_URL, on infrastructure you control. Secrets are therefore only as protected as that database, the backend host and the network path to it, so plan for access control, encrypted backups and TLS in front of the instance. Users sign in through the Email, GitHub, Google or Microsoft OAuth providers you configure, and the Community Edition needs SMTP settings if you use email sign-in. Confirm how your chosen environment variables are stored and rotated on your own hosts before you load production credentials.
How much effort does a Postman Vault migration take, and what drives it?
Effort depends mainly on how many collections, environments and scripts you have, how many secrets are embedded in them, and how many people share them. The Bruno import path accepts Postman Collection v2 or v2.1 JSON, and Bruno translates common pm.environment and pm.test calls while flagging unsupported packages such as newman, so script count and custom code are the main variables. Secret handling adds work: each credential has to be moved into a vault, referenced by name, and removed from exported files. Ask any provider for a timeline based on an inventory of your collections, scripts and secrets rather than on a headline figure.
Can our team move Postman secrets to Bruno or Hoppscotch without outside help?
A small team with one or two collections can often do the move itself, because both clients import Postman exports and the secret changes are mechanical. The work becomes harder when you have many shared environments, CI runs that read Postman variables, or a secrets manager that must be integrated and access-controlled. Be realistic about ownership: someone must decide where each secret lives, who may read it, and how it rotates after cutover. Your own platform team can do this in-house, and a fixed-scope engagement can cover the parts you do not want to carry alone.
How do we keep API keys and tokens out of Git after the move?
Bruno stores collections as plain files in a folder, so any secret typed into a request or environment file can end up in a commit. The safe pattern is to reference secrets by name, resolve them from a vault at run time, and add environment files that hold values to .gitignore. Hoppscotch keeps secrets in its database rather than in files, which moves the risk to database access and backups. Add a pre-commit scanner in every repository that holds collections, and confirm the exact files your Bruno version writes before you set the ignore rules.
Does Postman Vault stay in Postman's cloud, and what happens to it after cutover?
Postman offers Local Vault on every plan, and Shared Vault on the Solo, Team and Enterprise plans, according to Postman's pricing page, so values in a shared vault are held in Postman's service. After cutover, the values must be re-created in the target store and the Postman copies removed according to your own retention and offboarding steps. Confirm with Postman how its vault data is deleted when a workspace or account is closed, and record that evidence for your assessors.
What should a quote for replacing Postman Vault include?
A useful quote lists the scope in writing: the collections and environments in scope, the secret sources to integrate, the target client or Hoppscotch deployment, and the systems that must be checked afterward. It should separate one-time work, such as inventory, migration, secret integration and documentation, from recurring work, such as upgrades, backups and support. Ask for the deliverables, acceptance criteria and the assumptions behind any timeline. DeployOpen does not publish a price list, and quotes follow from the written scope, so ask for each cost line and what would change it.
Does the open-source route cover audit logs and SSO for secrets access?
Not on the free editions, so confirm this before you rely on it. Hoppscotch Enterprise Edition adds SCIM provisioning, activity and audit logs and requires a license key, while Bruno's paid editions use a license portal that covers SAML SSO and SCIM. The Community Edition of Hoppscotch and the Bruno Open Source edition do not list these controls, so you would need to provide access logging at the database, vault and host layers. Confirm the audit requirements your assessors expect, then choose the edition and the logging design together.
Licensing and vendor risk for secret managers
If your Postman replacement plan involves a secrets manager such as HashiCorp Vault, the licence and ownership of that tool matter as much as its features. HashiCorp announced on August 10, 2023 that future releases would move from the MPL-2.0 to the Business Source License 1.1, and the Vault LICENSE file names IBM as licensor for Vault 1.15.0 or later. That licence bars competitive hosted or embedded offerings and converts each version to MPL-2.0 four years after publication. IBM completed its acquisition of HashiCorp on February 27, 2025, so the vendor's roadmap, pricing and licence terms now sit under a different parent company than when many teams first adopted Vault.
Open-source forks are the usual hedge against that kind of change. OpenBao is a community fork of Vault under MPL-2.0, managed by the Linux Foundation's OpenSSF. Its migration guide was tested only against Vault 1.14.1 community edition, not Vault Enterprise, so confirm compatibility for any feature you depend on before planning a move. Ask whether your planned Vault features, such as namespaces, replication or Sentinel policies, exist in the fork and whether your Vault version falls inside the tested range. Also confirm which storage backend you plan to use, since HashiCorp's storage documentation lists integrated storage and Consul as officially supported.
Before you commit, have counsel read the current licence text for the exact Vault version you will deploy and the terms of any Enterprise agreement, including how your use interacts with the competitive restrictions. This section describes publicly stated terms and is not legal advice. Record the licence you rely on, the date you checked it, and a decision owner, and revisit that record whenever you upgrade Vault or change vendors.
How DeployOpen scopes and delivers the secrets move
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For a move off Postman Vault, that means agreeing in writing where API credentials will live, how they reach requests and CI runs, and how the team keeps them out of Git.
How we scope
- Inventory which Postman environments, variables and collections hold keys, tokens or passwords, and who uses them
- Decide per secret whether it stays in a local Bruno environment, a Hoppscotch environment or an external secret manager
- Agree the written scope, deliverables and timeline before any work starts, since engagements are fixed-scope
How we build
- Configure the chosen secret source, such as HashiCorp Vault, AWS, Azure or Google Cloud, with access limited to the people and CI jobs that need it
- Set up Git ignore rules and pre-commit checks so credential files and plain values cannot be committed to shared collections
- Test collection runs with bru run or hopp test against the secret source, and confirm no secret appears in exported reports
How we hand over
- Document where each secret class lives, who owns rotation, and how a new collection or environment is added safely
- Walk the team through local and CI workflows, including the steps for onboarding and removing a user
- Provide the configuration, access rules and runbook as deliverables in your own repositories and environment
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the handover
- Review secret source versions and client updates as part of upgrade work, with changes agreed in writing
- Confirm with your security and compliance leads which evidence they need, since DeployOpen prepares controls and records but does not issue audit reports
