Self-hosted LaunchDarkly alternative for EU data residency

LaunchDarkly's EU option is limited in scope, so teams with strict residency rules often run a self-hosted flag server in an EU data center they control. Unleash, Flagsmith and GrowthBook each fit that model with different trade-offs.

Book a callTalk to us
On this page

Why a self-hosted LaunchDarkly alternative for EU data residency needs a closer look

For most EU-regulated teams, the main route is a self-hosted Unleash, Flagsmith or GrowthBook instance in an EU data center the organization controls. A residency or GDPR-driven review starts by asking where flag definitions, targeting attributes and evaluation data live, and who can reach them. Map each data category to a system and a location: the server, its database, SDK traffic, any Edge or proxy layer, backups and logs. Unleash's getting started guide runs the server from the unleashorg/unleash-server image against PostgreSQL 15 or later, with the server and admin UI on port 4242, which gives you a concrete inventory to check. Confirm each component's hosting location in writing with your own architects before sign-off.

LaunchDarkly offers an EU instance in AWS Frankfurt, but its limits belong in your review. As currently described, that instance is available only to new Enterprise accounts and trials, so an existing account may not be able to move there without changing plans. Confirm that eligibility directly with LaunchDarkly against its current terms. Monitoring and CDN delivery run from the United States, which affects where operational and SDK-facing data travels even when flag storage sits in Frankfurt. Some features are also unsupported on the EU instance. Request a written list of unsupported features and check each one against the flags, approvals and integrations your teams depend on.

A self-hosted design moves those questions to your team, so the residency position depends on configuration. Flagsmith's official Helm chart creates its own PostgreSQL server in the cluster by default, while its docs recommend an externally managed database in production, so decide which database holds flag state and keep it in the EU. GrowthBook stores metadata in MongoDB or a compatible database, and its warehouse analysis runs only SELECT queries and transmits only aggregated statistics, so raw event data stays in your warehouse. If you plan to use Unleash Edge, note that its open-source version reaches end of life on December 31, 2026, so choose an EU-hosted caching layer on a supported path. Verify telemetry and update checks for each option before approval.

What EU data residency asks of a flag system

A flag system sits on the request path of your applications and holds targeting data about your users, so residency questions reach further than where the database lives. The cards below separate the data a flag server stores, the people who can change it, the traffic that leaves the region and the paper trail that proves where everything went.

Where flag definitions live

Flag definitions, environments, segments and audit history are stored in the database that the flag server uses. In a self-hosted Unleash, Flagsmith or GrowthBook deployment, that database is PostgreSQL or MongoDB in a location you choose, so you can pin it to an EU region. Confirm which database backups, replicas and log stores hold copies, since residency applies to those too.

Targeting attributes and evaluation data

Targeting rules often reference user IDs, email domains, country codes or account tiers, and SDKs send those attributes with each evaluation. Decide which attributes leave the browser or service, whether they are hashed or pseudonymized, and whether your evaluation traffic reaches the flag server inside the EU. Map every attribute your rules read before you choose a region.

Who can administer flags

Administrative access determines who can read or change targeting data from outside the region. Self-hosted options let you control this with your own identity provider, but SSO, SCIM and fine-grained roles are gated behind paid editions in several products, so check which features you need before you pick a tier. Confirm with your DPO which administrator locations and support access paths are acceptable.

Monitoring and CDN traffic

Hosted services often route SDK traffic through their own CDNs and send monitoring data to shared services, which may sit outside the EU. Self-hosting removes the vendor CDN, but you still need to review metrics exporters, error tracking, analytics snippets and any Edge or proxy layer you deploy. List every outbound destination from your application servers and browsers, then confirm each one with your DPO.

Transfers and subprocessors

Where a vendor operates an EU instance, the contract, its subprocessor list and its transfer mechanisms determine what data crosses borders during support, billing or monitoring. With a self-hosted deployment, the subprocessors are your own cloud provider and any managed database or support partner you engage, and each one needs documented location and access terms. Ask your auditor which records they expect to see, and keep those records current.

Where LaunchDarkly's EU instance meets the requirement and where it does not

