How Lapdev Turns Kubernetes Manifests into Development Environments

Lapdev builds development environments by reading the workloads already running in your Kubernetes cluster rather than asking you to write new YAML. You install a lightweight lapdev-kube-manager deployment, point Lapdev at the cluster, and it assembles an App Catalog from your existing workloads so each developer gets a production-aligned environment. This fits teams whose cluster is already the source of truth and who want per-developer or per-branch environments without maintaining a parallel set of manifests.

The core mechanism: your cluster is the source of truth

Lapdev treats the running cluster as the authoritative definition of your application. Instead of a separate dev manifest set, it reads the workloads you already run and keeps every environment in sync with the manifests you ship to production. When production manifests change, Lapdev highlights the difference so environments don't silently drift.

This is the key distinction from tools that generate environments from a template you maintain by hand: here the input is your live cluster state, and the output is a set of environments derived from it.

How the flow works

1. Connect your Kubernetes cluster

Install the lightweight lapdev-kube-manager deployment. It opens an outbound TLS tunnel to Lapdev, so you don't need to open a port on your firewall to reach the cluster. The outbound-only direction matters for teams that can't expose inbound access to internal clusters.

2. 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. You define the application once, and that catalog powers every environment Lapdev creates — which is what eliminates YAML drift between environments.

3. Launch environments

From the catalog you can spin up:

• Personal namespaces — one environment per developer.
• Shared team baselines — a common environment a team works from.
• Branch environments — cost-efficient environments that branch only the services you modify.

Lapdev automates routing and sync for each of these workflows, so you don't hand-write per-environment routing rules.

4. Iterate with Devbox and preview URLs

Devbox intercepts traffic to localhost so you can attach your IDE and debug locally against the environment. Preview URLs let you share a production-grade environment with PMs, QA, or stakeholders in a click.

Why the App Catalog approach reduces drift

The practical effect: the thing you maintain is your production manifests, and the environments follow.

When this approach fits

Lapdev is a reasonable fit if your team already runs Kubernetes and wants developer environments derived from what's deployed, especially if you need per-developer isolation without running a full copy of every service per developer. The per-developer traffic routing is specifically aimed at avoiding running 100 copies of every service.

It's less of a fit if you don't have a Kubernetes cluster to point at, or if you want environments defined independently of your production manifests.

Lapdev is currently in public beta, and a pricing page exists — check it directly for current plan details, since the available material doesn't specify pricing terms.