Latchpoint Start a free trial

The Kubernetes console built for GKE and EKS

Latchpoint runs against any cluster in your kubeconfig. On GKE and EKS it goes further: it signs your team in, calls the cluster as each person so everyone sees exactly what their RBAC allows, and brings in Cloud Build, Cloud Logging, ECR, CloudWatch and node groups.

  • Self-hosted in your own cloud
  • Every action as the signed-in person
  • Hash-chained audit log
Latchpoint's Topology page for the shop namespace: two HTTPRoutes feed Services, Deployments and pods, with the crash-looping payments-api marked in red, storefront holding live connections to the checkout Service and to CDN addresses, payments-api and checkout-web reaching api.stripe.com and events.segment.io as named in their config, and the address range a NetworkPolicy allows.
Works with GKEEKSGoogleOktaIAM Identity CenterHelmArgo CDPrometheus

Find the hop where traffic stops, read why the pod crashed and roll back the change, all from one console that acts as you.

See where traffic stops

Topology draws each request's path from left to right: HTTPRoute, Service, workload, pods, and out to the hosts your workloads call outside the cluster. A broken hop turns red right where the traffic stops.

Healthy hops

Moving dots mean a Service has ready endpoints and the pods behind it are running.

Broken hops

A route to a missing Service, a Service with no ready pods, or a crash-looping pod.

Declared outside hosts

From ExternalName Services, env vars such as ANALYTICS_URL, and NetworkPolicy egress rules.

Measured traffic

Request rates from Istio or Cilium Hubble, when your Prometheus scrapes them.

Every pod, as the cluster reports it

Lists read live from the Kubernetes API and refresh on their own. Pending and crash-looping pods stand out without opening each one.

Pods list for the shop namespace with one Pending pod and two payments-api pods in CrashLoopBackOff, and storefront pods showing 2 of 2 containers ready.

Read why it crashed

Switch to the previous container to read the run that just died. The log summarizer explains the tail and answers follow-up questions.

Logs tab with Previous selected, showing ERROR connect ECONNREFUSED payments-db:5432 and FATAL exiting with code 1.

An assistant with your permissions

It reads pod status, logs, events and resources as you, so it can't see more than you can.

Roll back from the revision list

Each Deployment's History tab lists every revision with its images and change cause. Pick one and roll back after a confirmation. Helm releases get the same, with diffs between revisions.

History tab for checkout-web listing revisions 4, 3 and 2 with images, change causes and a roll back button on each older revision.

Helm and GitOps

Helm releases with decoded history and rollback, Argo CD Applications and ApplicationSets, and GitHub Actions runs.

Previews an admin can switch on

Cloud Shell, debug containers, "Why can't I?" permission answers, a network check and incident bundles for tickets.

Every resource, grouped the way you work

Workloads
Pods with logs and a terminal, Deployments, StatefulSets, DaemonSets, Jobs, CronJobs, HPAs, ConfigMaps and Secrets.
Networking
Services, Ingresses, NetworkPolicies, Gateway API routes, gateways and classes.
Storage
PersistentVolumeClaims, PersistentVolumes, StorageClasses and volume snapshots.
Observe
Prometheus metrics, alerts and targets, Cloud Logging on GKE and CloudWatch on EKS.
Cloud
Cloud Build, Artifact Registry and Workload Identity on GKE. ECR, CodeArtifact, add-ons and node groups on EKS.
Admin
Nodes, node pools, namespaces, CRDs, quotas, limit ranges and an RBAC groups view.
Feature preview

Permission errors that explain themselves

When Kubernetes says no, "Why can't I?" shows which RoleBindings would allow the action and which of their groups you're in. Then it writes the access request for you to paste into a ticket.

Running for your team in an afternoon

One Helm chart and two images, whichever cloud you're on.

Install the chart

Deploy into the cluster you want to manage, or outside it to manage many clusters across projects and accounts.

# helm/values.yaml
cloud: eks   # or gke

Connect sign-in

Turn on Google, Okta or AWS IAM Identity Center, side by side if you like. On GKE you can put the console behind Identity-Aware Proxy instead.

Share one URL

Each person signs in and sees what their RBAC allows. Developers only see the namespaces they can use. Nobody gets new access.

Built to pass your security review