LaunchDarkly's EU instance in AWS Frankfurt covers a narrower set of accounts than a general EU hosting claim would suggest. Based on the scope available for this page, it applies only to new Enterprise accounts and trials. An existing customer on LaunchDarkly's standard deployment should not assume that the Frankfurt instance is an option without a written answer from LaunchDarkly on whether and how a move is possible, what it involves, and whether it changes contract terms. Unsupported features are the second limit to check. Make a list of the flag, targeting, experimentation, SDK and integration features your teams use today, then ask which of them are unavailable on the EU instance, because a missing feature can push teams back to a US-hosted configuration.

Residency is more than the location of the flag database. Monitoring and CDN delivery remain US-based, so an EU instance does not settle the data location question for every category of data that a flag service handles. Your review should separate at least four questions: where flag configuration and evaluation data are stored, where operational telemetry and monitoring data go, how SDK and client assets are delivered, and which subprocessors touch each of these. Ask LaunchDarkly for the current written scope, the subprocessor list, its data location commitments and the transfer mechanisms it relies on. Give those documents to your privacy counsel and data protection officer for interpretation. Your team should not read a vendor FAQ as a legal conclusion.

A self-hosted deployment of Unleash, Flagsmith or GrowthBook moves the data location decision to your own deployment choices. The server, database and admin interface can run in an EU data center or cloud region that your organization controls, but the same questions still apply to your setup. Confirm where the PostgreSQL or MongoDB database, backups, application logs, metrics and SDK traffic sit, and whether any managed service or CDN you add sends data outside the EU. Migration needs its own check, since exporting flag definitions through the LaunchDarkly REST API and recreating them in the target system both touch data in transit. Record each finding in your data inventory so the residency position is documented before any cutover.

Which open-source option fits an EU-hosted flag server

Unleash runs as the unleashorg/unleash-server image against PostgreSQL 15 or later, with the server and admin UI listening on port 4242. Flag definitions, segments and the evaluation API live in the database and servers you deploy, so placing that stack in an EU region you control keeps flag configuration and evaluation traffic inside your infrastructure. The license changed at v8.0.0, so review it before you standardize.

  • Data location: The server and PostgreSQL database run wherever you deploy them. Choose an EU region and confirm that backups, logs and replicas follow the same boundary.
  • License: From v8.0.0 the server source is AGPLv3, while the official open-source Docker images remain under Apache 2.0. Unleash's blog states that running the official images without modifying the source is not affected, but counsel should review any internal fork.
  • Free tier limits: Open Source allows 1 project, 2 environments and 5,000 feature flags per instance, with basic roles.
  • Enterprise-only features: Single sign-on, SCIM provisioning, project and custom roles, user groups and change requests require Enterprise, which is sold on custom annual contracts for self-hosted deployments.
  • Edge caveat: The open-source version of Unleash Edge reaches end of life on December 31, 2026, so EU edge caching designs need an Enterprise plan or another plan before go-live.

Ask Unleash for the current self-hosted Enterprise scope and the Pay-As-You-Go terms, which list $75 per seat per month with a 5-seat minimum for self-hosted deployments.

How to deploy a flag server inside your EU data center

