When is open source WSO2 API Manager enough, and when does a subscription pay for itself?
The open-source build of WSO2 API Manager is enough when your own platform engineering team can carry the gateway, control plane and traffic manager end to end, and the subscription is the stronger choice when someone outside your team must answer for support, patching and vulnerability monitoring. The repository confirms that WSO2 API Manager is licensed under Apache-2.0, so the code itself is not the variable. What differs is who is paid, and who is accountable, for keeping the platform current. Under the open-source build, your team pulls the release (4.7.0 was published on April 29, 2026, and building it requires JDK 21), tracks security fixes, tests upgrades and owns the outage when one goes wrong. The subscription covers expert support, continuous product updates, vulnerability monitoring and access to the licensed distribution for commercial use, as described in the repository.
Open source tends to fit when your organization already runs Kubernetes or VM estates, has engineers who can read the Java codebase and the Developer Portal and Publisher configuration, and can schedule upgrades without a contractual deadline. It also fits when the API programme is small enough that a support gap is tolerable. A subscription tends to pay for itself when a regulator, auditor or customer contract requires a named support path, a defined patch cadence or evidence that a vendor monitors vulnerabilities in the product you run. Ask your compliance lead which of those obligations apply, because a control that expects vendor-supplied advisories is not satisfied by a community mailing list. Cost is also one-time versus recurring: the open-source build carries recurring internal labor, while a subscription adds a recurring vendor fee. Confirm with WSO2 the exact coverage, response commitments, redistribution and commercial-use terms, and whether the distribution you receive is the same build you would test, since those terms are not set by the repository.
Which capabilities come with the open-source build and which come with a subscription
This table maps each WSO2 API Manager capability to what the Apache-2.0 open-source build provides and what a WSO2 subscription adds. Where the supplied documentation does not state the split, the cell tells you what to confirm with WSO2 before you commit. Use it to scope your own build against the support, updates and licensed distribution you would otherwise carry yourself.
| Capability | Open source build | WSO2 subscription |
|---|---|---|
| Control plane | Included in the Apache-2.0 repository as the API control plane | Commercial support and continuous product updates for the control plane; confirm the hybrid control plane terms with WSO2 |
| Gateway for routing, mediation and security | Included in the Apache-2.0 repository | Expert support, vulnerability monitoring and licensed distribution for commercial use; confirm gateway-specific entitlements |
| Traffic manager for throttling | Included in the Apache-2.0 repository | Covered by the same support and update channel; confirm whether any throttling feature is subscription-only |
| Developer Portal and Publisher | Included in the Apache-2.0 repository as web interfaces | Support and updates for both interfaces; confirm whether branding or customization support is included |
| REST, GraphQL and AsyncAPI support | Listed as supported in the repository | Support coverage for each API type; confirm which protocols WSO2 supports in its subscription scope |
| Custom authenticators, policies and workflows | Extensible in the open-source build; you build, test and maintain each extension | Support for the platform's extension points; confirm whether WSO2 reviews or supports custom extensions |
| On-premises deployment from packages | Extracted packages from the repository; you build with JDK 21 and manage the install | Licensed distribution for commercial use plus expert support; confirm the package and patch delivery process |
| Kubernetes deployment via WSO2 API Platform for Kubernetes | The API Platform components are Apache-2.0 except the Monetization module; confirm the exact Kubernetes components in scope | Separate WSO2 offering for Kubernetes; confirm whether it is covered by your subscription |
| Managed SaaS | Not available as part of the open-source build | Fully managed SaaS with a 99.95% SLA per WSO2's API Manager page; confirm current terms and what the SLA covers |
What each edition's license, support and update terms actually say
The open-source build and a WSO2 subscription share one codebase under Apache-2.0, but they differ in who answers when something breaks and who ships fixes. The four cards below separate the license grant, what a subscription adds, the upkeep you keep when you run the build yourself, and the contract terms that the public sources do not settle.
Apache-2.0 grants commercial use
The WSO2 API Manager repository is licensed under Apache-2.0, so your organization can run, modify and redistribute the open-source build in commercial settings without paying a license fee for the software itself. The license does not include vendor support, guaranteed patch timing or indemnity. Check whether your legal team reads the Apache-2.0 grant as sufficient for your internal use, and whether any custom authenticators, policies or workflows you write need their own review.
What a subscription adds
A WSO2 commercial subscription provides expert support, continuous product updates, vulnerability monitoring and access to the licensed distribution for commercial use. Those four items are the purchase. Ask the vendor to list which products, versions and environments the subscription covers, and whether the licensed distribution is a different artifact from the extracted open-source package you would otherwise build.
Build and upkeep you carry alone
The 4.7.0 release, published on April 29, 2026, requires JDK 21 to build. Running the open-source build means your team owns the JDK upgrade path, rebuilds after each release, tracks upstream fixes and tests gateway and portal changes before production. Estimate the staff time for those cycles as a recurring cost, and confirm the cadence you can sustain before you commit to self-maintenance.
Terms to confirm in writing
The supplied sources do not state support hours, response targets, severity definitions, indemnity or liability caps for a subscription. The hosted offering is described with a 99.95% SLA, but that applies to fully managed SaaS, not to self-hosted or hybrid use. Request these terms in writing, along with how vulnerability notices reach your team, before you compare cost with the open-source build.
How self-hosted, hybrid and SaaS deployment change who runs the platform
The deployment choice decides which parts of WSO2 API Manager your team operates. WSO2 documents three options for the platform: self-hosted from extracted packages on premises, hybrid with a SaaS control plane and on-premises gateways, and fully managed SaaS with a 99.95% SLA. In self-hosted mode, your team runs the Publisher, Developer Portal, gateway, traffic manager and the supporting databases, and it also owns patching, certificate rotation, backup and capacity planning. In hybrid mode, WSO2 hosts the control plane, while your gateways stay in your network, so the gateway placement, the data path and the upgrade windows for those nodes remain yours. In fully managed SaaS, the platform operations move to WSO2, and your team keeps API design, policy configuration, identity federation and the decisions about which backends and data sources the APIs can reach.
Three things stay with you under every option. The first is gateway placement and network paths: confirm where traffic enters, which backends each gateway can reach, and whether any call must stay on a private network segment. The second is data residency: ask WSO2 where API metadata, analytics and logs are stored for the hybrid control plane and the managed service, and which regions and subprocessors apply. The third is identity integration, because token issuance, claims mapping and any custom authenticators must work with your identity provider, whoever runs the control plane. Confirm these points in writing with WSO2 before you choose an option.
The 99.95% SLA applies to the fully managed SaaS service only. It does not cover a self-hosted deployment, and it does not cover the on-premises gateways in a hybrid model, which your team still operates. Ask WSO2 for the SLA document and the service credit terms, and ask what it excludes, such as maintenance windows and customer-side network faults. Map each availability commitment to a component you can actually observe. A self-hosted deployment that runs on the open-source code keeps the uptime burden on your team, and the subscription sets a support and update route rather than a managed availability guarantee. Plan your on-call rota and incident runbooks around the option you select.
Which team profile should build it and which should buy support
Teams that already run Java services and Kubernetes in production can absorb the open-source build. The WSO2 API Manager repository states that building the product requires JDK 21, so CI pipelines, container images and hardening baselines must target that runtime from the start. The team also takes on the work a subscription would otherwise cover: tracking releases such as 4.7.0, published on April 29, 2026, testing each upgrade against its own extensions and deciding which fixes to apply.
- Build and runtime: Pin JDK 21 in CI and container images, and rebuild from the tagged release.
- Upgrade testing: Your team owns regression tests for every custom authenticator, policy and workflow before each production upgrade.
- Patch intake: Your team monitors security issues, decides what to apply and records each decision.
- What a subscription changes: Expert support, continuous product updates and vulnerability monitoring move from your staff to the WSO2 contract.
- Wrong fit: The open-source build is the wrong choice if no one can own patch intake within your change window, or if Java and Kubernetes skills sit with a single person.
Confirm that your platform team can staff upgrade testing and patch intake on a fixed calendar before choosing the open-source build.
Regulated organizations often need a named vendor path for defects and security issues, plus dated records of how patches were handled. Source code under Apache-2.0 gives you full control of the software, but it does not by itself supply a contracted response. A WSO2 subscription adds expert support, continuous updates and vulnerability monitoring, along with access to the licensed distribution for commercial use. WSO2 also offers deployment choices that affect data flows and evidence: self-hosted on premises, hybrid with a SaaS control plane and on-premises gateways, and a fully managed SaaS service.
- Named support path: A subscription gives you a vendor contact for defects and security issues. The open-source build gives you that escalation path only if you staff it.
- Patch evidence: Vulnerability monitoring can supply dated records. With the build, your own tickets, test logs and change records become the evidence.
- Deployment fit: Self-hosted keeps the control plane inside your environment. Hybrid keeps gateways on premises while the control plane runs as SaaS, which needs a data-flow review.
- SaaS terms: WSO2 describes a 99.95% SLA for its fully managed service. Confirm the contractual terms in writing.
- Wrong fit: The open-source build is the wrong choice if your policy requires a supplier contract for every production component.
Ask WSO2 and your assessor which evidence each option produces. DeployOpen can prepare controls and evidence for an assessment, but independent auditors issue the attestation.
Organizations running several gateways face version drift, duplicated policies and separate upgrade calendars. WSO2 states that one control plane can manage WSO2 gateways and third-party gateways, including Kong, AWS, Azure and Envoy. That reach can simplify governance, but it also means your team must validate each connection and each gateway release. The subscription question here is scope: confirm whether support covers the third-party gateway connections or only the API Manager components.
- Control plane reach: Test the third-party gateway connections you depend on in a lab before you rely on them in production.
- Version drift: Each gateway has its own release line, so track upgrades per gateway and per control plane.
- Support scope: Ask in writing whether the subscription covers each third-party gateway connection.
- Operating load: The open-source build leaves your team owning every connector upgrade and its regression tests.
- Wrong fit: A single-gateway estate that already runs a gateway in production gains little from a control plane that spans several gateway types.
Before committing, write down which gateways must sit under one control plane and who owns each connection's upgrade.
What you pay for in each option and what drives the total
This table sets the cost components of a self-built Apache-2.0 WSO2 API Manager against a WSO2 subscription, row by row, so you can see who gets paid for what. Read each row as a question to put to your own team and to WSO2 before comparing totals, because the supplied facts do not include WSO2 subscription prices. The main takeaway is that the software license is the smaller decision for most teams; support, upgrade testing and staffing carry most of the recurring effort.
| Cost component | Open-source build | WSO2 subscription |
|---|---|---|
| Software license | Apache-2.0 license for the WSO2 API Manager repository, with no license fee for the code itself. Confirm the terms that apply to any bundled third-party components in your build. | Licensed distribution for commercial use, bought as a subscription. Ask WSO2 for the subscription price, term and which components are covered; prices are not in the supplied facts. |
| Support | No vendor support contract. Your team, DeployOpen under a written scope, or a third party covers troubleshooting and incident response. | Expert support included in the subscription. Ask WSO2 for response targets, support hours and escalation paths in writing before you rely on them. |
| Upgrades and patch testing | Your team or a services partner plans, builds, tests and rolls out each release, such as the 4.7.0 release that requires JDK 21. This effort recurs with every upgrade cycle. | Continuous product updates are included, but your team still tests them in your environment. Ask WSO2 how updates are delivered for your deployment model and what compatibility notes come with them. |
| Vulnerability tracking | Your team monitors advisories for WSO2 API Manager and its dependencies, then decides on fixes and emergency releases. Effort rises with the number of gateways and dependencies you run. | Vulnerability monitoring is part of the subscription. Ask WSO2 what is covered, how notices arrive and what turnaround applies to your deployment. |
| Infrastructure | You pay for compute, databases, load balancing, storage and backups in your own cloud, data center or air-gapped network. Sizing depends on traffic, gateway count and throttling needs. | Infrastructure for self-hosted or hybrid deployments is still yours. A fully managed SaaS option shifts hosting to WSO2, with a 99.95% SLA stated on WSO2's API Manager page; confirm its terms and scope in writing. |
| Staffing and training | Platform, security and integration staff need skills in API Manager, Kubernetes or the chosen runtime, and identity integration. Budget for onboarding time and for key-person risk. | Staff still need training to operate the product, but support access can shorten troubleshooting. Ask WSO2 what training and documentation are included with your subscription tier. |
| External implementation services | Fixed-scope work from DeployOpen or another partner covers planning, customization, hardening, integration, documentation and handover. Fees follow from a written scope, since DeployOpen does not publish a price list. | WSO2 services and partner services are separate purchases from the subscription. Ask whether any implementation work is included and request a written scope from each provider before comparing. |
| What drives the total | Number of gateways, environments, custom authenticators, policies and workflows, upgrade frequency, and how much patch testing you automate. | Subscription scope and term, deployment model (self-hosted, hybrid or SaaS), number of gateways, and how much of the operating work WSO2 takes on under the contract. |
How to move from the open-source build to a subscription, or back
This sequence gives you a tested path between a self-built WSO2 API Manager and a WSO2 subscription, with every API, extension and gateway accounted for before any traffic moves.
Inventory APIs, extensions and gateways
Your platform or API team lists every published API across REST, GraphQL and AsyncAPI, every custom authenticator, policy and workflow you have added, every throttling tier, and every gateway that enforces them. Record which extensions are your own code and which are configuration. Confirm the list with the API owners and the security team. The output is a versioned inventory that maps each API to its gateway, extension and consumer, so you know exactly what must move or be rebuilt.
Confirm subscription terms and distribution access
Procurement and legal confirm with WSO2 what the subscription covers: expert support, continuous product updates, vulnerability monitoring, and access to the licensed distribution for commercial use. Ask for the written terms that govern how the licensed distribution differs from the Apache-2.0 repository build, whether your current extensions are supported on it, and how a move back to a self-built distribution would be handled. The output is a signed statement of entitlements that the technical team can check against.
Classify what stays portable and what must be retested
Architecture and security review separates what carries over unchanged from what does not. API definitions, routing rules and consumer contracts are usually the most portable because they describe behavior, not packaging. Custom authenticators, policies and workflows need a compatibility check against the target distribution and its Java runtime, since the repository notes a JDK 21 build requirement. Gateway-specific configuration and third-party gateways in a mixed estate need full retesting. The output is a register marking each item as carry over, adapt or retest.
Plan the upgrade path across 4.x releases
The platform team sets the target version and the sequence of intermediate steps. Use the 4.7.0 release notes as the reference point for the current line, and confirm with WSO2 which 4.x release the subscription targets and whether any migration tooling or documented steps apply to your starting version. Schedule upgrades in a non-production environment that mirrors your extensions. The output is a written upgrade plan with a rollback checkpoint before each step.
Run parallel gateways for cutover
Deploy the target gateway alongside the current one, with the same APIs published and the same extensions loaded. Route a controlled share of non-critical traffic to the new gateway, then compare responses, throttling counts, authentication outcomes and logs against the baseline. Repeat with more traffic and more APIs until the mismatch rate is zero for agreed test cases. The output is a signed cutover test report that the API owners accept.
Document and rehearse the rollback path
Write the rollback runbook before the production change: the exact DNS, routing or gateway switch, how configuration and subscriptions are restored, who authorizes the switch, and the observable signals that trigger it. Rehearse the rollback in a staging environment at least once. Confirm that consumer credentials and throttling state survive the reversal. The output is a rehearsed runbook that operations staff can execute without the original authors present.
Cut over and retire the old gateway
Move production traffic in the window agreed in the runbook, monitor authentication errors, latency and throttling against the baseline, and keep the previous gateway warm until the agreed stability checks pass. Retire it only after the rollback window closes and the inventory is updated. The output is a closed change record with the final inventory, the entitlement statement on file, and a note of any extensions that were retested or rebuilt.
What buyers ask before choosing between the open-source build and a subscription
How much effort does running WSO2 API Manager yourself take?
Running the Apache-2.0 build yourself means your team owns installation, upgrades, patching, monitoring, backups and incident response for the gateway, control plane and traffic manager. The effort depends on how many environments you run, whether you deploy on premises from extracted packages or on Kubernetes, and how often you take new releases. The repository notes that building the product from source requires JDK 21, so your build pipeline needs that runtime from the start. Ask your platform team to size the work against the upgrade cadence you expect, and to name who watches for vulnerabilities in the components you ship.
Can a team run WSO2 API Manager without outside help?
A team with strong Java, container and API operations skills can run the open-source build without an outside partner, provided it has someone accountable for upgrades and security fixes. The gaps usually appear in less common areas: diagnosing gateway performance under load, customizing authenticators or workflows, and keeping pace with releases. The product repository describes extension points for custom authenticators, policies and workflows, so custom work is possible but needs ownership. DeployOpen plans, implements, hardens, backs up, upgrades and supports self-hosted open-source platforms inside your infrastructure under fixed-scope agreements or retainers, which is one option if your team lacks that capacity.
What does a WSO2 subscription include beyond the distribution?
According to WSO2's repository, a commercial subscription provides expert support, continuous product updates, vulnerability monitoring and access to the licensed distribution for commercial use. Those four items are the core of what you pay for, and each one replaces work your team would otherwise do. Ask WSO2 for the written list of support channels, response expectations, the update and patch policy, how vulnerabilities are notified, and whether the subscription covers the deployment model you choose. Confirm subscription pricing and SLA terms directly with WSO2, because the figures you see on marketing pages may depend on deployment model and tier.
Does the Apache-2.0 license allow commercial use of WSO2 API Manager?
The repository states that WSO2 API Manager is licensed under Apache-2.0, which permits use, modification and redistribution, including commercial use, subject to the license terms. The license does not include vendor support, guaranteed patch timelines or vulnerability notifications, so those are the parts you must provide yourself or buy separately. WSO2 also states that its API Platform components are Apache-2.0 except the Monetization module, so check which modules you plan to use before assuming the whole stack carries the same terms. Have your legal and procurement teams review the license text and the module list for your exact design.
What work does a switch between the open-source build and a subscription involve?
Moving between the two generally keeps the same product code, so the main work is in operations rather than in rewriting APIs. Changes usually cover how you obtain the licensed distribution, how you schedule upgrades and how support and vulnerability notices reach your team. Your APIs, policies, subscriptions and developer portal content live in the platform's stores, so plan a backup and restore rehearsal before any change of distribution or deployment model. If you also move to hybrid or SaaS control planes, expect additional work on gateway placement, network paths and identity configuration. Ask WSO2 which migration steps it supports for your version and deployment model.
How does the deployment model change the cost?
The deployment model changes which costs you carry. WSO2 describes three choices: self-hosted, hybrid with a SaaS control plane and on-premises gateways, and fully managed SaaS with a 99.95% SLA. In self-hosted use, you pay for infrastructure, staff time for operations and the subscription if you choose one. In hybrid use, you run the gateways and keep API traffic inside your network while the vendor operates the control plane. In managed SaaS, most operating work moves to the vendor, and the 99.95% SLA is the figure to verify in the contract. Ask for a quote that separates each of these components and the recurring fees for each option.
How should a quote for the open-source build and a subscription be compared?
Compare quotes by total annual and one-time components rather than headline license figures. The open-source build has no license fee, but it carries one-time setup, integration, hardening and documentation work, plus recurring staff time for upgrades, monitoring and security response. A subscription adds a recurring fee that covers support, updates, vulnerability monitoring and distribution access. Ask each vendor, including DeployOpen if you engage it, for a written scope with deliverables, assumptions, exclusions and the environments covered. Confirm subscription pricing and SLA terms with WSO2 directly, since those depend on tier, deployment model and scope.
How DeployOpen scopes implementation on either edition
DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms inside your own infrastructure, whether that is your cloud accounts, data centers or air-gapped networks. The same scope applies whether you run the Apache-2.0 WSO2 API Manager yourself or add a WSO2 subscription, because the work sits around the product: deciding where the control plane, gateways and traffic manager run, wiring identity and logging, setting up the Publisher and Developer Portal for your teams, and writing the runbooks your operators will use. Most engagements are fixed-scope, so the scope, deliverables and timelines are agreed in writing before any work starts, and the written scope is the basis for a quote. DeployOpen does not publish a price list.
Ask for the scope to name which WSO2 deployment model you are building, since the work differs between self-hosted, hybrid with a SaaS control plane and on-premises gateways, and fully managed SaaS. Confirm with WSO2 which of these your subscription covers and what the vendor delivers directly, such as product support and vulnerability notices, so the statement of work does not duplicate or leave gaps. Check the WSO2 API Manager product page for the current deployment options before you fix the scope. Ask the implementation partner to state the upgrade path for the version you choose, including how the work would change when a new release such as the one noted in the WSO2 API Manager 4.7.0 release is adopted.
Ongoing support, upgrades and continuous testing are available as retainers, which is the usual way to cover the period after go-live. Retainer scope should be written as explicitly as the implementation scope: response expectations, which upgrades are included, who applies security patches and how they are tested, and whether the retainer covers the gateways your subscription manages. DeployOpen is not a WSO2 partner, reseller or certified provider, so it cannot sell or bundle a WSO2 subscription, and it does not hold partner status with WSO2 unless that is stated in a supplied fact. DeployOpen also does not issue audit reports, attestations or certifications. Where your assessors need evidence of controls, DeployOpen prepares the systems, controls and records, and the independent auditor or certification body makes the judgment.
How DeployOpen scopes, delivers and supports WSO2 API Manager
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, so WSO2 API Manager runs in your cloud account, data center or air-gapped network. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- The written scope names which WSO2 API Manager components are in play: control plane, gateway, traffic manager and the Developer Portal and Publisher.
- It records the deployment model chosen (self-hosted, hybrid with on-premises gateways, or another path) and the hosting environment you control.
- It lists the APIs in scope, including REST, GraphQL and AsyncAPI definitions, and any custom authenticators, policies or workflows you need.
How we build
- We build from the Apache-2.0 source or extracted packages, confirming the JDK 21 build requirement noted for the 4.7.0 release before any work begins.
- We configure gateways, throttling tiers and identity integration, and develop agreed custom extensions in your own repositories.
- We test routing, mediation, security and throttling behavior against the acceptance criteria in the written scope before handover.
How we hand over
- Deliverables include deployment runbooks, configuration records, architecture notes and the upgrade and backup procedures for your team.
- We walk your operators through daily administration, API publishing and troubleshooting so the platform does not depend on us alone.
- We document which items remain your responsibility, including licensing decisions and any subscription you choose to hold with WSO2.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, agreed separately from the initial fixed-scope work.
- Upgrade work follows the release notes for each WSO2 API Manager version, and we confirm extension compatibility before applying it.
- Ask in any quote whether WSO2 subscription support, updates and vulnerability monitoring are needed alongside our retainer, and who holds each responsibility.
