When several application services share a public address, a gateway decides which service receives each request and applies rules such as authentication or traffic limits. The historical Ambassador project provided that front door using Envoy, the proxy that handles the traffic. It let teams describe routing alongside their Kubernetes applications. Before using old Ambassador instructions, identify whether your installation is Emissary-ingress or Ambassador Edge Stack, because their configuration and support differ.
Deployment and operating notes
This page originally described the Ambassador Envoy-based gateway. Current upstream material distinguishes Emissary-ingress from Ambassador Edge Stack; sharing ancestry does not make their packaging, features or support policies interchangeable. Both document Mapping, Listener and Host resources. Emissary requires Listener and Host resources to receive and route traffic; identify the installed product and release before applying product-specific configuration.
An existing installation should first be identified by image, chart, CRD group and version, rather than by the word Ambassador in a namespace. Inventory authentication services, rate limits, TLS origination, rewrites and cross-namespace routing before selecting a target. Preserve the existing CRDs and export their objects before a chart change. For a move to another Gateway API implementation, translate behavior explicitly: an HTTPRoute alone does not reproduce every Mapping or authentication policy. Run the replacement on a separate address and compare routing, denial and certificate behavior before switching traffic. The historical compatibility examples below are not a supported Kubernetes-version matrix.
Historical upstream link check · 2026-10-09
The recorded upstream address returned HTTP 404 on 2026-10-09; that URL was unavailable in this check. GitHub does not mark emissary-ingress/emissary archived or disabled; this does not establish active maintenance, support or compatibility. GitHub resolves the old repository identity to emissary-ingress/emissary. Link availability does not certify the historical installation instructions or current security support. The GitHub API verifies the linked repository's current location. Its repository overview is provided because the old subpage is unavailable; this is not a replacement installation guide.
Website availability is separate from project, chart and image support. Use the current guidance and primary sources on this page to assess the distribution.
Historical Kubedex content
Preserved for context. Commands, versions, prices and results below reflect the original research.
Ambassador is an open source, Kubernetes-native microservices API gateway built on the Envoy Proxy. Ambassador is built from the ground up to support multiple, independent teams that need to rapidly publish, monitor, and update services for end users. Ambassador can also be used to handle the functions of a Kubernetes ingress controller and load balancer (for more, see this blog post).
Ambassador is:
- Self-service. Ambassador is designed so that developers can manage services directly. This requires a system that is not only easy for developers to use, but provides safety and protection against inadvertent operational issues.
- Operations friendly. Ambassador operates as a sidecar process to the Envoy Proxy, and integrates Envoy directly with Kubernetes. Thus, all routing, failover, health checking are handled by battle-tested, proven systems.
- Designed for micro services. Ambassador integrates the features teams need for micro services, including authentication, rate limiting, observability, routing, TLS termination, and more.
For more background on the motivations of Ambassador, read this blog post.
You may also be interested in our ingress comparison article.
Sources & further reading
Spotted something that needs another look?
Help improve this page →