Self-hosted Postman alternative for EU data residency

If your API collections, environments and embedded credentials must stay in the EU, Postman's Frankfurt instance is limited to Enterprise customers. Offline Bruno files or a Hoppscotch instance in your own EU infrastructure keep that data under your control.

On this page

Why a self-hosted Postman alternative for EU data residency starts with where collections live

If a data residency or transfer requirement applies to your API work, the first question is where your collections, environments and test data are stored, not which client you open. Postman's EU Data Residency instance in Frankfurt is available only to Enterprise customers, so teams on other Postman plans cannot use it to keep this data in the EU. Offline-only Bruno and a self-hosted Hoppscotch Community Edition both keep API collections on infrastructure you control, which moves the residency decision from a vendor's plan tier to your own hosting choices. Postman's own documentation on EU data residency is the starting point for confirming what its Enterprise instance covers.

Collections are more sensitive than they look. They often hold base URLs for internal systems, example payloads containing personal data, and credentials such as bearer tokens, API keys and client secrets stored in environments or collection variables. Once those items are exported, shared or synced, they become personal data or security-relevant material in their own right, so the storage location matters as much as the request payloads. Before you choose a client, inventory which collections contain embedded credentials and which environments carry production hostnames or customer identifiers, and confirm with your data protection officer whether that content falls under your transfer assessment.

With Bruno, the collection is a folder of files on a device or repository you manage, so you decide where it sits. With Hoppscotch Community Edition, your team workspaces live in a PostgreSQL database set through DATABASE_URL on servers you run in your EU infrastructure. In both cases, confirm where backups, Git remotes, email relays used for sign-in, and logs are hosted, because any of them can move the data outside the EU even when the client itself is local.

What EU data residency requires for API collections

API collections often hold endpoints, environment variables, bearer tokens and sample payloads that can contain personal data. Whether that data leaves the EU depends on where it is stored, who can reach it remotely and which laws apply to the provider, so each requirement below should be checked against your own setup.

Transfers under Article 44

GDPR Article 44 applies Chapter V to every transfer of personal data to a third country, including onward transfers. A collection that holds customer identifiers in sample requests or test data is in scope when it is copied to a service outside the EEA. Map which collections and environments contain personal data, then record where each copy is stored. Confirm with your data protection officer whether test data is covered by your records of processing.

Remote access counts as a transfer

EDPB Guidelines 05/2021 state that remote access from a third country is a transfer, even when data is only displayed on a screen for support or administration. A vendor engineer who opens a shared collection from outside the EEA to troubleshoot an import can therefore create a transfer. Ask any API client or support vendor where their staff access customer workspaces and whether that access is logged and restricted.

Schrems II and the Data Privacy Framework

The Court of Justice invalidated the Privacy Shield in Case C-311/18 (Schrems II) while upholding standard contractual clauses. Commission Implementing Decision (EU) 2023/1795 recognizes the EU-US Data Privacy Framework only for US organizations on its list, and an appeal against the General Court's September 2025 judgment is pending as Case C-703/25 P. Check whether a US-owned vendor is on the list today and plan for the case that the decision is set aside.

CLOUD Act exposure

18 U.S.C. 2713 requires US electronic communication and remote computing service providers to preserve or disclose data in their possession, custody or control, wherever it is stored. A US-headquartered SaaS client can therefore be reached even when the data sits in Frankfurt. EDPB Recommendations 01/2020 say that where access goes beyond what is necessary and proportionate, no effective technical measure is foreseen. Ask counsel to assess this exposure before choosing a cloud-hosted collection store.

Article 48 limits on foreign orders

GDPR Article 48 allows a third-country court judgment or administrative decision requiring disclosure of personal data to be recognized or enforced only when it rests on an international agreement, such as a mutual legal assistance treaty, in force with the Union or a Member State. This limits how far a foreign order can be enforced in the EU, but it does not remove the exposure described for CLOUD Act providers. Keep it as one input to counsel's assessment, not as a guarantee.

Data Act Article 32 for non-personal data

Article 32 of the EU Data Act (Regulation (EU) 2023/2854) requires data processing service providers to take measures against third-country governmental access to non-personal data held in the Union when that access would conflict with Union or national law. It covers non-personal data, such as API configuration without personal content, while personal data stays under the GDPR. Ask providers how they meet Article 32 in writing, and keep the switching rights in the Data Act in mind when you compare options.

