Open-source alternative to MuleSoft Omni Gateway

Replacing Omni Gateway when your team needs to own the gateway tier

Apache APISIX or the open-source edition of Kong Gateway can replace Omni Gateway as a self-run data plane, with the control plane and policy management moving out of Anypoint and into tooling your team operates. Omni Gateway runs in Connected Mode, where Anypoint API Manager and Runtime Manager hold policies and deployment state, or in Local Mode, where local configuration files drive the gateway and it contacts MuleSoft only for registration and usage metrics. If your renewal or data residency concern is about where traffic flows and who operates the gateways, both options keep requests inside your own Docker hosts, Kubernetes clusters or Linux servers. The trade is that you take on what Anypoint provided: a hosted policy catalog, a consumer-facing portal and one place to see every gateway.

The first gap is the control plane. Nothing in APISIX or Kong Gateway OSS replaces the Anypoint API Manager interface, so client applications, access and policy inventory need a new home, usually a developer portal or a spreadsheet of record until one exists. APISIX offers its Admin API on port 9180 in traditional mode, and its standalone deployment mode reads conf/apisix.yaml and hot-reloads it without a restart. Kong's DB-less mode takes declarative files that can live in Git, with decK to dump and sync them. Map each Omni policy to a plugin during a pilot and record every policy with no equivalent. Database-dependent plugins such as cluster-strategy rate limiting need Kong's traditional mode, so a DB-less design may rule out some limits you rely on today. Confirm the rate-limiting, JWT and OAuth behavior you need against current plugin documentation before you commit.

The second gap is governance. Without Anypoint, promotion, approval and rollback move into Git and your CI/CD pipeline: review gateway configuration as code, validate it, deploy to staging and keep the Kubernetes resources next to the services they front. The Kong Ingress Controller is Apache-2.0 licensed, and APISIX has its own ingress controller, so either option can sit in the same delivery flow. Patch ownership changes as well. Kong's version support policy applies only to Kong Gateway Enterprise, so the OSS edition has no published support window to plan against, and the APISIX downloads page does not mark its 3.19.0 release as long-term support. Ask each vendor, and your own security team, who will ship security fixes, how quickly and through which channel. Then assign the upgrade and on-call work that MuleSoft previously carried.

How Omni Gateway capabilities map to APISIX and Kong Gateway OSS

This table maps each Omni Gateway capability to its closest equivalent in Apache APISIX and Kong Gateway OSS, with notes on where the open-source option needs a different deployment mode or where the feature lives outside the gateway. Read the coverage column first, because the gaps are mostly about the management layer rather than request handling.

Capability	Apache APISIX	Kong Gateway OSS	Coverage note
Connected Mode (control plane managed centrally)	Traditional or decoupled mode with etcd as the shared configuration store	Hybrid mode with a self-run control plane, or Konnect with a Kong-hosted control plane	Anypoint API Manager and Runtime Manager have no direct open-source equivalent in the gateway alone. Plan a separate control plane or accept Git-based configuration.
Local Mode (file-based configuration)	Standalone mode reads conf/apisix.yaml or conf/apisix.json and hot-reloads on change	DB-less mode reads declarative files that can be kept in Git and exposes a read-only Admin API	This is the closest match to Omni Gateway Local Mode. Confirm that your team's file layout and reload checks suit your change process.
Policy enforcement (routes, transforms, request rules)	Routes and plugins configured through the Admin API or YAML, with more than 100 built-in plugins	Routing, transformation and request plugins listed in the Kong Gateway README, applied per service or route	Map each Omni policy to a named plugin and test behavior on sample traffic. Some Mule policy parameters will not have a one-to-one field.
Authentication (OAuth, JWT, OIDC)	openid-connect plugin works with Keycloak, Auth0, Microsoft Entra ID, Google and Okta, including PKCE	JWT, basic auth, OAuth and ACL plugins; OAuth2 plugin depends on database-backed traditional mode	For Kong, OAuth2 and cluster-strategy rate limiting require traditional mode with a database. DB-less deployments need a different token pattern.
Rate limiting and traffic control	Traffic control plugins with hot-reloaded limits in a running gateway	Rate limiting plugin; cluster-strategy limits need traditional mode with a database	In a multi-node Kong DB-less fleet, limits stay local to each node. Confirm the required accuracy across nodes before cutover.
Kubernetes and Docker deployment	APISIX Ingress Controller for Kubernetes and Docker images; release 2.2.0 published August 18, 2026	Kong Ingress Controller (Apache-2.0, v3.5.13 on August 7, 2026) and Docker or Docker Compose installs	Omni Gateway runs on Docker, Kubernetes and several Linux distributions. Both open-source options cover these targets, but confirm the operating system matrix for your estate.
Observability and logging	Plugin-based logging and metrics exposure; integrate with your own Prometheus and log stack	Logging and metrics plugins; integrate with your own Prometheus and log stack	Anypoint Analytics dashboards and usage contracts are not part of either gateway. Expect to build dashboards in your own monitoring stack.
Versioning and support window	Latest release 3.19.0 on September 28, 2026; no long-term support line is marked on the downloads page	Latest OSS line is 3.9 (3.9.4 on October 12, 2026); no published support window for the OSS edition	Neither open-source project offers a vendor support window. Budget for an internal upgrade process or a paid support contract, and ask vendors to confirm terms.

