--- title: "Kong vs Ambassador (Emissary-ingress) Compared (2026) - API7.ai" description: "Kong vs Ambassador (Emissary-ingress): NGINX vs Envoy, Kubernetes-native design, protocols, plugins, security, and licensing compared to help you choose." url: "https://api7.ai/kong-vs-ambassador" --- # Kong vs Ambassador (Emissary-ingress): NGINX vs Envoy (2026) By API7.ai Team Last updated: June 2026 Kong and Ambassador (Emissary-ingress) are both API gateways, but they start from different places — a general-purpose NGINX/OpenResty gateway that runs anywhere versus a Kubernetes-native gateway built on Envoy Proxy. This guide compares architecture, Kubernetes integration, protocols, plugins, security, and licensing so you can pick the right fit. TL;DR Kong is a general-purpose API gateway (NGINX/OpenResty, 100+ plugins) that runs on bare metal, VMs, Docker, or Kubernetes. Emissary-ingress is a CNCF-incubating, Kubernetes-native gateway built on Envoy and configured through CRDs — powerful inside a cluster but Kubernetes-only. The choice mostly comes down to deployment flexibility versus Kubernetes-native design. - One gateway across K8s and non-K8s infrastructure: Kong - Pure-Kubernetes, CRD-native ingress and gateway: Emissary-ingress - Broadest plugin ecosystem and language choice: Kong - [At a glance](#at-a-glance) - [What is Kong?](#what-is-kong) - [What is Emissary-ingress?](#what-is-ambassador) - [Architecture](#architecture) - [Kubernetes & deployment](#kubernetes) - [Feature comparison](#feature-comparison) - [When to choose](#choose) - [FAQ](#faq) ## Kong vs Ambassador (Emissary-ingress) at a glance Kong leads on deployment flexibility and plugin breadth across any environment; Emissary-ingress leads on Kubernetes-native, CRD-driven configuration with an Envoy data plane and no external database. | Dimension | Kong | Ambassador (Emissary-ingress) | | ----------------------- | ------------------------------------------------ | ----------------------------------------- | | Best for | General-purpose API gateway, any deployment | Kubernetes-native ingress and API gateway | | Proxy core | NGINX/OpenResty (Lua) | Envoy Proxy | | Configuration | Admin API + decK; PostgreSQL, DB-less, or hybrid | Kubernetes CRDs + Service annotations | | Runs outside Kubernetes | ✓ Bare metal, VM, Docker, K8s | — Kubernetes-only | | Plugin ecosystem | 100+ plugins (some Enterprise-only) | Envoy filters + Wasm extensions | | Governance | Kong Inc. (Apache-2.0 core + Enterprise) | CNCF incubating (Apache-2.0) | | Commercial edition | Kong Konnect / Enterprise | Edge Stack (now a Gravitee product) | ## What is Kong? Kong is a general-purpose API gateway built on NGINX/OpenResty (Lua) with a 100+ plugin ecosystem, running on bare metal, VMs, Docker, or Kubernetes via PostgreSQL, DB-less, or hybrid mode. Kong is a general-purpose API gateway built on NGINX/OpenResty (Lua) with a 100+ plugin ecosystem for authentication, rate limiting, and traffic management. It runs on bare metal, VMs, Docker, or Kubernetes using PostgreSQL, DB-less, or hybrid deployment modes. Proxy core NGINX/OpenResty (Lua) License Apache-2.0 core + Enterprise Best for API gateway in any environment ### Pros - Runs anywhere: bare metal, VM, Docker, Kubernetes - 100+ plugins; custom plugins in Lua, Go, Python, JS, and Wasm - PostgreSQL, DB-less, and hybrid deployment modes - Mature ecosystem with a managed cloud option (Konnect) ### Cons - Not originally designed Kubernetes-first - Traditional mode adds a PostgreSQL dependency to operate - OIDC and some advanced plugins are Enterprise-only - Enterprise pricing is custom (contact sales) ## What is Ambassador (Emissary-ingress)? Emissary-ingress is an open-source, Kubernetes-native API gateway built on Envoy Proxy and configured through Kubernetes CRDs. It is a CNCF-incubating project under Apache-2.0 and runs only inside a cluster. Emissary-ingress is an open-source, Kubernetes-native API gateway built on Envoy Proxy, configured entirely through Kubernetes CRDs and Service annotations. It is a CNCF-incubating project under the Apache-2.0 license and runs only inside a Kubernetes cluster. Proxy core Envoy Proxy License Apache-2.0 (CNCF incubating) Best for Kubernetes-native ingress + gateway ### Pros - Kubernetes-native: CRD-based config, no external database - Built on Envoy Proxy with modern L7 routing - Canary releases, A/B testing, and dynamic routing built in - Vendor-neutral CNCF project under Apache-2.0 ### Cons - Kubernetes-only — cannot run on bare metal or VMs - Extensibility is Envoy filters / Wasm — smaller, lower-level - Leans on external services for some advanced policy - Original parent stepped back; commercial Edge Stack moved to Gravitee ## Architecture: NGINX/OpenResty vs Envoy Kong builds on NGINX/OpenResty with Lua plugins and a configurable datastore; Emissary-ingress builds on Envoy Proxy with an xDS-driven data plane configured entirely through Kubernetes CRDs. Kong runs on NGINX/OpenResty and extends behavior through Lua plugins. Configuration can be backed by PostgreSQL (traditional mode), kept in-memory (DB-less mode), or split across control and data planes (hybrid mode). Cassandra support was removed in Kong Gateway 3.4, so PostgreSQL is the supported database when you need one. Emissary-ingress uses Envoy Proxy as its data plane and a control plane that translates Kubernetes CRDs and Service annotations into Envoy configuration. There is no separate database — desired state lives in Kubernetes resources. That keeps the model declarative and GitOps-friendly, at the cost of running only inside Kubernetes. ## Kubernetes and deployment flexibility Emissary-ingress is Kubernetes-only and CRD-native; Kong supports Kubernetes through its Ingress Controller but also runs on bare metal, VMs, and Docker — so deployment scope is often the deciding factor. Emissary-ingress is Kubernetes-native by design. It is configured with CRDs such as Mapping, TCPMapping, Host, and Listener, and it relies on Kubernetes for scaling and resiliency. It cannot run outside a cluster, which is ideal for Kubernetes-only platforms and a hard limit for everyone else. Kong supports Kubernetes through the Kong Ingress Controller, but it was not originally Kubernetes-first and equally runs on bare metal, VMs, and Docker. If your estate spans Kubernetes and non-Kubernetes workloads, Kong lets you standardize on one gateway; if you are all-in on Kubernetes, Emissary's CRD model is a closer fit. ## Kong vs Ambassador (Emissary-ingress): feature comparison Across proxy core, configuration, Kubernetes integration, protocols, plugins, and security, the two trade deployment flexibility against Kubernetes-native, Envoy-based design. | Feature | Kong | Ambassador (Emissary-ingress) | | ----------------------- | ----------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- | | Proxy core | NGINX/OpenResty with Lua; mature, widely deployed | Envoy Proxy (C++); modern xDS-driven data plane | | Configuration model | Admin API + decK declarative config; PostgreSQL, DB-less, or hybrid mode | Kubernetes CRDs (Mapping, TCPMapping, Host, Listener) and Service annotations | | Kubernetes | Kong Ingress Controller; supported but not originally K8s-designed | Kubernetes-native by design; built as an Ingress + API gateway | | Deployment flexibility | Bare metal, VM, Docker, and Kubernetes | Kubernetes-only — requires a cluster | | Datastore | PostgreSQL (traditional), DB-less, or hybrid; Cassandra removed in 3.4 | No external database — state lives in Kubernetes resources | | Protocols | HTTP/HTTPS, gRPC/gRPCS, TCP/TLS, WebSocket, UDP | HTTP/1.1, HTTP/2, gRPC, TCP, WebSockets (via Envoy) | | Plugins / extensibility | 100+ Plugin Hub plugins; custom plugins in Lua, Go, Python, JS, and Wasm | Envoy filters and WebAssembly (Proxy-Wasm) extensions; smaller, lower-level | | Security & auth | JWT, OAuth2, API keys, ACLs, mTLS; OIDC and some advanced auth are Enterprise | Authentication/authorization, JWT, external auth, rate limiting, and TLS via Envoy | | Observability | Prometheus, OpenTelemetry, Zipkin, Datadog via plugins | Prometheus metrics, distributed tracing, and access logging (Envoy-native) | | Traffic management | Routing, load balancing, rate limiting, request/response transformation | Canary releases, A/B testing, dynamic routing, sticky sessions | | License & governance | Apache-2.0 core, governed by Kong Inc.; paid Enterprise tier | Apache-2.0, CNCF incubating project; community-governed | | Commercial / pricing | Konnect usage-based tiers; Enterprise is custom (contact sales) | Free OSS; commercial Edge Stack is now sold by Gravitee (custom pricing) | ## When to choose Kong vs Ambassador (Emissary-ingress) Choose Kong for deployment flexibility and a broad plugin ecosystem across any environment; choose Emissary-ingress for a Kubernetes-native, Envoy-based gateway configured entirely through CRDs. ### Choose Kong if you… - You need one gateway across bare metal, VMs, Docker, and Kubernetes - You want a broad plugin ecosystem and custom plugins in several languages - You prefer PostgreSQL, DB-less, or hybrid deployment flexibility ### Choose Ambassador (Emissary-ingress) if you… - You run entirely on Kubernetes and want a CRD-native gateway - You prefer an Envoy-based data plane with no external database - You value a vendor-neutral, CNCF-governed open-source project **Bottom line:** if you run only on Kubernetes and want a CRD-native, Envoy-based gateway, Emissary-ingress is a natural fit; if you need one gateway across Kubernetes and non-Kubernetes infrastructure with a deep plugin ecosystem, Kong is the more flexible choice. If you're weighing open-source gateways more broadly, Apache APISIX is another NGINX/OpenResty option worth a look — see [Apache APISIX vs Kong](https://api7.ai/apisix-vs-kong). ## Frequently asked questions ### What is the difference between Kong and Ambassador (Emissary-ingress)? Kong is a general-purpose API gateway built on NGINX/OpenResty (Lua) that runs anywhere — bare metal, VMs, Docker, or Kubernetes — using PostgreSQL, DB-less, or hybrid mode. Emissary-ingress is a CNCF-incubating, Kubernetes-native API gateway built on Envoy Proxy and configured entirely through Kubernetes CRDs, so it runs only inside Kubernetes. ### Is Kong or Ambassador (Emissary-ingress) better for Kubernetes? Emissary-ingress is Kubernetes-native by design: it is configured through CRDs (Mapping, TCPMapping, Host, Listener) and Service annotations, and only runs in a cluster. Kong supports Kubernetes through the Kong Ingress Controller but was not originally Kubernetes-first. For a pure-Kubernetes, GitOps-style setup Emissary fits naturally; Kong is better when you also run outside Kubernetes. ### Can Ambassador (Emissary-ingress) run outside Kubernetes? No. Emissary-ingress is Kubernetes-native and is configured exclusively through Kubernetes CRDs and Service annotations, so it requires a cluster to run. If you need a gateway for bare metal, VMs, or other non-Kubernetes environments, Kong runs in those topologies via its traditional, DB-less, or hybrid deployment modes. ### How do Kong and Emissary-ingress compare on performance? They use different proxy cores: Kong runs on NGINX/OpenResty, while Emissary-ingress runs on Envoy Proxy. Each has strengths, and published throughput numbers vary widely by workload, plugin/filter chain, and hardware. Neither project publishes a single authoritative head-to-head figure, so treat third-party benchmarks as approximate and test against your own traffic. ### Which has a larger plugin ecosystem, Kong or Emissary-ingress? Kong has a larger extension catalog — its Plugin Hub ships 100+ plugins across authentication, traffic control, transformations, logging, and security, though some advanced plugins are Enterprise-only. Emissary-ingress extends through Envoy filters and supports custom Envoy/WebAssembly extensions, a smaller and lower-level model that leans on external services for some advanced policy. ### What are some alternatives to Kong and Ambassador (Emissary-ingress)? The API gateway space also includes Apache APISIX, Traefik, Tyk, and Gloo Edge, among others. Apache APISIX, for example, is built on NGINX/OpenResty with etcd and offers both a Kubernetes Ingress Controller and standalone deployment. Which fits depends on whether you prioritize Kubernetes-native design, deployment flexibility, or plugin breadth. ## Related comparisons [Kong vs Traefik](https://api7.ai/kong-vs-traefik) · [Kong vs Gloo Edge](https://api7.ai/kong-vs-gloo-edge) · [Apache APISIX vs Kong](https://api7.ai/apisix-vs-kong) · [All gateway comparisons](https://api7.ai/api-gateway-comparison) ## Ready to get started? For more information about full API lifecycle management, please contact us to Meet with our API Experts. [Contact Us](https://api7.ai/contact)