Ephemeral clusters, cost, and how the management cluster keeps the fleet small.

A purpose-built Kubernetes management platform that empowers development teams with short-lived, lower-cost K8s clusters provisioned natively inside your own AWS or GCP environments. Not GKE. Not EKS per tenant cluster. A developer picks an admin cluster profile (1-node, 3-node, 5-node, or custom), gets a real API and worker VMs, then tears it down — or Lattice hibernates it when idle and deletes it after three idle days.

One managed Kubernetes cluster per region — EKS on AWS, GKE on GCP — that Lattice provisions and tunes for one job: hosting tenant control planes. It runs Cilium as the CNI, the Kamaji operator, cert-manager, ExternalDNS, Envoy Gateway for the shared regional ingress, Prometheus and Grafana, OpenCost, Headlamp, and cloudtty. It is the only managed control plane you pay for; every tenant cluster's API lives on it.

A real Kubernetes cluster that exists for hours or days, not quarters. It has its own API and worker VMs, runs on spot instances, hibernates when idle, and expires automatically. Ephemeral is the default here, not an add-on you configure.

Enterprises that want to give every user their own real Kubernetes cluster — one per person, not a shared namespace — and platform admins who refuse to clone GKE/EKS for every tenant cluster. Credentials stay secure behind a browser web terminal, so users never handle raw kubeconfig.

The management cluster is. AWS always provisions EKS; GCP always provisions GKE — one managed cluster per region, pinned to a single availability zone (one datacenter). Tenant clusters are Kamaji TenantControlPlanes hosted on that management cluster, not another EKS or GKE SKU. You pay the EKS/GKE control plane once per region, then spot worker VMs for ephemeral clusters. Azure is not available yet.

The account owner and admins publish cluster profiles — 1-node, 3-node, 5-node, or a custom worker count, spot or on-demand workers, with or without a load balancer, optional egress gateway, and management-cluster vs dedicated VPC. Each profile is stored in Lattice’s database for that organization. Developers pick a stored profile when they create a cluster; Lattice records which profile launched it. They cannot resize a production-shaped node group on the fly.

Yes. The account owner and admins pin preferred AWS/GCP regions and one AZ (one datacenter) per region in Site configuration. Management clusters and ephemeral clusters only land there. Developers pick among those ready regions. Empty preference means the full catalog is allowed, defaulting to the region’s a zone.

No — one shared load balancer per region serves every tenant cluster. Lattice provisions a single ingress load balancer on the management cluster and routes each app by hostname, like app.us-west-2.dev.acme.lattice, as an HTTPRoute on the regional Gateway. You do not pay for a new NLB per tenant cluster. A profile can still put a TenantControlPlane API on its own NLB, and egress NAT is off unless that profile enables Istio or Cilium.

Yes. Connect AWS or GCP once. Worker nodes and networking live in that account. Lattice does not host the nodes. Azure support is planned.

The same steps as the Clastix Kamaji getting-started guides. On AWS, Lattice creates EKS with OIDC, the EBS CSI driver, and a single-AZ node group in a 192.168.0.0/16 VPC. On GCP, it creates a GKE cluster with the PD CSI driver. Either way it installs Cilium as the CNI, then cert-manager v1.18.3, ExternalDNS, and the Kamaji helm chart in kamaji-system, patches the cloud's default StorageClass (gp2 on EKS, standard-rwo on GKE), and stands up the default etcd DataStore. It also installs Envoy Gateway plus the GatewayClass that programs the shared regional ingress, kube-prometheus-stack, OpenCost, Headlamp, and cloudtty. The management cluster is Ready only after the Kamaji operator is Available.

Each tenant cluster is a Kamaji TenantControlPlane on the management cluster: its own kube-apiserver, etcd, certificates, CoreDNS, kube-proxy, and konnectivity on port 8132, running as pods on the management cluster's nodes. The management cluster runs the Kamaji operator that reconciles them and a shared etcd DataStore for their state. Tenant worker VMs join that API with kubeadm — they never run a control plane of their own.

Lattice applies a TenantControlPlane to the management cluster, pulls the admin-kubeconfig secret, issues a kubeadm join token, and launches worker VMs — from the CAPA Ubuntu 24.04 AMI on AWS, or a GCE Ubuntu 24.04 image on GCP. Tenant clusters run Cilium, the same CNI as the management cluster. Nodes sit in the management cluster's VPC.

Connect with an IAM role — Lattice never stores your AWS keys. Create a role named lattice-provisioner that trusts Lattice's account, pinned to the external ID shown in Cloud setup, and attach the least-privilege policy for EKS, EC2/VPC, Elastic Load Balancing, tagging, and iam:PassRole. Lattice assumes the role on demand and uses short-lived credentials that expire in 15 minutes. The CloudFormation template on the setup page creates the role with exactly these permissions. The management cluster also runs the Cluster API AWS infrastructure provider (CAPA) with those temporary credentials to create tenant worker EC2 instances and security groups. Developers never see any cloud credentials.

• EKS cluster IAM role
• EKS node IAM role