Apache APISIX or Kong Gateway OSS: which fits which team

Both gateways can take over the proxy role that Omni Gateway plays in Local Mode, and both are Apache-2.0 licensed. The choice comes down to how your team manages configuration, which plugins and languages you need, and how much you depend on a commercial control plane for governance.

Apache APISIX for dynamic, etcd-backed routing

APISIX fits teams that change routes and plugins often and want them to take effect without restarts. It runs in traditional mode with etcd and an Admin API on port 9180, in decoupled mode with a shared etcd cluster, or in standalone mode driven by a YAML or JSON file that reloads every second. It offers more than 100 built-in plugins, and custom plugins can be written in Lua or through plugin runners in Java, Go and Python. Check that your chosen mode matches your change process, and confirm which plugins your Omni policies need before you commit.

Kong Gateway OSS for declarative GitOps

Kong suits teams that want a DB-less gateway whose full configuration lives in declarative files in Git. The deck gateway dump command exports configuration, and decK syncs files to open-source Kong Gateway. DB-less mode has no database, but database-dependent plugins such as cluster-strategy rate limiting and OAuth2 need traditional mode. Confirm this before you map Omni policies one for one.

Kong Ingress Controller for Kubernetes

Teams running Omni on Kubernetes often want their ingress and gateway managed the same way. The Kong Ingress Controller is Apache-2.0 licensed and is Kong's official controller for Kubernetes. Apache APISIX also ships an ingress controller, so compare how each one reads your Kubernetes resources and how upgrades are tested in your cluster. Check the release you plan to pin, not only the latest tag.

Kong OSS release line and support gap

The latest open-source Kong Gateway releases on GitHub are in the 3.9 series, while Kong Gateway Enterprise has moved to newer quarterly releases. Kong's version support policy covers only Enterprise, so no published support window exists for the open-source edition. Plan for your own patching, testing and backporting, or confirm an arrangement with a support provider in writing before you standardize on it.

Control plane limits in the open edition

Kong Konnect and Kong's self-hosted control plane with a local data plane are part of Kong Gateway Enterprise. A team that wants a central dashboard, RBAC over many gateways or a self-hosted control plane must budget for Enterprise or build those functions. APISIX's Dashboard and Admin API cover some of this, but confirm the access control and audit features your governance rules require. This gap replaces the Anypoint API Manager role.

Language and plugin extension effort

APISIX lets engineers write custom logic in Java, Go or Python through plugin runners, and in WebAssembly, which may suit teams that already maintain services in those languages. Kong extends through its plugin model and Lua-based plugins. Count the custom Omni policies or DataWeave-style logic you must reproduce, and assign each one to the language your team can maintain after the migration.

Choosing traditional, decoupled, standalone or DB-less deployment

For a proof of concept, the goal is to see how routes, plugins and authentication behave against your own services with the least operational weight. Both products can run this way on a single host using Docker, so the choice is less about scale and more about how you want to manage configuration from day one. Keep the evaluation close to the topology you expect to run later, because switching modes after you have built policies means rewriting configuration.

