Proven with Industry Leaders
Ask one question. The rest follows.
Can your compliance regime tolerate API definitions, policies, and lifecycle metadata living in a vendor-operated SaaS?
If yes, Bijira with private data planes gives you SaaS-operated management with API traffic that never leaves your perimeter. If no, because of data sovereignty mandates, air-gapped environments, or a no-third-party-control-plane policy, self-hosted WSO2 API Manager is the defensible path.
Both are WSO2. Both are supportable. The difference is not capability. It is where the most privileged component in your API estate lives, and who operates it. Everything below exists to help you answer that one question with evidence rather than instinct.
The decision at a glance
| What to test | Bijira with a private data plane | Self-hosted WSO2 API Manager |
|---|---|---|
| Control plane | WSO2-operated SaaS. | Runs where you deploy it, operated by your team. |
| API traffic and payloads | Private data plane in your VPC or on-premises, or WSO2-hosted. | Your infrastructure. |
| Definitions, policies, lifecycle state | Held in WSO2’s cloud. | Inside your boundary. |
| Logs and runtime telemetry | Retained in your private data plane. | Retained in your infrastructure. |
| Patching and upgrading the management layer | WSO2. | Your team or a support partner. |
| Inside your EDR, SIEM, and incident response | The control plane is not. | Yes. |
| Air-gapped or no-third-party-control-plane policy | Not a fit. | Fit. |
| Choose it when | Your regime accepts vendor-held management metadata. | Sovereignty law, an air-gap mandate, examiner precedent, or institutional policy says no. |
One platform became a portfolio.
In 2025, WSO2 reorganized its product line. Choreo, previously a single platform covering API management, integration, and developer tooling, was split three ways. Its API management became Bijira. Its integration workloads became Devant. Choreo itself was refocused as an internal developer platform, released open source as OpenChoreo. The result: every layer of the WSO2 platform now ships in two deployment models.
Bijira is not a replacement for API Manager. API Manager remains fully supported, actively developed, and, for a class of regulated deployments, the only acceptable answer. Bijira is the same capability lineage delivered as a service. Which one you should run is an architecture and compliance decision, not a product-roadmap one.
Control plane, data plane, and which side of your firewall each sits on.
Bijira separates management from runtime. The control plane, where APIs are defined, policies are set, and lifecycle state is managed, runs as WSO2-operated SaaS. The data plane, the gateways your API traffic actually flows through, can run as WSO2-hosted SaaS, in your own cloud VPC, or on-premises as a private data plane. In the private data plane model, three properties matter for a regulated review:
Traffic stays inside your boundary
Requests, responses, and payloads move through gateways you host. They do not transit WSO2’s cloud.
Communication is outbound-only
Your data plane initiates every connection to the control plane. Nothing listens for inbound connections from the internet.
Logs and observability stay home
Runtime telemetry is retained in your data plane, not shipped to the vendor.
What remains in WSO2's cloud is the management metadata: your API inventory, definitions, policies, and configuration. For many institutions that is acceptable. For some it is a hard stop. Knowing which you are, before contracts are signed, is the entire game.
Self-hosted API Manager collapses the question: control plane and data plane both run where you put them, operated by your team, inside your detection and response perimeter.
Make the control plane a proposer, not the source of truth.
A Bijira deployment for a regulated enterprise should not accept the control plane's word as final. These are the controls that make the architecture defensible:
Declared state outside the vendor
API definitions and policies live in your repository. Changes flow through your CI/CD with approvals. The control plane executes decisions; it does not originate them.
Continuous drift detection
Compare what your data plane is actually running against declared state. A malicious or accidental change pushed from the control plane surfaces as unexplained drift in minutes, not in post-incident forensics.
Egress allow-listing
Your data plane can reach the control plane endpoints and nothing else. A rogue proxy cannot call out to arbitrary infrastructure.
Policy-change alerting
Any weakening of an authentication policy or any new backend endpoint is treated as a change-management event with a named approver, not a routine sync.
Scoped, short-lived credentials
A stolen control-plane credential should not grant indefinite authority over your runtime.
Vendor diligence in writing
SOC 2 scope covering the Bijira control plane specifically, tenant isolation model, detection capability, and breach notification terms.
Every one of these produces the artifact a regulated review actually asks for: who changed what policy, when, authorized by whom. That evidence layer is the same discipline we build into AI agent governance on WSO2: the control plane is simply another privileged identity to govern. What that layer must enforce once model and agent traffic flows through it is set out in our guide to the AI gateway. And it is operational work: drift detection, alerting, and credential hygiene need an owner, which is where our WSO2 support and managed services practice carries the load.
Some perimeters don't take tenants.
If the assessment lands on no, whether from sovereignty law, air-gap mandate, examiner precedent, or institutional policy, self-hosted WSO2 API Manager is not a consolation prize. It is the same product lineage with the control plane inside your boundary, your tooling watching it, your team operating it. Current releases add a unified control plane across gateway estates, so a self-hosted deployment is not a step backward in manageability.
The cost is real: you own patching, upgrades, scaling, and the security operation around the management layer. That is precisely the work our support and managed services practice carries, so the self-hosted path does not have to mean building a platform team from scratch.
And the two paths are not forever. Estates migrate: self-hosted to Bijira as postures relax, Bijira to self-hosted when regulation tightens. We design so the declared state (your APIs, your policies, in your repo) survives the move in either direction.
Advice that isn't shaped by the sale.
Our WSO2 consulting practice delivers Bijira and self-hosted API Manager, and the support practice behind both. The recommendation you get is the one we would defend in front of your examiner, because we are usually the ones standing next to you when it is examined.
- → We deliver both paths. Our advice isn’t shaped by which one we can sell.
- → Regulated by default. Seven years of WSO2 delivery in data-residency-constrained, audited environments.
- → Evidence-first. Every design produces the audit trail an examiner asks for, designed in, not bolted on.
- → The full portfolio. API Manager, Bijira, Devant, WSO2 Integrator, Identity Server, and WSO2’s agent layer, under one team.
The deployment decision, answered plainly.
What is Bijira, and how is it different from WSO2 API Manager?
Bijira is WSO2’s AI-native API management SaaS; WSO2 API Manager is the self-hosted platform it is built from. They share the same lineage, but Bijira’s control plane is operated by WSO2 in the cloud, while API Manager’s runs wherever you deploy it. Duczer East supports and delivers both.
Is Bijira replacing WSO2 API Manager?
No. API Manager remains fully supported and actively developed, and for a class of regulated deployments it is the only acceptable answer. Bijira is the same capability lineage delivered as a service. Which one you run is an architecture and compliance decision, not a product-roadmap one.
Can Bijira run on-premises, and does that satisfy data residency requirements?
Bijira can run private data planes in your own VPC or on-premises, with outbound-only communication, while the control plane remains WSO2-hosted SaaS. For API traffic and logs, that generally satisfies residency: they remain in infrastructure you host, in the jurisdiction you choose. For management metadata, it depends on your regulator’s definition of in-scope data. Organizations that cannot accept a vendor-hosted control plane should run self-hosted WSO2 API Manager. We map your specific residency obligations against Bijira’s architecture before recommending it, not after.
Should we migrate from WSO2 API Manager to Bijira?
Only if your compliance regime can accept a vendor-operated control plane and the move solves a problem you actually have. Running API Manager today is not by itself a reason to move. If you do migrate, keep API definitions and policies as declared state in your own repository, so the move is a project rather than a rebuild and can be reversed if regulation tightens.
What happened to WSO2 Choreo?
Choreo was split into three products in 2025: its API management became Bijira, its integration workloads became Devant, and Choreo itself was refocused as WSO2’s internal developer platform. It is now also available open source as OpenChoreo. If you run a legacy Choreo deployment, we can map your workloads to the right successor and manage the transition.
What is Devant by WSO2?
Devant is WSO2’s AI-native integration platform as a service (iPaaS), the SaaS counterpart to self-hosted WSO2 Integrator. It covers automations, event-driven and file-based integration, AI agents with MCP tool access, and RAG data ingestion into vector databases. We support Devant alongside the self-hosted integration stack.
What metadata does Bijira keep in WSO2’s cloud when using a private data plane?
Management metadata: API definitions and inventory, policies, lifecycle state, and configuration. Runtime traffic, payloads, and logs stay in your private data plane. Whether that split satisfies your regime is the core assessment question. For some regulators it is acceptable; for sovereignty-constrained environments it is disqualifying.
Can a compromised control plane affect our in-house runtime?
Yes. That is the trust model’s central fact. Outbound-only communication prevents inbound network attacks, but your data plane executes instructions the control plane sends. That is why we design Bijira deployments with declared state outside the vendor, drift detection, and policy-change alerting, so the control plane proposes and your pipeline disposes.
Can we start on Bijira and move to self-hosted API Manager later, or the reverse?
Yes, if the deployment is designed for it. Keeping API definitions and policies as declared state in your own repository, rather than living only in the vendor console, is what makes migration in either direction a project instead of a rebuild. We design for that portability from day one.
Is Bijira mature enough for production in a regulated enterprise?
Bijira launched in 2025 and is evolving quickly. Capabilities like on-premises private data planes should be verified at current maturity, not from launch-era messaging. As a WSO2 partner we validate the current state of the specific features your architecture depends on, directly with WSO2, before they go into a design.
How does this decision interact with AI and agent traffic?
Directly. Bijira includes AI gateway and MCP management capabilities, so choosing it also chooses where your agent-to-model and agent-to-API governance layer lives. The governance requirements (which agent, which tool, whose authority, where’s the record) are identical either way; the deployment decision determines whether that enforcement point is in-perimeter or vendor-hosted.