Create an EKS cluster service role named lattice-eks-cluster, trusted by eks.amazonaws.com, and attach AmazonEKSClusterPolicy. Create a node role named lattice-eks-node, trusted by ec2.amazonaws.com, and attach AmazonEKSWorkerNodePolicy, AmazonEC2ContainerRegistryPullOnly, and AmazonEKS_CNI_Policy. The lattice-provisioner role needs iam:PassRole for these two role ARNs in the same AWS account ID entered in Cloud setup. These are service roles; they are separate from the provisioner role Lattice assumes for provisioning and tenant workers.

• AWS EKS cluster role instructions
• AWS EKS node role instructions

The management cluster runs Cluster API with the AWS infrastructure provider (CAPA) using the same credentials. When a tenant cluster is created, CAPA launches worker EC2 instances and their security groups in the management cluster's VPC, driven by a MachineDeployment per worker pool. Keep the provisioning principal's required EC2 permissions available in each enabled region, and rotate the stored key if it is revoked. Do not give the key to developers.

• Cluster API provider AWS documentation

A real Kubernetes cluster meant to last hours or days, not quarters — ephemeral by design. Bring it up for a pull request, tear it down when the branch merges. If nobody uses it for three days, Lattice deletes it.

Lattice hibernates it: worker VMs scale to zero and the API stays. The next kubectl command or terminal wakes it in seconds. If it stays idle for three days, Lattice deletes the API and the workers. We email the owner before that.

Name it, pick a region and a stored cluster profile, create. When the API is ready you get kubeconfig and a browser terminal with KUBECONFIG already set.

Delete from the cluster page. That removes the hosted API and the worker VMs. Or do nothing — idle expiry does it.

Three days idle by default. Extend life from the cluster page: 1, 3, or 7 days. We email the owner before it expires. Opening the terminal counts as activity.

The account owner. They set an account-wide ceiling on a single extension (7 days by default) in site configuration, and can set a tighter cap per cluster profile for the teams that use it. A cluster created from a profile inherits that profile's cap; otherwise it uses the account default. The extend dialog only offers options within the cap.

Yes. Anyone in the org can open the cluster, download kubeconfig, or use the web terminal. Isolation is per cluster, not per user.

You do not pay a managed control-plane fee for every tenant cluster (EKS and GKE charge for that around the clock, even when idle). Lattice hosts the API on the shared management cluster; workers hibernate when idle and run on spot, so you pay for the minutes a cluster is awake. After three idle days those VMs are gone.

When a cluster is idle, Lattice hibernates it: worker VMs scale to zero and the API stays. The next kubectl command or terminal wakes it in seconds. You pay for compute only while the cluster is awake — not for the nights and weekends it sat untouched. Idle clusters that stay asleep for three days are deleted.

Yes. Worker pools run on AWS Spot or GCP Spot VMs with on-demand fallback, so a tenant cluster costs up to ~70% less than on-demand. A cluster that is designed to be deleted is exactly the workload spot pricing is built for. Admins choose spot or on-demand per cluster profile.

Free is one cluster and up to 3 seats. Pro is $49 / month including 5 development clusters, then $12 per additional cluster (up to 25 clusters and 25 seats). Enterprise is $199 / month including 25 clusters, then $9 per additional cluster (up to 150 clusters and unlimited seats). Company SSO is on Pro and Enterprise. The account owner adds a card when upgrading. Cloud compute is billed by AWS or GCP separately.

The worker instances, disks, and load balancers for clusters that are actually running — on spot where the profile allows. Not a weekend of forgotten nodes. Not a second EKS/GKE control plane per intern experiment.

An unused EKS cluster still bills the control plane (~$73/month each) plus nodes. Ten forgotten tenant clusters is ten of those. Lattice: no per-tenant-cluster control-plane SKU, and idle delete removes the nodes.

vCluster is a virtual API on shared host nodes — cheap to start, but the host runs 24/7, every tenant cluster inherits its version and CNI, and forgotten vClusters keep burning host CPU. Lattice gives each tenant cluster its own API and worker VMs, hibernates them when idle, runs them on spot, and deletes idle clusters. You pay for the minutes a cluster is up.

Infrastructure run-rate sits at the bottom of every fleet page. Admins see the total before finance does.

Every management cluster ships OpenCost alongside Kamaji, so cost is allocated from real Kubernetes usage — per namespace, per TenantControlPlane, per worker — not a flat estimate. It reads the same Prometheus that scrapes your clusters.

Yes. Every management cluster ships Headlamp, the CNCF Kubernetes web UI, so you can browse workloads, logs, and events across the management cluster and every TenantControlPlane without installing anything yourself.

Yes. Every management cluster runs the cloudtty operator, and each tenant ships a CloudShell CR. That serves a full kubectl terminal in the browser against your TenantControlPlane — no kubeconfig download, no local tooling. The CloudShell is a ClusterIP Service inside the tenant; FRP carries it out through the shared regional NLB, so the terminal needs no per-cluster load balancer and your cluster credentials never leave the browser session. Lattice also has a built-in terminal on the cluster page.

One crawl of every development cluster: region, version, nodes, owner, idle timer, cost. Node count and gateways are the admin scale, not a leftover GKE/EKS node group.