APISIX traditional mode: Runs the data plane and control plane together with etcd. Client traffic arrives on port 9080 and the Admin API on port 9180, so expose the Admin API only to your test network.
APISIX standalone mode: Needs no etcd. Routes live in a file such as conf/apisix.yaml, which is a simple way to keep the evaluation in Git.
Kong DB-less mode: Needs no database. Declarative files define the configuration, and the Admin API is read-only.
Kong traditional mode: Uses a database and supports database-dependent plugins such as cluster-strategy rate limiting and OAuth2, so test those plugins only if you plan to use them.
Plugin coverage: Confirm that every plugin your policies depend on works in the mode you choose, since some features are tied to a database.

Before leaving the evaluation, confirm which mode you will run in production and test your policy set in that mode, not in a different one.

Air-gapped networks and remote edge sites often cannot reach a central control plane reliably, so the deployment must keep working when the link is down. This is where the standalone and DB-less options matter most, because the gateway reads its configuration locally. Plan the update path as carefully as the runtime, since changes must be packaged, moved across the boundary and verified on site.

APISIX standalone mode: Reads conf/apisix.yaml or conf/apisix.json and checks for changes every second, then hot-reloads without restarting. Updating a file on a disconnected node therefore takes effect without a restart.
Kong DB-less mode: Keeps configuration in declarative files that can be signed, copied and reviewed offline, with no database to maintain at each site.
Control plane dependencies: Traditional and decoupled APISIX modes depend on etcd, so a site that loses connectivity to it cannot receive new configuration.
Commercial dependencies: Confirm whether the Kong features you need require a connection to Kong's services, since the commercial self-managed offering is a separate license decision.
Packaging and provenance: Build configuration bundles in a controlled environment and keep a record of what was deployed where.

Before you approve a design, ask how a configuration change reaches each site, how a rollback works without the network, and who can authorize it.

Migrating Omni Gateway policies to self-run gateways

This sequence moves each Omni Gateway policy, route and deployment to a self-run gateway in a controlled order, so you finish with declarative configuration in Git, verified traffic on the new gateway and no remaining Connected Mode registrations. It is written for platform and API teams who will own the gateway after cutover.

Inventory Anypoint policies and gateway deployments
The platform owner and the API owners list every gateway instance registered in Runtime Manager, every API instance in Anypoint API Manager, and every policy attached to each instance, including its version, order and scope. Record which instances run in Connected Mode and which in Local Mode, since Local Mode gateways may already keep their configuration in local files. The step is done when each API has one row listing its upstream, client credential model, rate limits, transformations and owning team. Anything without an owner goes into a separate list for decision before the mapping starts.
Export API specifications and policy settings
The API team exports the API specifications and the exact policy configuration for each instance, keeping the values that drive behavior such as limits, time windows, header names, allowed origins and token validation settings. Store these exports in the same Git repository that will hold the new gateway configuration, so every later change is traceable. Confirm with MuleSoft which export formats your account and version allow, because the available formats depend on your Anypoint setup. The step closes when a reviewer can rebuild each API's policy set from the files alone.
Map each policy to a gateway plugin
The gateway engineer maps every exported policy to a plugin in the target gateway. For Apache APISIX, check the built-in plugin list for authentication, traffic control and transformation equivalents. For Kong Gateway, check the plugin catalog for the same functions, and note which plugins need a database, since DB-less mode excludes some of them. Anypoint-specific policies may have no one-to-one plugin, so mark those as gaps, decide whether to reimplement them as a custom plugin or move the logic upstream, and record the decision with its owner. The step is done when every policy has a target, a gap, or a retirement decision.
Write declarative configuration and review it in CI/CD
The platform engineer writes the routes, upstreams, consumers, plugin settings and certificates as declarative files, such as the APISIX configuration in standalone mode or Kong's decK files for DB-less Kong Gateway. Each change goes through a merge request, automated validation and a review by someone who did not write it. Secrets stay out of the files and come from your secrets store at deploy time. The step closes when a pipeline can deploy the configuration to a non-production gateway and the result matches the mapping sheet.
Run both gateways in parallel and shift traffic
The operations team runs the new gateway alongside the Omni Gateway and routes a small share of test traffic through it, widening the share only after logs, error rates and latency look equivalent. Compare authentication outcomes, rate limit responses and transformed payloads between the two paths, using the same test cases that the mapping sheet lists. Hold a rollback path where the old route remains ready to receive traffic. The step is complete when the new gateway carries all production traffic for an agreed observation period that your change process sets.
Cut over and remove Connected Mode registrations
After the observation period, the owner switches DNS or the upstream load balancer to the new gateway and records the change in the migration log. Then the team removes the Omni Gateway registrations from Runtime Manager, retires the Anypoint API Manager instances no longer in use, and revokes the Connected Mode credentials used by the gateways. Confirm with MuleSoft how your contract handles these instances before deleting anything. The step closes when no Omni Gateway reports to Anypoint and every API is served only by the new gateway.
Decommission old instances and document ownership
The platform team shuts down the Omni Gateway nodes, removes their certificates and access paths, and updates the runbooks, architecture diagrams and on-call routes to name the self-run gateway. The team also confirms which upgrade and security patch process now applies, since no vendor manages the gateway after this step. The output is a short ownership record listing each API, its gateway owner and the location of its configuration in Git. The step is done when the old nodes are gone and the on-call team has tested a rollback from the documentation alone.

