Telepresence is a widely adopted development tool for fast local development of Kubernetes applications. It is built on the CNCF Telepresence project, with extended features, including access to dashboards, auditing capability, increased security configuration for platform teams, and world-class product support from Ambassador’s Customer Support team.

Telepresence OSS is a CNCF Sandbox project. It's available on Github.

For additional feature comparison, please visit our Telepresence vs. Telepresence OSS page.

Telepresence currently works natively on macOS (Intel and Apple Silicon), Linux, and Windows.

All HTTP/1.1 and HTTP/2 protocols can be intercepted. This includes: REST, JSON/XML over HTTP, gRPC, and GraphQL.

Yes, you can either set the pod’s environment variables on your machine or write the variables to a file to use with Docker or another build process. Please see the environment variable reference doc for more information.

You can connect to cloud-based data stores and services that are directly addressable within the cluster (e.g. when using an ExternalName Service type), such as AWS RDS, Google pub-sub, or Azure SQL Database.

The preview URL functionality should work with most ingress configurations, including straightforward load balancer setups.

Telepresence will discover/prompt during first use for this info and make its best guess at figuring this out and ask you to confirm or update this.

In certain cases, Telepresence might not have been able to communicate back with Ambassador Cloud to update the intercept's status. Worry not, they will get garbage collected after a period of time.

Intercepts tagged with "Unreported" clusters simply mean Ambassador Cloud was unable to associate a service instance with a known detailed service from an Edge Stack or API Gateway cluster. Connecting your cluster to the Service Catalog will properly match your services from multiple data sources.

Yes. The cluster has to have outbound access to the internet for the preview URLs to function correctly, but it doesn't need to have a publicly accessible IP address.

The cluster must also have access to an external registry in order to be able to download the traffic-manager and traffic-agent images that are deployed when connecting with Telepresence.

The local daemon needs sudo to create a VIF (Virtual Network Interface) for outbound routing and DNS. Root access is needed to do that unless the daemon runs in a Docker container.

A single traffic-manager service is deployed in the ambassador namespace within your cluster, and this manages resilient intercepts and connections between your local machine and the cluster.

When running in team mode, a single ambassador-agent service is deployed in the ambassador namespace. It communicates with the cloud to keep your list of services up to date.

A Traffic Agent container is injected per pod that is being intercepted. The first time a workload is intercepted all pods associated with this workload will be restarted with the Traffic Agent automatically injected.

You can run the command telepresence helm uninstall to remove everything from the cluster, including the traffic-manager and the ambassador-agent services, and all the traffic-agent containers injected into each pod being intercepted. Also run telepresence quit -s to stop the local daemon running.

All components of the Telepresence application and cluster components are written using Go.

The connection between your laptop and cluster is established by using the kubectl port-forward machinery (though without actually spawning a separate program) to establish a TLS encrypted connection to Telepresence Traffic Manager in the cluster, and running Telepresence's custom VPN protocol over that connection.

• GitHub
• GitLab
• Google
• Docker

The connect sessions are counted when you can run the Telepresence connect command, or it will be done during an intercept, which automatically connects as part of the intercept process.

We currently offer 3 plans for Telepresence, depending on your need and the size of your organization - Lite, Developer and Enterprise. Please see our pricing page for more details.

We have an online Slack community with thousands of users. We try to help out as often as possible, although we can't promise a particular response time.

If you need a guaranteed SLA, we also have commercial contracts. Contact sales for more information.

Emissary-ingress and Ambassador Edge Stack are Kubernetes-native API Gateways that deliver scalability, security, and simplicity for some of the world's largest Kubernetes installations.

Emissary-ingress is a CNCF Incubating project and provides the open-source core of Ambassador Edge Stack.

Edge Stack is intended to provide all the functionality you need at the edge, including an API Gateway, ingress controller, load balancer, developer portal, and more. Go here to see full Edge Stack vs Emissary-Ingress feature comparison.

Ambassador Edge Stack uses Envoy Proxy as its core proxy. Envoy is an open-source, high-performance proxy originally written by Lyft. Envoy is now part of the Cloud Native Computing Foundation.

There are many dimensions to performance. We published a benchmark of Ambassador Edge Stack performance on Kubernetes. Our internal performance regressions cover many other scenarios; we expect to publish more data in the future.

See the Controlling the Edge Stack 404 Page how-to.

See the Protecting the Diagnostics Interface how-to.

Service meshes focus on routing internal traffic from service to service ("east-west"). Ambassador Edge Stack focuses on traffic into your cluster ("north-south"). While both a service mesh and Ambassador Edge Stack can route L7 traffic, the reality is that these use cases are quite different. Many users will integrate Ambassador Edge Stack with a service mesh. Production customers of Ambassador Edge Stack have integrated with Consul, Istio, and Linkerd2.

All Edge Stack licenses are based on Requests Per Second (RPS) through any auth filters or the rate limiter.

We offer two licenses for Edge Stack:

• Community license that allows up to 5 RPS
• Enterprise license for 6+ RPS using those features

See our pricing page for more details.

• Create an account on Ambassador Cloud with GitHub, Gitlab, Google, or Docker and select your team account.
• Navigate to this link.
• Follow the prompts to name the cluster and click **Generate Key**.
• Either follow the installation instructions there, or copy the token out and follow along with the quickstart.
  

We offer licenses for air-gapped environments where logging into Ambassador Cloud is not possible through our Enterprise license. Please contact sales for more information.

If your installation(s) routinely go over the 5 RPS limit on the Community license, our sales team will reach out to work with you on obtaining an appropriate license for your usage.

For our Edge Stack Enterprise plan, we offer standard 5x8 support, which means you can expect support during normal business hours, five days a week. If your organization requires more extensive support, there's an additional option to upgrade to 24/7 support to ensure that any issues are addressed promptly, regardless of the time of day or week.

For more information on support for enterprise, please contact sales.

We have an online Slack community with thousands of users. We try to help out as often as possible, although we can't promise a particular response time.

If you need a guaranteed SLA, we also have commercial contracts. Contact sales for more information.