Bijira or self-hosted API Manager? It comes down to one question.
WSO2 now ships API management two ways — a SaaS with a WSO2-hosted control plane, and software you run entirely yourself. Feature lists won't settle the choice. Your compliance posture will. Here is the honest framework.
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 — 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.
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.
Your runtime is only as sovereign as its most privileged remote administrator.
Outbound-only architecture is real security engineering — it eliminates inbound network attack paths. But it does not eliminate trust. Your data plane phones home precisely to receive instructions: policy updates, API deployments, configuration changes. The connection direction is reversed; the authority relationship is fully intact.
That means the control plane must be treated as what it is — a privileged administrator of your runtime. A compromise there does not need to breach your network. Your own gateways would faithfully execute whatever a compromised control plane tells them: weakened authentication policies, altered routing, new proxies exposing internal backends. This is the supply-chain attack shape, and it applies to every SaaS control plane in the industry — it is not a Bijira flaw. It is the architecture of the era, and it deserves an explicit answer in your design rather than a shrug.
The honest counterweight: a self-hosted control plane has the same logical attack surface, defended by your team instead of WSO2's. For many organizations, WSO2's security operation is stronger than what they could staff. The difference is that a vendor SaaS is a concentrated, shared target sitting outside your EDR, your SIEM, and your incident response. You are not choosing between risk and no risk. You are choosing whose risk model you can defend in front of an examiner.
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, any new backend endpoint — 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 — the control plane is simply another privileged identity to govern. 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 — 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.
We deliver 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 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.
Does a private data plane satisfy data residency requirements?
For API traffic and logs, generally yes — 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. We map your specific residency obligations against Bijira’s architecture before recommending it, not after.
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.
Answer the question with evidence.
A fixed-scope deployment-model assessment: your regulatory obligations mapped against both architectures, the trust-model analysis your CISO will ask for, and a defensible recommendation — in writing, ready for the review board.
Already running one of them and need help keeping it sound? That is our support practice — same team, same conversation.