Running the new gateway alongside CloudHub and Runtime Fabric

Most teams will not move every Mule application at once, so the gateway tier often changes while the integration runtimes stay where they are. The cards below cover the traffic path, the design-time split, and what happens to the metrics Omni Gateway sends to the control plane when it is replaced. Each item is a decision or check to make before the gateway cutover, not a reason to expect a particular result.

Keep Mule apps on their current runtime

CloudHub 2.0 and Runtime Fabric are MuleSoft-managed or customer-managed runtimes that can keep running while only the gateway tier changes. Before cutover, confirm which Mule applications sit behind Omni Gateway policies today, since some may depend on gateway-injected headers, client ID enforcement or rate limits that Apache APISIX or Kong must reproduce. Record the upstream hostnames and ports each application expects, because those become the upstream definitions in the new gateway's configuration. Test the new path with one non-critical API first.

Route traffic through the open-source gateway

In the target design, clients call the new gateway first, and the gateway forwards requests to the Mule APIs running on CloudHub 2.0, Runtime Fabric or your own servers. Define each route with its upstream address, then add authentication and rate limiting plugins in the same order the Omni Gateway policies ran. Check TLS between the gateway and each upstream, since certificates that Omni Gateway trusted may not be trusted by the new gateway without explicit configuration. Confirm that health checks mark a failed Mule replica as unavailable.

Decide what stays in Anypoint

Anypoint Exchange, API design tools and Anypoint Studio can remain in use while the gateway moves, which makes the exit gradual. Specifications in Exchange still describe the APIs, but no runtime enforces them once Omni Gateway is removed, so the specification and the gateway configuration can drift apart. Assign one owner for each API's OpenAPI or RAML source of truth, and decide whether that source lives in Git. Ask MuleSoft to confirm what your contract allows for Exchange and Design Center after the gateway is retired.

Plan for lost Connected Mode metrics

In Connected Mode, Omni Gateway reports usage and status to Anypoint API Manager and Runtime Manager, so dashboards and analytics depend on that feed. Once traffic moves to APISIX or Kong, those dashboards stop receiving gateway data, and historical trends stay in MuleSoft. Replace the signal with metrics from your own stack, such as Prometheus for request counts and latency, and keep the old dashboards read-only for audit until the retention you need has passed. Ask your security team which usage records they must keep.

Run both gateways during cutover

During migration, DNS or a load balancer can split traffic between Omni Gateway and the new gateway by route or by client. Running both in parallel lets you compare error rates, latency and authentication outcomes before retiring the old path. Keep Omni Gateway in Local Mode or Connected Mode as it was until the last route moves, since changing its mode mid-cutover adds a second variable. Define rollback steps for each route in writing before the first switch.

