/
DR-000045 - Replace Kong with Apache APISIX

DR-000045 - Replace Kong with Apache APISIX

Dec 10, 2025

Submitted Date

Dec 10, 2025 

Approved Date

Dec 10, 2025 

Status

ACCEPTED

Impact

MEDIUM

 

Overrides/Supersedes 

NA

RFC 

NA

Stakeholders

  • #folio-sys-ops

  • #folio-devops

  • #folio-development

  • #folio-tech-council

Contributors

  • @Viktor Gema

  • @Craig McNally

  • @VBar

  • Eureka Team

Approvers

Technical Council via lazy consensus.  See 2025-12-10 Eureka Gateway Update

Background/Context

Kong inc. (the primary contributor/maintainer of Kong OSS) decided earlier this year to stop contributing to, and building binary distributions of the open source version of Kong.  More specifically:

  • No new features would be contributed to Kong OSS

  • They would no longer build binary distributions of Kong OSS

  • Some bug fixes may be contributed to the OSS version, but there are no guarantees wrt timing or providing patches at all. 

Note:  AFAIK there was never a formal, public statement made about this, but during conversations with Kong inc. it was confirmed.

Assumptions

See API Gateway Comparison: APISIX vs Gloo vs Kong – Decision Matrix for FOLIO Platform

Constraints

See API Gateway Comparison: APISIX vs Gloo vs Kong – Decision Matrix for FOLIO Platform

Rationale

After reviewing several options across various metrics, a clear front-runner emerged.   See API Gateway Comparison: APISIX vs Gloo vs Kong – Decision Matrix for FOLIO Platform and other spike/PoC findings linked below for additional details.

Decision

Adopt Apache APISIX as the replacement for Kong.

Implications

  • Pros

    • APISIX is a suitable Kong replacement providing not only feature parity, but the active community is still contributing new features

    • Potentially improved performance

    • Less risk of losing corporate support

    • Configuration changes are propagated to all APISIX cluster nodes quicker than with Kong.

    • Impact on development teams is largely limited to the Eureka team.

    • Support for java-based plugins

  • Cons

    • Dual compatibility should be supported for some time (Kong & APISIX) to facilitate transition from one to the other.

    • System operators will need to host both the APISIX container, as well as an etcd service.

    • References to Kong (e.g. in env var names, documentation, etc.) should eventually be changed to avoid confusion.

Other Related Resources