Which API clients keep collections in the EU, and the trade-offs

This table compares Postman's Enterprise EU instance, offline Bruno and self-hosted Hoppscotch Community Edition on where collections are stored, who controls them and what each option costs to extend. Read each row as a question to answer against your own hosting and vendor contracts, because the EU location of data depends on the vendor's setup and your infrastructure. The main takeaway is that only the two self-hosted or offline options keep collections on infrastructure you control by default.

OptionWhere collections liveTrade-off to checkWhen it fits
Postman EU instance (Frankfurt)Postman's EU cloud, available only to Enterprise customersEnterprise contract required; confirm data location terms and sub-processors with PostmanTeams already on Enterprise that accept a vendor-hosted EU region
Bruno (offline, MIT)Plain files in a folder you choose, shared through GitNo cloud sync by design; the Git UI push and merge features need a paid editionTeams that want collections in their own repositories and EU storage
Hoppscotch Community EditionPostgreSQL database in an EU server you runYou install, patch and back up the stack; SSO needs OAuth setup or EnterpriseTeams that want a shared web workspace on EU infrastructure they operate
Bruno Pro or Ultimate seatsSame files as Bruno; licence managed in a licence portalPaid seats add SAML SSO, SCIM and bulk Postman import; check licence portal data handlingOrganizations that need SSO provisioning while keeping files local
Hoppscotch Enterprise EditionSelf-hosted instance with a licence keyAdds SAML, OpenID Connect, SCIM and audit logs; confirm licence terms before deploymentOrganizations that need SAML and SCIM on their own servers
Hoppscotch CLI (alpha)Runs tests from files or your instanceDescribed as alpha; check stability before using it in gating pipelinesPipelines that run collections against an EU instance
Imports from PostmanPostman export files, up to 50 MB on self-hosted HoppscotchLarger exports need splitting; the 50 MB limit applies to self-hosted editionsMoving existing collections into EU storage

Choosing between offline Bruno and self-hosted Hoppscotch by team setup

Bruno suits people who work alone or teams that already share code through Git. Bruno is offline-only and has no plans for cloud sync, so each collection is a folder on a laptop or repository that you commit like any other source. Nothing runs on a server, which means there is no database to back up, no upgrade window for a platform and no sign-in service to operate. Collections stay on the devices your organization controls, which fits strict residency rules.

  • No server to run: The desktop app is installed on macOS, Windows or Linux, and the collection lives in a folder.
  • Git as the collaboration layer: Teams review API changes in pull requests the same way they review code.
  • Free core features: The Open Source edition covers clone, initialize, diffs, pull and commit, and Git itself works outside the app on any edition.
  • Paid editions are optional: Git push, branch operations and merge conflict resolution in the app require a paid Bruno edition, but you can run those steps in Git on the command line.
  • Cost is mostly staff time: Recurring cost comes from the people who keep collections current and any paid seats you choose to add.

Confirm with your Git hosting and security team how secrets are kept out of committed files before you adopt this model.

How to move collections into EU infrastructure in sequence

