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.
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
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.
Frequently asked questions
Related comparisons
Kong vs Traefik · Kong vs Gloo Edge · Apache APISIX vs Kong · All gateway comparisons
Ready to get started?
For more information about full API lifecycle management, please contact us to Meet with our API Experts.
