Apache APISIX vs KrakenD: which fits your gateway model
Choose Apache APISIX when your gateway must change at runtime through an Admin API and etcd, and when your team wants to write plugins in Lua or, through plugin runners, in Java, Go or Python. APISIX is Apache-2.0 licensed, and its traditional and decoupled topologies keep routes, upstreams and plugin settings in etcd, so operators can change them without restarting nodes. Choose KrakenD Community Edition when your gateway should be a stateless, declaratively configured layer that every node runs independently, managed as files in Git. KrakenD CE is also Apache-2.0 licensed, and its README describes nodes that need no coordination or central persistence.
Three questions decide it. First, must configuration changes apply at runtime through an API, or is a reviewed file change deployed through your pipeline acceptable? APISIX's standalone mode also reloads a YAML or JSON file, so file-driven operation is possible there, but the etcd-backed model is where dynamic control sits. Second, must nodes be stateless? KrakenD's design fits that requirement directly, while APISIX traditional and decoupled modes depend on an etcd cluster that you must run and back up. Third, how much custom logic do you need? APISIX offers more extension languages and more than 100 built-in plugins, while KrakenD extends through Lua, Martian or Google CEL.
Be fair to both. KrakenD's strengths in response aggregation and transformation may cover your needs without a plugin layer at all, and APISIX's breadth may be more than a small API surface requires. Before you decide, confirm the aggregation, transformation and rate-limiting behavior you need against each project's current documentation, test your etcd or file-reload workflow in a staging environment, and check that the Enterprise features you may later need are priced into your plan.
Which gateway fits which scenario
This table maps common gateway scenarios to the platform that usually fits better, with the condition that makes each choice hold. Read each row against your own route churn, change control and team skills, since the better fit flips when those conditions change.
| Scenario | Better fit | Condition under which it holds |
|---|---|---|
| Kubernetes ingress with frequent route changes | Apache APISIX | Routes and plugins change many times a day and you want Admin API or Ingress Controller updates applied at runtime without reloading the whole config. |
| GitOps-only change control | KrakenD CE | Every change must go through a Git pull request and the gateway should hold no state, so stateless nodes that load a declarative file fit the review model directly. |
| Backend aggregation for mobile or web clients | KrakenD CE | Clients need one call that fans out to several backends and merges or filters the JSON or XML responses, which KrakenD covers as built-in features. |
| Custom plugin authoring in Java, Go or Python | Apache APISIX | Your team wants external plugin runners in those languages, and you accept that WebAssembly support is still experimental in APISIX. |
| Custom logic written in Lua or CEL | Apache APISIX or KrakenD CE | APISIX fits Lua plugins that run in worker processes. KrakenD fits lighter extensions in Lua, Martian or Google CEL. Confirm the exact extension limits for your use case. |
| Teams without etcd operations experience | KrakenD CE | You want no distributed configuration store to back up and operate. APISIX standalone mode removes etcd too, but it changes how you push config, so confirm that trade-off before choosing. |
| Dynamic configuration through an API | Apache APISIX | Automation or internal tools need to change routes and upstreams through an Admin API, with the cluster state held in etcd. |
How APISIX and KrakenD are built and deployed
APISIX and KrakenD both run as gateways in front of your services, but they hold configuration in very different places. The cards below cover where each keeps its state, how changes reach running nodes, and which operational work each model creates for your team.
APISIX traditional and decoupled modes
In traditional mode, data plane and control plane run together on each node, and etcd holds the configuration. In decoupled mode, separate data plane and control plane instances share one etcd cluster. Both models make etcd a critical dependency: your team must plan its backup, quorum, certificate rotation and upgrades. Confirm the etcd sizing and failure behavior with your own load tests before committing.
APISIX standalone mode
Standalone mode removes etcd and loads routes and plugins from conf/apisix.yaml or conf/apisix.json, or through the Admin API. Because there is no shared store, your team must decide how each node receives the same file, usually through your configuration management or GitOps pipeline. Check whether the Admin API and its access controls fit your change process before choosing this mode.
APISIX Admin API and ports
In traditional mode, APISIX serves client traffic on port 9080 and the Admin API on port 9180. Changes made through the Admin API are written to etcd and applied to the running nodes. Restrict access to port 9180 with network policy and strong Admin API keys, and confirm which ports your firewall, load balancer and health checks must allow in each mode.
APISIX hot reload in file mode
In file-driven standalone mode, APISIX checks conf/apisix.yaml or conf/apisix.json for changes every second and hot-reloads without a restart. This makes rollouts quick, but it also means a bad file can take effect across nodes within seconds. Ask your team to validate configuration in CI and keep a tested rollback path for the file.
KrakenD stateless nodes
KrakenD's README describes each node as operating independently, without coordination or centralized persistence. There is no etcd or database to back up or keep in quorum, so scaling out means starting more identical instances with the same configuration. The trade-off is that every node must receive the same configuration version, and your deployment pipeline becomes the only source of truth for what is running.
KrakenD declarative configuration and rollout
KrakenD is configured declaratively for GitOps workflows, so changes ship as versioned files rolled out with your normal release tooling. Operations work shifts from database care to the release pipeline: testing the configuration, staging it, rolling it across nodes and confirming that all nodes match. Ask KrakenD for its documented reload behavior and how it signals a changed configuration before you plan maintenance windows.
Where extension languages and response aggregation differ
Choose APISIX when custom logic must run inside the request path with a plugin model you can extend in several languages, and choose KrakenD when most of the work is composing and reshaping responses from existing backends. APISIX runs Lua plugins inside its NGINX worker processes, which keeps per-request overhead low for teams that write their own plugins in Lua. For Java, Go or Python, APISIX uses external plugin runners, so each non-Lua plugin adds a separate process to deploy, monitor and patch. WebAssembly plugin support is documented as experimental, so do not plan production plugins around it without confirming current status with the APISIX maintainers. KrakenD extends through Lua, Martian and Google CEL, and its built-in content aggregation, filtering and XML or JSON transformation cover many composition cases without custom code.
Aggregation at the gateway removes backend work when several services must be merged into one response for a mobile or partner client, and the backends should not change to serve that client. A KrakenD endpoint can fan out to several upstreams, merge the results and drop fields the client does not need, so the front-end team does not wait for backend releases. The cost moves into gateway configuration: every new composition is another declarative definition that someone must review, test and version. Illustrative example: if a product page needs three backend calls, the gateway hides that from clients, but a failure or latency spike in any one backend now affects the aggregated endpoint, which the team must test with circuit breaker and timeout settings.
Before committing, run a short spike. Build one aggregated endpoint in KrakenD CE and one equivalent flow in APISIX using its plugins or a custom plugin, then measure how many files, plugin runners or build steps each one needs for a change. Ask whether your team already writes Lua, Java, Go or Python, because that answer decides whether APISIX's plugin model is a benefit or an extra runtime to run. If your composition logic is mostly JSON reshaping, confirm that KrakenD's transformation features cover your cases before writing custom code in either product.
Capabilities compared on supplied facts
This table compares Apache APISIX 3.19.0 and KrakenD CE v3.0.1 on the capabilities that most affect architecture and day-to-day operation. Cells marked as needing confirmation are gaps you should check in each project's documentation before deciding. The main takeaway is that APISIX documents more deployment modes and extension runtimes, while KrakenD's stateless, declarative model is simpler to reason about for teams that manage the gateway through Git.
| Capability | Apache APISIX 3.19.0 | KrakenD CE v3.0.1 |
|---|---|---|
| License and editions | Apache-2.0, Apache Software Foundation top-level project. Confirm which features any commercial add-on covers. | Community Edition under Apache-2.0. Enterprise Edition adds SLAs, security, governance and 24/7 support. |
| Runtime and core technology | Built on NGINX with ngx_lua and LuaJIT. | Stateless gateway where every node operates independently. Confirm the underlying runtime in its documentation. |
| Configuration storage and deployment modes | Traditional and decoupled modes store configuration in etcd. Standalone mode has no etcd and reads YAML or JSON or an API. | No centralized persistence or coordination between nodes. Confirm supported topologies and how configuration changes reach running nodes. |
| Protocols | HTTP and HTTPS, HTTP/3 with QUIC, gRPC, WebSocket, MQTT, Dubbo and TCP/UDP proxying, per the repository. | Not covered by the supplied facts. Confirm HTTP/3, gRPC, WebSocket, MQTT and TCP/UDP support in KrakenD's documentation. |
| Authentication | openid-connect plugin works with Keycloak, Auth0, Microsoft Entra ID, Google and Okta, with authorization code, client credentials, introspection and PKCE flows. | OAuth and JWT security are supported. Confirm named OIDC provider support and the flows available. |
| Rate limiting and circuit breakers | Traffic control is one of the built-in plugin categories. Confirm the rate limiting and circuit breaker plugins in your version. | Multi-layer rate limiting and circuit breakers are listed as core features. |
| Observability exporters | Observability is one of the built-in plugin categories. Confirm which exporters your chosen version ships. | Telemetry to Prometheus, Jaeger, Zipkin and Datadog. |
| Extension languages | Lua plugins run in worker processes. Java, Go and Python run through external plugin runners. WebAssembly is experimental. | Extensions in Lua, Martian and Google CEL. |
| Git-driven configuration | Standalone mode reloads a YAML or JSON file when it changes, and the Admin API handles API-driven changes. Confirm the GitOps workflow your team needs. | Declarative configuration designed for GitOps workflows. Confirm how the config file is validated and deployed in your pipeline. |
How each handles identity integration
Browser users sign in through an identity provider, and the gateway handles the redirect flow before it forwards requests. The APISIX openid-connect plugin supports the authorization code flow with PKCE, which suits single-page apps and public clients that cannot keep a client secret safe. The plugin's documentation names Keycloak, Auth0, Microsoft Entra ID, Google and Okta among its supported identity providers.
- Provider coverage: The documentation names these providers, so test discovery, claims and token behavior against your own tenant before you commit.
- Authorization code with PKCE: The browser exchanges a short-lived code for tokens, and PKCE protects that exchange when no secret stays in the client.
- Route scoping: Attach the plugin only to routes that need login, so public routes stay open on the same gateway.
- Session and refresh handling: Confirm how sessions and token refresh behave in your chosen deployment mode, since traditional, decoupled and standalone modes differ in where configuration lives.
Check redirect URI rules, logout behavior and cookie settings against your security baseline before go-live.
Machine clients such as batch jobs, internal services and partner integrations do not have a user to redirect. For these, APISIX supports the client credentials flow, where the calling service authenticates as itself, and token introspection, where the gateway asks the identity provider whether an opaque token is still active. Both are documented for the same openid-connect plugin, so one policy can cover browser and machine traffic.
- Client credentials: Each service gets its own client identity, which makes revocation and audit trails specific to that service.
- Token introspection: The gateway checks token status with the identity provider, so revoked tokens stop working without waiting for expiry.
- Per-request cost: Introspection adds a call to the identity provider unless results are cached, so confirm caching behavior and size the identity provider for peak traffic.
- Scope checks: Map scopes or claims to routes so each service reaches only the endpoints it needs.
Before relying on introspection, confirm the cache lifetime you accept for revoked tokens and test rotation of client secrets with your identity provider.
KrakenD's open-source README lists OAuth and JWT security among its features, and its stateless design means each node validates tokens on its own without a shared session store. That model fits teams that already receive tokens from an identity provider and want the gateway to verify them, enforce rate limits and forward claims to backends. The supplied material does not describe KrakenD running a browser login redirect, so plan login handling in the application or in a separate component.
- Stateless validation: Each node checks signatures and expiry independently, which keeps horizontal scaling simple because no session state must be shared.
- Layered controls: Token checks sit alongside multi-layer rate limiting and circuit breakers in the same configuration.
- Custom checks: Extensions in Lua, Martian or Google CEL can express claim rules beyond the built-in checks, so test each rule against sample tokens.
- Declarative config: Identity rules live in files that suit GitOps review and audit.
Verify how KrakenD validates tokens from your identity provider in a test environment before treating it as the identity boundary.
The supplied material establishes that KrakenD CE supports OAuth and JWT security, but it does not establish how far its OIDC handling goes in any given version. Treat OIDC behavior as a question for your own testing, not an assumption. The latest Community Edition release supplied is v3.0.1, published on October 13, 2026, so start your checks on that line and record the exact version you deploy.
- Login flows: Ask whether CE performs authorization code or PKCE login itself, or only validates tokens issued elsewhere.
- Key discovery and rotation: Confirm how signing keys are fetched and refreshed, and how fast a rotated key is accepted.
- Algorithms and claims: List the signing algorithms and claim checks your identity provider uses, and test each one.
- Enterprise differences: Ask the vendor which identity features sit in the Enterprise Edition and what its terms require.
- Failure behavior: Test what happens when the identity provider is unreachable.
Record the answers against your identity provider and version, and ask for them in writing before you commit to either gateway.
What drives running cost for each gateway
Running cost for either gateway comes from the infrastructure it sits on, the people who operate it, and the support or paid editions you choose. APISIX carries a stateful configuration store, while KrakenD scales as stateless nodes, so the cost drivers differ in shape even where the license is free.
Infrastructure footprint
APISIX in traditional or decoupled mode needs an etcd cluster alongside gateway nodes, while KrakenD CE runs as independent stateless nodes with no central persistence. Your cloud or data center bill is therefore driven by node count, redundancy targets and the extra etcd capacity for APISIX. Ask any vendor or partner to price the node sizing for your peak traffic and your failover model, since both gateways scale horizontally but the fixed overhead differs.
etcd cluster operation
In APISIX traditional and decoupled modes, etcd holds the configuration that every gateway node depends on, so someone must own its backups, quorum health, upgrades and disk monitoring. This is a recurring operating task that does not exist in KrakenD's stateless design. Standalone mode removes etcd entirely by reading a YAML or JSON file, which changes the recurring workload. Confirm which mode you will run before estimating operator hours.
Stateless node scaling
KrakenD nodes operate without coordination, so adding capacity is largely a matter of adding identical nodes from the same declarative configuration. The recurring cost is compute and the pipeline that deploys configuration changes, not a stateful cluster. Check how your team will test configuration in Git before each rollout, because aggregation and transformation rules run on every node and a faulty change multiplies quickly.
Skills needed to operate
APISIX customization is primarily in Lua, with plugin runners available for Java, Go and Python, so operators need Lua knowledge for in-worker plugins and NGINX familiarity for troubleshooting. KrakenD extensions use Lua, Martian or Google CEL, and its configuration is declarative. Staff cost is usually the largest recurring line, so check whether your team already has these skills or must hire or train for them.
Support options and retainers
Both communities are free to use, but production support is a separate purchase. KrakenD sells an Enterprise Edition with SLAs and 24/7 support, and API7 Enterprise is a commercial product built on APISIX. Implementation partners such as DeployOpen work from a fixed written scope, and ongoing support is available as a retainer. Ask each quote to separate one-time build work from recurring support, and to state what response commitments are included.
Upgrade cadence and paid editions
APISIX 3.19.0 was released on September 28, 2026, and the downloads page does not mark any release as long-term support, so plan for regular minor upgrades. KrakenD CE v3.0.0 followed on September 30, 2026 and v3.0.1 on October 13, 2026. Ask for the upgrade effort per cycle, the testing cost for configuration and plugins, and which features sit behind KrakenD Enterprise before you commit to a free edition.
Moving from one gateway to the other
This sequence moves routes, plugin behavior and identity settings from one gateway to the other without a single cutover, so both can run side by side until traffic is proven on the new platform. The output is a tested route set, a documented auth model and a retired configuration store.
Inventory routes, plugins and policies
Your platform or API team lists every route, upstream, plugin and auth policy on the current gateway, including the Admin API calls or configuration files that create them. Export the current configuration and record which routes carry rate limits, JWT or OAuth checks, transformations and response aggregation. Done means every route has an owner and a row in a mapping sheet, and the team agrees which features are in active use and which can be retired.
Map plugins to KrakenD configuration
Work through the mapping sheet and decide, for each APISIX plugin, how the equivalent behavior is expressed in KrakenD's declarative configuration, or the reverse. Where KrakenD's built-in features cover the need (content aggregation, filtering, JSON or XML transformation, multi-layer rate limiting, circuit breakers), note the configuration keys. Where no built-in equivalent exists, record the gap and whether a custom extension in Lua, Martian or Google CEL would be needed, or whether the logic belongs in the backend. Done means every gap has a written decision.
Rebuild authentication and identity settings
The security team re-creates the auth model on the target gateway, using the same identity provider tenant, client registrations, audiences and scopes. On APISIX this is usually the openid-connect plugin with flows such as authorization code, client credentials or introspection. On KrakenD it is the OAuth and JWT configuration. Test each route with valid, expired and wrongly scoped tokens. Done means the test results show the same allow and deny outcomes on both gateways, and the identity provider settings are documented in the change record.
Automate configuration in version control
The platform team moves the target configuration into Git and wires it into the deployment pipeline. For KrakenD, the declarative file is the source of truth and is reviewed like application code. For APISIX, decide whether the Admin API, file-driven standalone mode or a Kubernetes tool drives the configuration, and retire any manual changes. Note that a standalone APISIX deployment reads conf/apisix.yaml or conf/apisix.json and hot-reloads on change. Done means a pull request is the only route to production on the target gateway.
Run both gateways in parallel and shift traffic
Keep the current gateway serving production while the target handles a limited set of routes, chosen by low risk first. Shift traffic through DNS, a load balancer or a routing rule in front of both, and watch error rates, latency, authentication failures and dropped requests against a baseline agreed before the move. Roll back the affected routes if a threshold is crossed. Done means each route has run on the target gateway under real traffic, with the metrics recorded and the cutover decision signed off by the service owner.
Retire the old configuration store
Once all routes are proven, the team removes the old gateway from traffic, exports a final backup of its configuration and data store, and records the retention period set by your policy. For APISIX, this may mean decommissioning etcd and the Admin API endpoints on port 9180 in traditional mode. For a database-backed gateway, it means closing the database and its credentials. Done means no client still resolves to the old gateway, access to its backups is restricted, and the decommission is in the change log.
Where implementation projects usually run long
The longest APISIX work is usually the control plane, not the routes. In traditional or decoupled mode, etcd becomes the configuration center, so teams must settle its cluster sizing, TLS, access controls and backup before any gateway node goes live. The Admin API on port 9180 needs its own hardening: restricting which networks can reach it, rotating its admin key, and deciding who may change routes through it. Identity wiring with the openid-connect plugin tends to take longer than planned because each identity provider (Keycloak, Entra ID, Okta and others) has its own client registration, scopes, token lifetimes and flow choices such as PKCE or client credentials. Teams that write custom plugins in Lua or through an external plugin runner in Java, Go or Python also need a build, test and upgrade path for that code, since WebAssembly support is still marked experimental in the architecture documentation. Ask for these items as separate line items in the written plan.
KrakenD projects tend to run long in a different place: modeling the configuration and proving the aggregation. Because every node is stateless and configured declaratively, the effort concentrates in the endpoint definitions, the backend mappings, the filtering and XML or JSON transformations, and the rate limit and circuit breaker settings that must match each upstream's real behavior. Aggregation testing is often underestimated, because each composed response has to be checked against partial backend failures, timeouts and schema changes. The GitOps pipeline is the other common overrun: teams need validation of the configuration file before merge, environment-specific values kept out of the repository, and a promotion path that matches how their clusters are deployed. Confirm with the vendor which package format or Docker image your team will use and how upgrades between CE releases are handled.
A fixed-scope written plan for either gateway should name the configuration model, the test cases and the rollback steps as deliverables with their owners. For APISIX, it should cover etcd and Admin API hardening, identity provider setup per flow, plugin development and runner setup, and a load test on the chosen deployment mode. For KrakenD, it should cover the endpoint and backend model, an aggregation test suite including failure cases, the GitOps pipeline and the observability exports to Prometheus or the tracing tool you use. Require that each item lists what the client must supply, such as identity provider access, network rules and test data, because delays on the client side are a frequent cause of overrun. Ask DeployOpen to state assumptions and change-control terms in writing before work starts.
Questions buyers ask before choosing or hiring help
Can KrakenD CE handle dynamic routing needs?
KrakenD CE can route and transform requests, but its design is declarative and stateless: every node runs independently from configuration, without coordination or centralized persistence. That suits teams that change routes through Git and a deployment pipeline. If your routes must change at runtime through an API call with no redeploy, check whether a file-driven reload or a pipeline step meets that need, because KrakenD's README describes configuration for GitOps workflows rather than a live control API. Ask the vendor to confirm how route changes propagate across nodes in your topology before you commit.
Does APISIX require etcd expertise to run in production?
In traditional and decoupled modes, APISIX stores configuration in etcd, so someone on the team must operate an etcd cluster, including backups, quorum, disk performance and upgrades. Standalone mode removes etcd entirely and loads configuration from conf/apisix.yaml or conf/apisix.json, reloading when the file changes. The effort therefore depends on the mode you pick. Teams that want file or API-driven configuration without running a distributed key-value store should evaluate standalone mode, and the deployment modes documentation at Apache APISIX deployment modes explains the trade-offs the project itself describes.
How much effort does a gateway migration take, and what drives it?
Effort is driven by the number of routes, the plugins or transformations in use, and how authentication is wired. Routes that are simple proxies move quickly, while KrakenD aggregation endpoints or response transformations need to be re-expressed as APISIX plugins or upstream services. Other drivers include the identity provider integration, rate limit policies, observability exports and how much of the current gateway configuration already lives in version control. Ask for an inventory of endpoints and policies first, because the scope of that inventory sets the migration plan. DeployOpen does not publish a migration duration, so treat any figure you receive as a function of the written scope.
What work must our team provide during an engagement?
Most of the input is knowledge and access. Your team should supply the route inventory, upstream service owners, the identity provider configuration, the traffic and rate limit requirements, the target hosting platform and the change approval process. You will also need to decide who owns the configuration repository and who approves production changes after handover. Named reviewers for security and operations reduce waiting time during testing. Clarify these responsibilities in the written scope so that cost and schedule follow from what each party provides.
Can our own engineers run the migration without outside help?
Yes, if your team already runs NGINX-based or declarative infrastructure and has the time to learn the chosen APISIX mode or KrakenD configuration model. The main risks are unfamiliar operational tasks, such as operating etcd in APISIX traditional or decoupled modes, and gaps in security testing before cutover. A common approach is to pilot a small set of routes internally, then bring in outside help for the parts where the team lacks depth. Be honest about bandwidth, because a gateway migration competes with ongoing service work.
What does a fixed-scope engagement with DeployOpen cover?
A fixed-scope engagement covers the work named in the written scope, with deliverables and timelines agreed before work starts. For a gateway topic, that can include planning the deployment in your own cloud accounts, data centers or air-gapped network, implementing and integrating the chosen gateway, hardening it, setting up backups, documenting the configuration and handing over operations. DeployOpen also offers security testing of APIs and supports compliance readiness by preparing controls and evidence, but it does not issue audit reports or certifications. Ongoing support, upgrades and continuous testing are available as retainers. A quote follows from the written scope, and DeployOpen does not publish a price list.
Which license and version facts should we confirm before choosing?
Confirm that you are comparing the same release tracks. Apache APISIX is Apache-2.0 licensed, and the APISIX downloads page reports 3.19.0 released on September 28, 2026, without marking any release as long-term support. KrakenD Community Edition is Apache-2.0 licensed, with v3.0.1 published on October 13, 2026, and KrakenD sells an Enterprise Edition with SLAs and 24/7 support. Check which features your requirements depend on, and confirm with each vendor what is included in the community release and what sits in a paid edition. Your procurement team should record those answers in the scope document.
How DeployOpen helps you choose and implement
DeployOpen helps teams decide between Apache APISIX and KrakenD by first mapping their routing, identity and configuration-management requirements, then implementing the chosen gateway inside their own infrastructure. Engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Written scope lists which gateway, deployment mode and environments are covered, agreed before any work starts.
- We document the routes, upstreams, identity flows and rate limits the gateway must handle for your APIs.
- The scope names which extensions, such as custom plugins or response aggregation logic, are in or out of the engagement.
How we build
- We deploy the chosen gateway into your own cloud accounts, data centers or air-gapped networks.
- Configuration is kept in version control, with changes applied through your review and release process.
- We test routing, authentication and failover behavior against the requirements agreed in the written scope.
How we hand over
- Deliverables include deployment documentation, configuration references and runbooks for your operations team.
- We walk your engineers through day-to-day administration, upgrades and the rollback steps they will need.
- Handover records state which components were built, which were configured and which remain your responsibility.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover tracking of upstream release lines, so your team plans upgrades against published support dates.
- Ask us to confirm the support scope, response expectations and upgrade cadence in writing before you sign.