What does it cost and take to replace Omni Gateway?

What are the cost components of replacing Omni Gateway with a self-hosted gateway?

The cost splits into five components: software licenses, infrastructure, implementation, testing, and ongoing operations. The open-source gateway itself carries no license fee, but the MuleSoft Omni Gateway subscription you stop paying is only one line item. Infrastructure is the compute, load balancers, and etcd or database nodes you run in your own cloud or data center. Implementation covers translating policies, building the CI/CD pipeline, and deploying to Docker or Kubernetes. Testing covers regression runs against live traffic patterns. Operations covers upgrades, patching, certificate rotation, and on-call. Ask your MuleSoft account team and each open-source vendor to confirm exactly which license tier, support terms, and deployment modes your environment needs, because some features sit only in commercial editions.

Which replacement costs are one-time and which recur every year?

One-time costs include discovery, inventory of Omni Gateway policies and routes, mapping them to the new gateway's plugins or policies, building declarative configuration in Git, building the deployment pipeline, and the initial cutover. Recurring costs include the infrastructure that runs the gateway, engineer time for upgrades and security patches, monitoring and log storage, certificate management, and any vendor support subscription you choose to buy. Apache APISIX is Apache-2.0 licensed and Kong Gateway OSS is Apache-2.0 licensed, so neither adds a per-node license fee. If you choose a commercial support contract or a commercial Kong Gateway Enterprise tier, that becomes a recurring line item, and its scope should be confirmed in writing.

What makes the migration effort go up or down?

Effort rises mainly with four drivers. The first is policy count and how many routes share the same policy chain. The second is custom Mule policies or DataWeave logic embedded in gateway policies, since these need to be rewritten as APISIX plugins (Lua, or a plugin runner in Java, Go, or Python, or WebAssembly) or Kong plugins. The third is observability needs, such as traces, metrics, and logs that must reach an existing SIEM or monitoring stack. The fourth is authentication: the APISIX openid-connect plugin supports flows such as authorization code, client credentials, token introspection, and PKCE with providers including Keycloak, Microsoft Entra ID, and Okta, but each integration still needs testing. Fewer routes, standard policies, and an existing identity provider keep the work small.

Can an internal team replace Omni Gateway without outside help?

A team with Kubernetes, Docker, and CI/CD experience can run the gateway itself, and both APISIX and Kong Gateway OSS publish documentation for Docker, Kubernetes, and Linux package installs. The harder parts are usually the policy inventory, the security review of each route, and running the gateway with the same availability and patching discipline you apply to other production infrastructure. Teams without that experience, or teams with tight change windows, often bring in an implementation partner for a fixed-scope engagement. DeployOpen plans, implements, hardens, and documents self-hosted platforms inside your own infrastructure, and an engagement starts with an agreed written scope.

How long does replacing Omni Gateway take?

Timeline depends on scope, and no duration is fixed by the research behind this page. The main inputs are the number of gateways and environments, the number of policies to map, the depth of testing you require, and how many applications must cut over. A pilot with a small set of low-risk APIs usually comes before any production move, so plan for a parallel run where Omni Gateway and the new gateway serve the same routes. Ask any partner for a phased plan with a milestone for each environment and a rollback step at each cutover, and treat any single-number estimate without that breakdown as incomplete.

What should a fixed-scope quote for this migration include?

A useful fixed-scope quote lists the following items in writing:

The inventory of gateways, environments, routes, and policies in scope, with the exclusions named.
The target platform, the chosen deployment mode, and the Kubernetes or Docker runtime.
Deliverables such as declarative configuration in Git, CI/CD pipeline, runbooks, and evidence for security controls.
Testing scope, including regression and cutover tests.
Handover, training, and the warranty or acceptance criteria.
Whether ongoing support, upgrades, and testing are included or sold separately as a retainer.

Also ask the vendor to confirm in writing which license tier and support terms apply to your deployment, because feature availability differs between open-source and Enterprise editions.

Which licensing and support terms should I confirm before I start?