This sequence moves Postman collections, environments and test data into Bruno files or a self-hosted Hoppscotch instance inside EU infrastructure you control, with secrets kept out of version control. Each step ends with a check you can record for your data protection file.

  1. Inventory personal data and credentials in Postman

    The data protection lead and the API owners list every workspace, collection, environment and global variable that holds personal data, such as customer identifiers in request bodies, or credentials, such as bearer tokens, API keys and client secrets. Record the owner and the systems each collection calls. The output is a register that marks each item as personal data, credential, or neither, and this register sets the scope for the rest of the sequence.

  2. Export collections and environments from Postman

    An API owner exports each collection as Collection v2.1 JSON and each environment from the Postman app, while the account administrator decides whether an account-wide bulk export is needed for shared content. Check the export limits and download windows described in the Postman export guide before you start, because scripted exports are subject to Postman API call limits. The output is a folder of JSON files that matches the register from the previous step.

  3. Store exports in an EU location you control

    Move the exported files to a storage location in an EU cloud account, data center or on-premises network that your organization controls, and restrict access to the people named in the register. Do not place these files in a personal drive or a non-EU file sharing service during the migration. The output is a restricted folder with an access list, and a note of where the original exports were deleted once the import is verified.

  4. Import into Bruno or Hoppscotch and review scripts

    Import the collections into Bruno, which reads Collection v2 and v2.1 JSON, or into a self-hosted Hoppscotch instance, which accepts Postman collections and environments up to the 50 MB self-hosted limit. Review the import log for Postman script APIs that were translated and for packages that were flagged as unsupported, such as postman-collection and newman. An engineer rewrites the flagged scripts and reruns each request against a test environment. The output is a list of rewritten scripts with passing test runs.

  5. Deploy Hoppscotch Community Edition in EU infrastructure

    If your team needs a shared server rather than local files, a platform engineer deploys Hoppscotch Community Edition with the Docker install in an EU cloud account or data center. Point DATABASE_URL at a PostgreSQL database in the same region and size the build and host machines using the published prerequisites. Your team installs and updates the software itself, so assign an owner for quarterly releases. The output is a running instance reachable only from your network, with its database in the EU.

  6. Configure OAuth sign-in and SMTP for the instance

    The administrator configures the Email, GitHub, Google or Microsoft OAuth providers that your identity policy allows, and sets the SMTP settings needed for email sign-in and notifications. Confirm with your identity team which provider is authoritative for staff accounts, and confirm that the SMTP relay is in the EU if mail contains personal data. The output is a sign-in test by each user group and a documented list of enabled providers and mail routes.

  7. Keep secrets out of Git and verify the move

    Remove credentials from the imported collections and replace them with environment variables or references to your secret manager, so no token or key is committed to a repository. If collections are stored in Git, add a pre-commit or repository scan that blocks committed secrets, and keep the Bruno folders or Hoppscotch workspaces under access control. Confirm with the register that every item has been moved, tested and cleaned up. The output is a signed-off checklist that your compliance lead can keep as evidence, though an independent auditor decides whether it meets any assessment requirement.

Evidence to collect for a data residency review

A residency review tests whether personal data in API collections stays where you say it does, and whether any transfer is covered. The cards below cover the records that connect the storage, hosting, sign-in and transfer questions, so one review can follow the data from request to deletion. Auditors and regulators decide whether the evidence is sufficient, and DeployOpen prepares evidence but does not issue attestations.

Data flow map and storage locations

Start with a map that shows every place collections, environments, response bodies and test data are written: a developer laptop, a Git remote, the Hoppscotch PostgreSQL database, backups, logs and CI runners. For each location, record the country or data center, the operator and who holds administrative access. Include copies that tools create by default, such as local caches and exported JSON files, because reviewers often find them after the main store is checked. Confirm each location with the people who run it, not only with the architecture diagram.

Hosting location and access logs

For a self-hosted Hoppscotch Community Edition instance, document the EU region of the virtual machines or Kubernetes cluster, the database host, and the backup targets. Keep administrator access records and authentication logs for the instance, and confirm how long your platform retains them. Check that remote support sessions, vendor consoles and monitoring tools do not show production data from outside the EU, since viewing data remotely can count as a transfer under the EDPB guidance. Name the people who can open the database.

Git history and repository access controls

For Bruno, collections are plain files in a folder, so the Git repository becomes the system of record. Document where the remote is hosted, who has read and write access, and whether branch protection requires review before merge. Scan the history for credentials, because a secret committed once remains in older commits even after it is deleted from the current files. Record how the team keeps environment files with secrets out of the repository, and confirm the location of any Git hosting provider you use.

Transfer impact assessments

Any service outside the EEA that can receive or access collection data needs a documented transfer assessment under Chapter V of the GDPR. The assessment should name the transfer tool relied on, the destination law, and the supplementary measures considered, such as encryption where the provider holds no keys. Reviewers also expect you to consider whether an EU provider is subject to third-country law with extraterritorial effect. Record the date of each assessment and the person who approved it, and rerun the assessment if the destination rules change.

OAuth, SMTP and provider locations

