How to Connect a Kubernetes Cluster to Lapdev
Updated
You connect a cluster to Lapdev by installing the lightweight lapdev-kube-manager deployment inside it. That component opens an outbound TLS tunnel to Lapdev, so you don't need to open any inbound port on your firewall. Once connected, Lapdev reads the workloads already running in your cluster and uses them as the source of truth for the environments it builds.
What the connection actually does
Lapdev treats your Kubernetes cluster as the source of truth. Rather than asking you to write new YAML, it reads the workloads you already run, assembles them into App Catalogs, and keeps every environment in sync with the manifests you ship to production.
The practical consequence: your existing production or staging manifests define what a development environment looks like. There is no separate set of environment definitions to maintain.
Connection steps
- Install the
lapdev-kube-managerdeployment. This is the only component you add to the cluster. It is described as lightweight. - Let it establish the tunnel. The manager opens an outbound TLS tunnel to Lapdev. Because the connection is outbound, you do not need to open a port on your firewall to your cluster.
- Create an App Catalog. Select the workloads that make up your application. Lapdev automatically pulls the related ConfigMaps, Secrets, and Services into an App Catalog blueprint.
- Launch environments. Spin up personal namespaces, shared team baselines, or cost-efficient branch environments. Lapdev keeps them in sync and highlights when production manifests change.
Why the outbound tunnel matters
The security-relevant design choice here is directionality. A typical in-cluster agent that needs to be reached from outside requires an inbound rule, a load balancer, or an exposed endpoint. Lapdev's manager instead dials out over TLS, which means the cluster initiates the connection and no firewall port needs to be opened toward it. If your security posture restricts inbound access to clusters, this is the detail to check first.
What you get after connecting
| Capability | What it does |
|---|---|
| App Catalogs | Defines your application once by reading workloads already running in production or staging; eliminates YAML drift |
| Environment models | Personal namespace, shared baseline, or branch only the services you modify — Lapdev automates routing and sync for each |
| Devbox | Intercepts traffic to localhost and attaches your IDE |
| Preview URLs | Share production-grade preview URLs with PMs, QA, or stakeholders |
Common points to verify before you start
- Cluster access for the install. You need to be able to deploy
lapdev-kube-managerinto the cluster. Confirm you have the permissions to create that deployment. - Which workloads to include. The App Catalog is built from workloads you select, and Lapdev pulls in the related ConfigMaps, Secrets, and Services automatically. Decide up front whether you are cataloging from production or staging.
- Firewall direction. Because the tunnel is outbound TLS, the check is whether your cluster can reach Lapdev outbound — not whether Lapdev can reach in.
Lapdev is currently in public beta, and a pricing page exists at lap.dev/pricing. Details on plan limits and any account requirements are not specified in the available material, so check the pricing page and docs directly before assuming what the beta includes.