Confirm three things directly with each vendor. First, the license scope: the Kong Gateway repository is Apache-2.0, but Kong's pricing page states that fully self-hosted gateways with a local control plane and data plane are part of the commercial Kong Gateway Enterprise offering. Second, the support window: Kong's version support policy applies to Kong Gateway Enterprise and gives no published support window for the open-source edition, and APISIX's downloads page does not mark any release as long-term support. Third, the MuleSoft side: confirm your Omni Gateway subscription terms, notice period, and any data your control plane still holds. Read these terms in writing, because a summary in a blog post or a sales call is not a license.

What do I lose when Anypoint API Manager is no longer in the loop?

Connected Mode ties Omni Gateway to Anypoint API Manager and Runtime Manager for centralized policy management, dashboards, and usage metrics. Without it, you rebuild those functions with your own tools: declarative files in Git, a CI/CD pipeline that applies them, and monitoring that reads gateway metrics. APISIX and Kong both provide Admin APIs and declarative options, but a developer portal, subscription workflow, and analytics dashboard are separate components you choose and operate. Local Mode on Omni Gateway already uses local configuration files, so teams on that mode have the smallest change in day-to-day operation.

What changes without Anypoint API Manager

Moving off Omni Gateway means the governance functions that Anypoint API Manager provided must be rebuilt in your own tooling. Those functions cover API contracts, client applications with their credentials and tiers, traffic analytics, and developer self-service. Each one needs a named replacement before cutover, because the gateway itself only enforces what it is told. Kong Konnect is a SaaS platform with a Kong-managed control plane, so moving to Kong Gateway OSS in your own environment means giving up that hosted control plane rather than simply swapping a data plane. Apache APISIX has no hosted control plane in this scope. Its routes, consumers and plugins live in etcd in traditional or decoupled mode, or in a YAML or JSON file in standalone mode, and you operate whichever one you choose.

For API contracts, the usual replacement is a Git repository holding OpenAPI specifications next to the gateway configuration. Review happens in merge requests, and a CI job validates the spec and syncs the gateway definitions. For Kong, decK handles the sync from declarative files. For APISIX, the Admin API or the standalone file is the write path, so the pipeline must be the only process allowed to change it. Confirm who may approve changes to a production route, and whether your audit process accepts Git history as the record of change.

Client applications, analytics and self-service need separate answers. Consumer credentials and key rotation become tasks in your identity provider or secrets manager, and the APISIX openid-connect plugin supports Keycloak, Microsoft Entra ID, Okta and similar providers. Gateway logs and metrics should feed an observability stack, since neither gateway replaces Anypoint's analytics views on its own. For developer self-service, decide between a portal built on Backstage, which catalogs APIs from the same Git source, and a gateway-native portal. Ask each vendor or project which portal features are community-licensed before you commit, because some portal and management capabilities sit in commercial editions.

How DeployOpen scopes and delivers a gateway replacement

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source gateways inside your own cloud accounts, data centers or air-gapped networks. For a move off MuleSoft Omni Gateway, the work starts with a written scope that maps your existing Omni Gateway policies onto Apache APISIX or Kong Gateway before any configuration is changed.

How we scope

Inventory every Omni Gateway instance, API, policy and client application that the replacement must carry over.
Record which gateways run in Connected Mode and which in Local Mode, since each affects what the new gateway must provide.
Agree in writing the target gateway, deployment model, deliverables and timeline before any work begins.

How we build

Translate policies into declarative APISIX or Kong configuration kept in Git and applied through your CI/CD pipeline.
Deploy to Docker or Kubernetes in your environment, wiring in your existing identity provider and observability stack.
Test routing, authentication, rate limits and failover in a staging environment against the captured inventory before cutover.

How we hand over

Deliver the configuration repository, deployment manifests and a runbook covering rollback and certificate rotation.
Document each mapped policy, any gap where the open-source option needs a different approach, and the decisions behind it.
Walk your platform and security teams through operation, upgrades and the change process before the handover is closed.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped separately from the build.
Plan version upgrades against the current release lines of your chosen gateway, with your team confirming support terms directly with the vendor.
Run periodic security testing of the gateway and its APIs when you want an independent check on the configuration.

Open-source alternative to MuleSoft Omni Gateway (Flex Gateway)