This sequence takes a self-hosted Unleash, Flagsmith or GrowthBook server from a chosen EU site to a running, reachable flag service whose data, admin access and SDK traffic stay inside infrastructure your organization controls.

  1. Choose the EU region and data center

    Your architecture, security and data protection teams agree on the EU site where the flag server, its database and its backups will run, and confirm which facility, cloud region or private data center meets your residency commitments. Record the site, the network zones that will reach the server, and who holds administrative access. Confirm with your provider or data center operator where backups and snapshots are replicated, because a flag server holds targeting attributes and user context that may count as personal data. The step is done when the site, zones and access owners are written down and approved.

  2. Provision the database for your chosen platform

    Your platform engineers provision the database that matches the option you selected. Unleash needs PostgreSQL 15 or later. Flagsmith's Helm chart creates its own PostgreSQL server in the cluster by default, but the Flagsmith documentation recommends an externally managed database in production and offers optional PgBouncer, so most teams should provision an external instance here. GrowthBook stores metadata in MongoDB or a compatible database, and its documentation suggests a managed service such as MongoDB Atlas or AWS DocumentDB for production. Confirm the managed service is available in your EU region and that encryption at rest, backups and point-in-time recovery meet your policy. The step is done when the database endpoint, credentials and restore test are documented.

  3. Deploy the container images or official Helm charts

    Your platform team deploys the server from the official images or charts. For Unleash, run the unleashorg/unleash-server image, or unleashorg/unleash-enterprise if you hold an Enterprise license, pointed at your PostgreSQL instance. The server and admin UI listen on port 4242, so set that port as the internal service target. For Flagsmith, install the flagsmith/flagsmith chart from its official chart repository with the external database settings. For GrowthBook, use its official Helm chart or single Docker image. Pin image versions and record them in your change log. The step is done when the pods or containers pass health checks and you can log in to the admin interface from an internal address.

  4. Put admin and SDK endpoints behind internal TLS

    Your security engineers place the admin UI and the SDK endpoints behind an internal load balancer or ingress with TLS certificates issued by your internal certificate authority. Keep the admin interface reachable only from your management network and let application SDKs reach the evaluation endpoints from the networks where your services run. Disable direct public exposure and confirm DNS resolves only to internal addresses. The step is done when a TLS scan from outside the network fails and an internal test client receives valid certificates.

  5. Restrict egress from the flag server

    Your network team limits outbound traffic from the flag server and its database so that only what the platform needs is allowed. Inbound SDK traffic and admin access are the expected flows. Outbound flows should be limited to your database, your identity provider if you use SSO, your log collector and any package or image sources you have approved for updates. Document each allowed destination and review it when you upgrade. The step is done when a test from the server to an unapproved external address is blocked and logged.

  6. Configure SSO if your license covers it

    Your identity team connects the admin interface to your identity provider only where the license covers it. Unleash SSO and SCIM sit in Enterprise, Flagsmith SAML and Okta integrations are Enterprise features, and GrowthBook SSO and SCIM are part of self-hosted Enterprise. Confirm these entitlements with each vendor before planning, because the free editions use local accounts. Test sign-in with a non-administrator account and confirm that deprovisioning removes access. The step is done when SSO sign-in works and a disabled test user is refused.

  7. Plan Edge or Edge Proxy placement

    Your platform team decides where a caching layer sits between application SDKs and the server, so that flag evaluation stays fast and the central server is not overloaded. For Unleash, Unleash Edge caches between SDKs and the API, but the open-source version of Edge reaches end of life on December 31, 2026, and Unleash recommends OSS Edge users move to an Enterprise plan. For Flagsmith, the optional Edge Proxy reduces latency. Place the caching layer in the same EU network zone as the workloads it serves, and confirm the support status of your chosen version before go-live. The step is done when the placement diagram is approved and a test service reads flags through the chosen layer.

  8. Verify the deployment and record the evidence

    Your operations and compliance teams check that the deployment behaves as designed and keep the evidence in your records. Confirm the server answers from the intended network only, the database is reached only by the server, backups restore to a test environment, and SDK calls return flag values. Keep configuration, version pins, network rules and test results together so auditors can trace them. DeployOpen can prepare this evidence for a compliance assessment, but independent auditors and certification bodies issue any audit report. The step is done when the verification checklist is signed off and stored with the deployment record.

What auditors and data protection officers ask to see

Where does the self-hosted flag data physically reside in an EU deployment?

The location is whatever data center or cloud region you choose, because the flag server, its database and any cache run in infrastructure your organization controls. Auditors usually want a data flow diagram that lists each component (the Unleash, Flagsmith or GrowthBook server, its database, SDK traffic, backups and any log sink), the account or data center that holds it, and the region for each. Include where SDKs connect from, since client-side traffic can cross borders even when the server does not. Confirm the exact regions with your hosting provider, including any support access from outside the EU. DeployOpen prepares the diagram and configuration evidence from your environment, but your data protection authority and auditor decide whether that location meets your obligations.

How do auditors check access control and SSO for a self-hosted flag server?

Auditors look for named accounts, least-privilege roles, a documented way to remove access, and the identity provider configuration that proves it. The gap between editions matters here. Unleash Enterprise adds single sign-on, SCIM provisioning, custom roles and change requests. Flagsmith lists SAML single sign-on and role-based access control as Enterprise Edition features that require a license. GrowthBook's self-hosted Enterprise plan adds SSO, SCIM and advanced permissioning. If your policy requires federated login and provisioning, price the edition that includes them before you write the control narrative. Collect role assignment exports, the SSO configuration and a periodic access review record. Confirm with each vendor which features your chosen edition includes.