Latchpoint runs in your cloud and holds no standing access to your workloads. Every request is checked against Kubernetes RBAC as the person who made it, then written to an audit log.

Identity and access

  • Single sign-on with Google, Okta or AWS IAM Identity Center, or Identity-Aware Proxy on GKE.
  • A server-side permission check runs before every action, as the signed-in person.
  • On GKE, Google Groups for RBAC works without the Cloud Identity API. On EKS, groups come from Okta, Identity Center or a static map.

Least privilege

  • The console's own cloud identity can't read application Secrets across the cluster.
  • User actions run under the user's own token on GKE, or a narrowly scoped impersonated identity on EKS.
  • Deleting a resource means typing its name to confirm.

Audit and compliance

  • Every API request is recorded with who made it and what it touched, in a hash-chained log.
  • On GKE, route the log to a retention-locked Cloud Logging bucket. Nobody, a project owner included, can shorten or delete it.
  • Reviewers get read access to that bucket alone, without project-wide logging rights.

Sessions

  • Tokens live in HttpOnly, Secure, SameSite=Strict cookies that page scripts can't read.
  • The refresh token stays server-side with an 8-hour idle limit.
  • Signing out revokes the refresh token at the provider, not only in the browser.

Your data stays with you

  • Self-hosted: the console runs in your cloud and the browser never talks to a cluster directly.
  • No analytics or telemetry is built into the console.
  • The AI assistant and log summarizer stay off until an admin sets your own model endpoint and key.

Hardened by default

  • A strict Content Security Policy, HSTS preload and the full set of security headers.
  • CORS takes an explicit allowlist, and the server refuses to start with a wildcard or with TLS checks off in production.
  • Per-user rate limits, per-IP limits on sign-in, and a guard against server-side request forgery on admin-supplied URLs.

Going through a security review? The deployment guide includes a checklist for regulated and healthcare environments: CMEK encryption at rest, handling sensitive data in logs, and audit retention. We'll walk your team through it.

Talk to us about security

Try it on your laptop first

Point it at any context in your kubeconfig, such as Docker Desktop's. No cloud account or sign-in needed. You see whatever kubectl sees.

This local mode refuses to start outside development, so it can't end up in production by accident.

# backend, on http://localhost:8080
$ cd backend && npm ci
$ NODE_ENV=development AUTH_MODE=none \
    KUBECONFIG_CONTEXT=docker-desktop \
    IN_CLUSTER_LOCATION=local npm run dev

# frontend, on http://localhost:5173
$ cd frontend && npm ci && npm run dev

Simple pricing per cluster

Every feature is in every plan. Paid plans add help from the people who build Latchpoint.

Community

Free

Self-hosted on your own clusters.

  • The full console on GKE and EKS
  • Sign-in with Google, Okta or AWS IAM Identity Center
  • Hash-chained audit log
  • The Helm chart and both images
  • Help from the community
Run it on your laptop

Enterprise

Custom

For 20 or more clusters, or strict compliance needs.

  • Everything in Team
  • 24/7 support for production outages, with a 1-hour response
  • A named engineer who knows your setup
  • Help with security reviews, Identity-Aware Proxy and CMEK
  • Custom add-ons built for your team
  • Volume pricing and invoicing
Talk to sales

A cluster counts once it's connected to Latchpoint, whatever its size. Every paid plan starts with a 30-day trial.

Questions

Anything else, write to sales@latchpoint.cloud.

On your laptop it runs against any cluster in your kubeconfig, including Docker Desktop and kind. A shared deployment, with sign-in and per-person access, runs on GKE and EKS.

No. You run Latchpoint in your own cloud and it has no analytics or telemetry built in. The AI features only call a model endpoint if an admin configures one, and then only the one you choose.

No. Every action runs as the signed-in person and Kubernetes RBAC decides whether it's allowed. The console's own identity can't read your application Secrets.

Any cluster connected to Latchpoint, whatever its size or node count. Autoscaling doesn't change your bill.

Choose Team or Enterprise to keep the support, or stay on Community. The console keeps working either way, because every feature is in every plan.

Google, Okta and AWS IAM Identity Center, which can run side by side. On GKE you can also put the console behind Identity-Aware Proxy.

Give your team one console

Start a 30-day Team trial on your own GKE or EKS clusters. Tell us how many clusters you run and we'll set it up with you.