A Hoppscotch Community Edition instance can sign users in through Email, GitHub, Google or Microsoft OAuth providers and sends mail through an SMTP service. Each of these providers receives personal data such as names, email addresses and sign-in events, so list each one, the account it runs under, the processing location and the data processing agreement in place. Confirm whether the identity provider or mail relay stores logs outside the EU, and decide whether a self-hosted mail relay is needed to keep these records in the EU.

Export and deletion records

Keep a record of each collection export, such as a Postman JSON file or a Bruno folder copy, including who made it, when, where it was stored and when it was deleted. Deletion should cover the primary store, backups and the local copies on laptops. For Hoppscotch, confirm how a user or workspace is removed from the database and how backups age out. For Bruno, record the removal of collection folders and their Git history if a full erasure is required. These records show that data was moved and removed on purpose.

Common questions about EU data residency for API collections

Is Postman's EU Data Residency instance available without an Enterprise plan?

No. Postman's EU Data Residency instance in Frankfurt is available only to Enterprise customers, according to Postman's documentation on EU data residency. Teams on Free, Team or other lower tiers cannot select it for their collections, environments or test data. Before you assume an upgrade solves the problem, confirm with Postman which features the Frankfurt instance includes, because the instance is also described as lacking some features. If you need EU storage without an Enterprise contract, the realistic options are offline Bruno, which keeps files in a folder you control, or a self-hosted Hoppscotch instance in your own EU infrastructure.

What drives the cost of moving API collections to a self-hosted EU setup?

Cost splits into licenses, infrastructure, and people. Bruno's Open Source edition is $0, while its Pro and Ultimate editions are listed at $6 and $11 per user per month, billed annually, according to Bruno's pricing page. Hoppscotch Community Edition is free to use, but you pay for the server that builds and hosts it, the PostgreSQL database behind it, SMTP for email sign-in, and the staff who install, upgrade and back it up. The Hoppscotch build prerequisites list 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. One-time costs include migration and script rewriting. Recurring costs include seats, hosting, patching and upgrades. Ask any vendor or partner for a written quote that separates these components.

How long does migrating API collections take and what makes it longer?

The duration depends mostly on the number of collections, the number of scripts, and how secrets are stored today. Bruno translates common Postman script APIs such as pm.test, pm.environment and pm.response during import, but it flags packages such as postman-collection and newman as unsupported, so each flagged script needs a manual rewrite. Hoppscotch's importer accepts Postman collections and environments, with a 50 MB limit on self-hosted editions, so very large exports may need splitting. Collections that embed API keys or tokens take longer because each credential must be moved into a secret store or environment file and removed from Git history. No researched duration applies to your estate, so ask for a timeline that is tied to a written inventory of collections, scripts and secrets.

Can our team migrate API collections without outside help?

Yes, a small team with a clear inventory can usually do the basic move alone. Bruno's documentation covers importing a Collection v2 or v2.1 JSON export, and Hoppscotch's importer covers Postman collections and environments. The harder work is repetitive: checking translated scripts, deciding where secrets go, setting up branch and review rules in Git, and confirming that CI runs still pass. Bulk import of a full Postman data dump is included only in Bruno Ultimate Edition, so teams with many collections should weigh that against staff time. Outside help makes most sense when you must document the control evidence for an assessment, need a self-hosted Hoppscotch deployment with OAuth and SMTP configured, or lack capacity to maintain the server after go-live.

Does Bruno's Git push require a paid edition?

Yes, Git push is a paid feature in the Bruno app. Bruno's pricing page marks push, branch operations, remote connections and merge conflict resolution in the Git UI as paid, while the Open Source edition covers clone, initialize, diffs, pull and commit. Git itself still works outside the app on any edition, so a team on the free edition can commit and push from a terminal or from its existing Git client. Collections are plain files in a folder, which keeps them under your own Git server. Confirm the current feature split on Bruno's pricing page before you rely on it in a procurement decision, because edition contents can change.

Do we need Hoppscotch Enterprise Edition for SSO on our own servers?

Only if your policy requires SAML single sign-on, OpenID Connect with provisioning, SCIM or audit logs. The Community Edition signs users in through Email, GitHub, Google and Microsoft OAuth providers that the administrator configures, and it needs SMTP settings for email. Hoppscotch's Enterprise Edition documentation lists SAML-based SSO, OpenID Connect, SCIM user and group provisioning, activity and audit logs, and it requires a license key. Enterprise is therefore a licensing decision tied to identity controls. Ask Hoppscotch for current pricing and check whether the OAuth providers you already use satisfy your sign-in rules before you commit to the paid edition.