What should backups and encryption look like for flag data?

Flag definitions are small, but they control production behavior, so treat database backups as sensitive data with a documented location, encryption and tested restore. Name the backup target, the region where copies are stored, the encryption method at rest and in transit, key ownership and retention. The database choice drives the design. Flagsmith's Helm chart creates its own PostgreSQL server by default, and its docs recommend an externally managed database in production. Unleash requires PostgreSQL 15 or later. GrowthBook stores metadata in MongoDB or a compatible database and can keep file uploads on local storage, Amazon S3 or Google Cloud Storage. Keep backup copies in the same jurisdiction as the primary data unless your transfer assessment allows otherwise, and keep a dated restore test record.

Which subprocessors and transfers apply when a hosted component is used?

Any hosted component that handles personal data becomes a subprocessor in your records, including a managed database, an SSO provider, an email relay, an error tracker, a CDN for SDK assets or an external warehouse used for experiment analysis. Document each one with its name, purpose, data categories, processing location and the transfer mechanism you rely on. A self-hosted core shortens this list but does not remove it. For GrowthBook, experiment analysis runs read-only SELECT queries against your own data source and transmits only aggregated statistics, which is worth stating in the register. Ask each provider for its current subprocessor list and data processing terms, and have counsel confirm the transfer basis. DeployOpen can compile the register from your architecture, but the legal assessment belongs to your data protection officer.

What change and import logs prove a LaunchDarkly migration was controlled?

Auditors want a timestamped record showing what was exported, who imported it, what changed in the target and who approved the cutover. Keep the raw JSON exports from the LaunchDarkly REST API, the import output and a diff between source and target flag definitions. Unleash moves flags as JSON but exports segments and custom strategies only as references, so the record should show those objects existed in the target before import. Flagsmith's importer overwrites existing environments and flags in the target project, so a fresh project and a dated snapshot of prior state are essential. GrowthBook's importer creates new revisions on re-import, which should appear in change history. Store these artifacts with approvals and a rollback plan, and record who reviewed the flags the importer marks for manual checks. The Unleash migration guide describes the export and recreation steps.

How do you show the self-hosted instance is the system of record?

Show that production flag decisions are made, stored and audited in the self-hosted instance, and that LaunchDarkly no longer serves or receives decisions for those flags. The evidence is a cutover record, an inventory of applications whose SDK or OpenFeature provider points at the new server, a dated read-only or decommissioning status for the old tenant, and a sample of recent changes traced to named users in the new system. Unleash's migration guide recommends running both systems in parallel behind an abstraction layer before cutover, so document the parallel-run period and its exit criteria. Confirm that no application falls back to the old service without a logged reason. Record how legacy LaunchDarkly data is retained or deleted under your own retention rules, because the migration does not settle that question.

Who decides whether our EU setup meets data residency rules?

Your data protection officer, your legal counsel and the independent auditor or regulator who reviews your program decide whether the setup meets your obligations. DeployOpen prepares the systems, controls and evidence described above, including diagrams, configuration records, access and backup documentation and migration logs. It does not issue audit reports, attestations or certifications. Scope the engagement in writing so each artifact has a named owner, a storage location and a review date. Ask your auditor early which evidence formats they accept, since a diagram without configuration exports often draws follow-up questions. Confirm with legal whether any transfer mechanism or local hosting requirement applies to the regions you select. Use this list to brief those reviewers before the assessment begins.

How to move flags out of LaunchDarkly without losing targeting

The safest move is to export definitions first, then rebuild them in the self-hosted target while both systems run side by side. Start by pulling flag, segment, environment and project definitions from LaunchDarkly through its REST API with an access token, and store those JSON exports in the EU environment you control, since they contain targeting logic and possibly customer identifiers. From there, pick the path that matches your tool. Flagsmith's built-in LaunchDarkly importer copies projects, environments and flags, and the Flagsmith documentation warns that it overwrites existing environments and flags in the target project, so import into a fresh, empty project. GrowthBook's importer runs in two steps, fetching into a preview before importing pending flags, and the application still has to switch from the LaunchDarkly SDK to a GrowthBook SDK after the import. For Unleash, the Unleash migration guide maps targeting rules to activation strategies, multivariate flags to strategy variants and segments to segments, and recreates segments and custom strategies in the target before any import.