The admin view of the fleet. List, open, kubeconfig, terminal, extend life, or delete. Plan caps (1 / 20 / 100) stop unbounded sprawl.

Idle expiry is on by default. Emails go out before delete. Caps on the plan. Run-rate on screen. That is the whole policy — not a ticket queue.

Anyone invited to the org. The first sign-up owns the account and invites the team.

The account owner or an admin can send invitations during first-run setup or later from People. Invite each person using the email address they will sign in with. Developers can belong to one team, and team profile access controls which cluster shapes they can launch.

Yes. Cloud credentials stay on the account. Developers get kubeconfig for the cluster they created, not the AWS or GCP keys.

vCluster is a virtual API on shared host nodes — version, CNI, and kernel follow the host, and the host runs 24/7. Lattice gives each tenant cluster its own API and its own worker VMs, hibernates them when idle, and runs them on spot. You pick Kubernetes version, CNI, instance type, and AMI.

Those are full managed clusters: billed control plane, multi-AZ HA, production node groups, add-on sprawl. A PR does not need that. Lattice gives a hosted API plus the worker, load balancer, egress, and VPC shape from an admin profile, all in one AZ.

These are development clusters. Spreading a tenant cluster across three AZs costs more and buys failover you do not need for a pull request. Management cluster nodes, tenant workers, and the regional ingress sit in one AZ / one datacenter. AWS still creates a second empty subnet so the EKS API can come up (an AWS requirement); no Lattice nodes run there. GKE management clusters are zonal.

Not yet. Connect AWS or GCP. Azure AKS management clusters are planned.

Weaker than a separate EKS account, stronger than a namespace or a vCluster on a shared host. Each tenant cluster has its own API and worker VMs. Control planes share the management cluster. Scale is intentionally small and uniform.

Download kubeconfig from the cluster page (or the direct link). Point kubectl at that file. Certificates are per cluster.

A browser shell that opens in a new tab with KUBECONFIG already set for that cluster. kubectl get nodes works without copying a file. Using it counts as activity for the idle timer.

On cluster create you can point Lattice at your CNI (Helm/OCI), your AMI or GCP image, and your container registry. Workers are launched in the same VPC as that region’s management cluster so they can actually reach those resources.

Private ECR, Artifact Registry, custom AMIs, and CNI charts are usually not on the public internet. Admins should keep those in (or peered with) the management cluster's VPC. Lattice will not put BYO workers in an isolated network they cannot pull from.

Yes. The account owner can delete the entire organization at any time from Site configuration. That wipes members, clusters, credentials, and billing. It is protected by the owner’s two-factor authentication — a live authenticator code or a one-time backup code — plus typing DELETE. Invited members do not have 2FA; they use SSO.

The account owner should enable an authenticator app during first-run setup. TOTP and backup codes protect owner sign-in and high-impact organization actions. Invited members use the configured company identity provider when SSO is enabled; SSO is optional.

Yes. Email-and-password signup sends a verification link, and the address must be verified before password sign-in. Delivery uses Resend: set RESEND_API_KEY and MAIL_FROM in the deployment environment and verify the sender domain in Resend. Workforce SSO trusts the configured identity provider's signed OIDC response.

No. SSO is optional. The account owner can configure Google Workspace, Microsoft Entra ID, Okta Workforce Identity, PingFederate, OneLogin, or another SAML/OIDC provider during setup or later in Site configuration. Without SSO, invited users can use email and password after verifying their address.

The account owner can configure Google Workspace, Microsoft Entra ID, Okta Workforce Identity, PingFederate, OneLogin, or another OIDC or SAML 2.0 provider for the organization's email domain. Members enter their company email on the sign-in page; Lattice looks up the domain and routes them to the configured provider. Download SP metadata from /api/sso/saml/metadata for SAML setup.

Ten one-time codes issued when the account owner connects an authenticator app. If the owner loses the phone, a backup code signs them in or authorizes deleting the organization. Each code burns after use. Generate a new set from Site configuration; the old set stops working.

Free until you need more than one cluster or more than 3 seats. The account owner checks out with Stripe to activate Pro or Enterprise. The platform fee covers the included clusters; only clusters beyond that allowance are billed per unit, and the quantity follows how many development clusters you actually have. Lattice emails a receipt after each paid invoice and alerts on failed or past-due charges.

Email verification, welcome, invitations, password reset, Stripe receipts, billing alerts, and idle-cluster expiry warnings. Verification requires Resend delivery; other transactional mail can fall back to the console notice list when Resend is not configured.

No. Conversion events are first-party (landing → signup → cloud → cluster → paid). The account owner can read the funnel under Funnel. Optional Plausible is cookieless if you set it.

The account owner can turn on Cloudflare Turnstile under Site configuration. The widget runs on sign-up, sign-in, company-email lookup, and password reset. When Lattice sits behind Cloudflare, requests with a low bot score are refused even without a widget. Installs without keys skip the check so the first account can still be created.

Privacy and Terms are linked in the footer and required on email sign-up. They cover cloud credentials, throwaway clusters, Stripe, and org deletion.

Support chat for the team, Discord for the community, or this FAQ.