What does a fixed-scope DeployOpen engagement cover for this migration?

DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For this migration, a fixed-scope engagement would typically cover the collection inventory, a self-hosted Hoppscotch deployment or a Bruno Git repository layout, script review, secret handling, CI integration with the Hoppscotch CLI or Bruno CLI, and the documentation your team needs. Scope, deliverables and timelines are agreed in writing before work starts, and a quote follows from that written scope. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications, which independent auditors and certification bodies provide. Ongoing support and upgrades are available as retainers.

Does keeping collections in the EU settle every transfer question?

Not on its own. Storing collections in an EU instance you control avoids routing them through a third country, but the transfer analysis also covers remote access from outside the EEA, support staff who view data, and the hosting provider's own legal exposure. EDPB Guidelines 05/2021 state that remote access from a third country, even only displaying data on a screen, counts as a transfer. The guidelines also say that engaging an EU processor subject to third-country law is not itself a transfer, but complying with a third-country authority request would be, so controllers should assess that exposure. Have your data protection officer and counsel review hosting, access and support paths, rather than relying on the storage location alone.

What changes for developers and CI after the move

The biggest change for developers is where collaboration happens. In Bruno, a collection is a folder of files on the local filesystem, so the team shares it through Git the same way it shares source code. Changes go through branches, diffs and pull requests, and the review record lives in the repository rather than in a vendor's workspace. Bruno's README states that it has no plans for cloud sync, so the team must agree on a branching and review routine before the first import. Confirm with your own engineers whether the Git operations they need (push, branch operations, merge conflict resolution) are in the Open Source edition or the paid Git UI features, and note that Git itself works outside the app on any edition.

With a self-hosted Hoppscotch instance, collaboration moves to team workspaces on your own server, backed by PostgreSQL. Postman account sign-in stops being the access path. Users sign in through the Email, GitHub, Google or Microsoft OAuth providers your administrator configures, and email delivery depends on SMTP settings you must supply. Decide before go-live who administers those providers, who can create workspaces, and how departing staff are removed, because the Community Edition does not provide SAML SSO or SCIM provisioning. Those controls belong to the Enterprise Edition, so confirm whether your identity requirements can be met with the community sign-in methods.

For CI, the command-line runners differ. The Bruno CLI runs collections with bru run and can produce test reports, while the Hoppscotch CLI runs hopp test against a file or a self-hosted instance and writes JUnit XML. The Hoppscotch CLI is described as alpha, and current versions need Node.js 22 or later, so check that your build agents meet that requirement and test the pipeline on a copy of the collection first. Scripts that call Newman or the Postman CLI must be rewritten, and any script that relies on a Postman cloud environment must instead read values from files or secret stores the pipeline controls.

How DeployOpen deploys API clients under EU residency constraints

DeployOpen plans and implements self-hosted API clients inside your own infrastructure, so collections, environments and test data stay where your data protection assessment says they must. We start from written scope and finish with documented handover, with ongoing support available as a retainer.

How we scope

  • We map which collections, environments and credentials hold personal or regulated data before choosing Bruno or Hoppscotch.
  • We confirm the EU hosting location, network path and who administers the Hoppscotch server or Git repositories.
  • Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.

How we build

  • We install Hoppscotch Community Edition in your EU environment with PostgreSQL, OAuth sign-in and SMTP configured.
  • We set up Bruno collections as files in a Git repository on your own servers, with secrets kept out of committed files.
  • We import Postman collections and environments, review translated scripts and test the results against your current requests.

How we hand over

  • We document the hosting location, data flows, access roles, backup routine and upgrade steps for your records.
  • We provide evidence of configuration settings to support your own assessments, without issuing any audit report or certification.
  • We run a handover session so your administrators can operate the chosen client and its CLI in CI.

How we support

  • Ongoing support, upgrades and continuous testing are available as retainers after handover.
  • We track Hoppscotch and Bruno release notes and plan upgrades inside your change process.
  • Ask us to confirm any legal reading with your counsel or data protection officer, since we prepare controls and evidence only.

Sources and further reading

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.