Treat every imported flag as unverified until someone has checked it by hand. Compare targeting rules, fallback values, prerequisites and percentage rollouts against the LaunchDarkly source, and confirm that user bucketing will not change for users already in a partial rollout. Flagsmith's documentation specifically asks for manual checks after import, and GrowthBook's importer documentation notes that advanced setups may include scenarios it cannot handle. Confirm with the vendor which fields each importer carries over before you rely on it. Plan for the fact that the migration itself touches residency: the exports, the importer's access token and any Relay Proxy or Edge components must all run inside the EU boundary, and the LaunchDarkly API calls should be scoped and logged under your own change records.

Put an abstraction layer in front of both systems before cutover. OpenFeature, a CNCF project that is currently at the Incubating maturity level, lets application code call one evaluation API while a provider decides which flag system answers. Wrap existing LaunchDarkly calls with the LaunchDarkly provider, run both systems in parallel, then switch the provider to Unleash, Flagsmith or GrowthBook one service at a time. Keep the cutover reversible until targeting results match across a representative period, and keep the old LaunchDarkly connection active until your data and audit obligations are settled. The exact effort depends on how many SDK call sites and services you have, so ask any implementation partner for a written inventory before agreeing a scope.

Running both systems in parallel before the EU cutover

This sequence lets you prove that the self-hosted flag service returns the same decisions as the US-hosted LaunchDarkly service for the same users, one environment at a time, before any traffic moves. It also gives you dated evidence for the data deletion and decommissioning record that your privacy and compliance owners will ask for.

  1. Stand up the EU flag server and database

    The platform team deploys the chosen server, such as Unleash on PostgreSQL 15 or later, Flagsmith on an externally managed PostgreSQL database, or GrowthBook on MongoDB or a compatible database, inside the EU data center or cloud account you control. Use the deployment guidance in the vendor documentation for your topology and confirm that the server and admin UI are reachable only from the networks you intend. The step is done when a health check passes and an administrator can log in through your identity provider or local accounts, with the database backups tested for restore.

  2. Export and recreate flag definitions in the EU instance

    The team that owns flag governance exports flag and segment definitions from LaunchDarkly through its REST API using a scoped access token, then recreates them in the EU instance using the importer or migration path your chosen vendor documents. Flagsmith and GrowthBook include built-in LaunchDarkly importers, while Unleash documents a scripted route through the Admin API. Record which definitions were copied, which were rebuilt by hand, and which were skipped, such as archived flags you choose not to carry over. The step is done when a reviewed inventory matches the LaunchDarkly export.

  3. Put both systems behind one flag abstraction

    Application teams wrap existing LaunchDarkly SDK calls behind an abstraction layer, ideally the CNCF OpenFeature API with a provider per backend, so that a single configuration switch decides which system answers each evaluation. Keep the LaunchDarkly provider as the default and add the new provider behind a flag per service or per environment. The step is done when a test build can evaluate the same flag key against either backend without code changes in business logic.

  4. Compare evaluations for the same contexts

    Engineers run a shadow comparison in a non-production environment, sending identical context objects, including user key, country and any attributes used in targeting, to both systems and logging each returned variation. Mismatches are investigated against targeting rules, attribute types, prerequisites and percentage rollout logic. The step is done when the mismatch rate for the agreed test set is zero, or every remaining difference has a documented explanation and an owner.

  5. Verify bucketing in partial rollouts

    Before any percentage rollout moves, the team checks that users keep the same variation in both systems. Percentage rollouts depend on how each platform hashes the user key and the flag or rollout seed, so a different hashing approach can move users between variations. Confirm this against the migration documentation for your vendor and test it with a sample of real user keys in staging. If assignments differ, keep the LaunchDarkly rollout as the source of truth for those flags until you have a plan to avoid re-bucketing. This verification is a check you must perform in your own environment.

  6. Cut over one environment at a time

    The release owner moves each LaunchDarkly environment to the EU provider in a fixed order, usually development, then staging, then a low-risk production service, and so on. Each cutover has a written rollback step that flips the OpenFeature provider configuration back to LaunchDarkly. Monitor error rates, evaluation latency and flag-change audit trails for each service during the window you agree in advance. The step is done when the environment has served production traffic from the EU instance with the agreed checks passing and a rollback test completed.

  7. Confirm data deletion with the US-hosted provider

    Before decommissioning, the privacy and procurement owners request written confirmation from LaunchDarkly of how and when evaluation data and account data in the US-hosted service will be deleted, and they check the answer against the data processing terms in the contract. Ask which data categories are covered, including monitoring and CDN data that LaunchDarkly describes as US-based, and what deletion evidence will be provided. The step is done when the deletion confirmation is filed with the data protection record for this system.

  8. Decommission the US-hosted service and keep the record

    Once all environments are served from the EU instance and the deletion confirmation is on file, the team removes the LaunchDarkly SDK keys from applications, revokes access tokens used for export, and cancels the subscription at the end of the agreed term. Keep the export files, comparison logs and cutover records under your own retention policy, since they are the evidence for later audits. The step is done when no service references the LaunchDarkly SDK, all tokens are revoked, and the decommissioning record is signed off by the system owner.

