Throwaway clusters, cost, and how admins keep the fleet small.

A console for throwaway development Kubernetes on a shared control plane. Not GKE. Not EKS. A developer picks an admin cluster profile (1-node, 3-node, 5-node, or custom), gets an API, then tears it down — or Lattice deletes it after three idle days.

Teams that need a Kubernetes API for a branch or a spike — and platform admins who refuse to clone GKE/EKS for every sandbox.

The mother is. AWS always provisions EKS; GCP always provisions GKE — one managed cluster per region, pinned to a single availability zone (one datacenter). Development sandboxes are Kamaji TenantControlPlanes on that mother, not another EKS or GKE SKU. You pay the EKS/GKE control plane once per region, then worker VMs for throwaway 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, with or without a load balancer, optional egress gateway, and mother 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. Mothers and throwaway 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.

Not for workloads. Lattice provisions one ingress load balancer per AWS/GCP region. Apps get a hostname like app.us-west-2.dev.acme.lattice — an HTTPRoute on the regional Gateway, not a new NLB. A profile can still put the TenantControlPlane API on an NLB. 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 on AWS guide. Lattice creates EKS (or GKE on GCP) with OIDC, the EBS CSI driver, and a single-AZ node group in a 192.168.0.0/16 VPC. Then it installs cert-manager v1.18.3, ExternalDNS, and the Kamaji helm chart in kamaji-system, patches gp2 as the default StorageClass, and stands up the default etcd DataStore. The mother is Ready only after the Kamaji operator is Available.

A TenantControlPlane on the mother — dedicated kube-apiserver, etcd, certs, CoreDNS, kube-proxy, and konnectivity on port 8132. Lattice pulls the admin-kubeconfig secret, issues a kubeadm join token, and launches worker VMs from the CAPA Ubuntu 24.04 AMI. On AWS the CNI is Calico in VXLAN mode (IP-in-IP is Never). Nodes sit in the mother VPC.

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

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.

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 sandbox (EKS and GKE charge for that around the clock, even when idle). Lattice hosts the API; you pay worker VMs only while the cluster exists. After three idle days those VMs are gone.

Free is one cluster. Pro is $10 per development cluster / month (up to 20). Enterprise is $20 (up to 100). 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. 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 sandboxes is ten of those. Lattice: no per-sandbox control-plane SKU, and idle delete removes the nodes.

vCluster looks cheap because sandboxes share a host — but you still pay that host 24/7, and forgotten vClusters keep burning host CPU. Lattice bills workers only while they exist, shows run-rate in the console, and deletes idle clusters.

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

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.

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. Lattice gives each sandbox its own API and its own worker VMs. 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 sandbox across three AZs costs more and buys failover you do not need for a pull request. Mother 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 mothers are zonal.

Not yet. Connect AWS or GCP. Azure AKS mothers are planned.

Weaker than a separate EKS account, stronger than a namespace or a vCluster on a shared host. Each sandbox has its own API and worker VMs. Control planes share the mother. 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 mother 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 mother 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.

Only the account owner. TOTP and backup codes protect owner sign-in and organization delete. Everyone else signs in with company email through Google Workspace, Ping Identity, or SAML federation. They cannot enroll an authenticator.

Yes. The account owner configures Google Workspace, Ping Identity (OIDC or PingFederate SAML), or a generic SAML 2.0 IdP on the tenant. Members enter their company email on the sign-in page; Lattice looks up the domain and redirects to that IdP. Download SP metadata from /api/sso/saml/metadata for PingFederate.

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. The account owner checks out with Stripe to activate Pro or Enterprise. 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.

Welcome on account create, invites, password reset for the owner, Stripe receipts, billing alerts, and idle-cluster expiry warnings. When Resend is configured they go to the inbox; otherwise they land in the console notice list.

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.