When Unleash, Flagsmith or GrowthBook fits best for residency

Choose by the workload, not by the logo. If the core need is release flags on a database your team already runs, Unleash fits best. Unleash runs against PostgreSQL 15 or later with the server and admin UI on port 4242, so the residency question reduces to where your Postgres instance and the Unleash container sit. Before committing, confirm which Unleash edition covers your needs: Open Source is limited to 1 project and 2 environments with basic roles, so a multi-team estate will need Enterprise for unlimited projects, SSO and SCIM. Also check the AGPLv3 change from v8.0.0 with your counsel if you plan to modify the server.

Choose Flagsmith when flags must sit alongside remote configuration and your identity controls need to be in place from day one. Its open-source core is BSD 3-Clause, but role-based access control and SAML single sign-on are Enterprise features that require a license, and the Flagsmith pricing page places SAML and governance features at the Scale-Up tier. Flagsmith's Helm chart creates its own PostgreSQL inside the cluster by default, so for an EU deployment, configure an externally managed, EU-hosted database and confirm that setting in your values file before go-live.

Choose GrowthBook when experiments must run against your own warehouse. GrowthBook issues only read-only SELECT queries against sources such as BigQuery, Snowflake or Postgres and transmits only aggregated statistics, so event-level personal data can stay in the EU warehouse you already govern. Metadata is stored in MongoDB or a compatible database, so confirm that database's region alongside the warehouse. Keep in mind that the self-hosted Open Source plan allows 1 project, and that sticky bucketing, holdouts and approval workflows are Enterprise features on the GrowthBook pricing page.

How DeployOpen deploys a self-hosted flag server under EU residency

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source flag platforms inside the client's own infrastructure, so flag definitions, evaluation data and admin access stay in an EU data center the client controls. The work starts with a written scope that names which platform, which region and which parts of the LaunchDarkly estate are in play.

How we scope

  • Map which LaunchDarkly services, environments and data flows must move, including the EU instance and any US-based monitoring or CDN paths you use today.
  • Confirm the target EU data center, the hosting model and which of Unleash, Flagsmith or GrowthBook fits the flag and experiment needs.
  • Agree deliverables, timelines and responsibilities in writing before any work starts, since most engagements are fixed-scope.

How we build

  • Deploy the chosen platform in your own cloud account or data center, backed by an externally managed PostgreSQL or MongoDB database as the platform requires.
  • Configure SSO, access roles and network controls, and test that flag evaluation and admin traffic stay inside the EU boundary you defined.
  • Run security testing of the deployed application and API, then harden the configuration before any production SDK traffic is routed to it.

How we hand over

  • Deliver architecture diagrams, data-flow records, runbooks and configuration documentation that show where each data type is stored and processed.
  • Provide evidence of residency controls and access settings that your internal teams or an independent auditor can review, noting that DeployOpen prepares evidence but does not issue audit reports.
  • Run a knowledge transfer session so your platform team can operate upgrades, backups and restores without depending on us.

How we support

  • Ongoing support, platform upgrades and continuous security testing are available as a retainer after handover.
  • Upgrades track each platform's release cycle, and we confirm version changes and license terms with you before applying them.
  • Confirm with your legal and procurement teams which support terms, response expectations and data processing terms apply to your retainer.

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