What core capabilities does Lapdev offer for platform teams?

Updated

Lapdev reads the Kubernetes workloads you already run and turns them into repeatable development environments, so platform teams don't have to maintain a parallel set of dev YAML. Its core capabilities fall into four areas: App Catalogs, environment models, per-developer traffic routing, and Devbox with preview URLs. It's most relevant if your team already runs Kubernetes and wants developer environments that stay aligned with production manifests rather than drifting from them.

App Catalogs: define the application once

Instead of writing new manifests for development, you point Lapdev at your cluster. It reads your running workloads and assembles an App Catalog — a blueprint of the workloads that make up your application.

When you select workloads, Lapdev automatically pulls the related ConfigMaps, Secrets, and Services into the catalog. Because the catalog is derived from what's actually running, it eliminates YAML drift: every environment Lapdev creates is built from the same source of truth, and Lapdev highlights when production manifests change.

For platform teams, this means the "define the app" step happens once, and every subsequent environment inherits it.

Environment models: match the workflow to the task

Lapdev supports several environment types rather than a single one-size-fits-all model:

Model What it gives you Typical use
Personal namespace An isolated environment per developer Individual feature work
Shared team baseline A common baseline environment Stable shared state for a team
Branch environment Only the services you modify are branched Cost-efficient work on a subset of services

Lapdev automates the routing and sync for each workflow, so you don't hand-wire namespaces or keep environments manually in step with the cluster.

Traffic routing: one set of services, many developers

A common cost problem with Kubernetes dev environments is running a full copy of every service per developer. Lapdev routes traffic per developer instead, so you don't need 100 copies of every service running at once. Developers get their own routed environment while the underlying services stay shared.

Devbox and preview URLs: local debugging and sharing

Devbox lets a developer intercept traffic to localhost and attach their IDE, so they can debug locally against the environment rather than rebuilding containers for every change. When something is ready to show, Lapdev generates production-grade preview URLs that can be shared with PMs, QA, or stakeholders in a click.

How the pieces connect

The flow is sequential, and each step feeds the next:

  1. Connect your 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 the cluster.
  2. Create an App Catalog — select the workloads that make up your application; related ConfigMaps, Secrets, and Services are pulled in automatically.
  3. Launch environments — spin up personal namespaces, shared team baselines, or branch environments, kept in sync with production manifests.
  4. Iterate — use Devbox to intercept traffic to localhost and attach your IDE, then share preview URLs.

What to check before adopting

  • Cluster access model: the outbound TLS tunnel means no inbound firewall port is required, which suits clusters that aren't publicly reachable. Confirm this matches your network policy.
  • Source of truth: Lapdev treats your cluster as the source of truth, so your running workloads need to be the accurate representation of the app you want in dev.
  • Availability: the platform is in public beta, so evaluate it against your stability requirements before depending on it for a whole team.
  • Pricing and plan limits: Lapdev has a pricing page, but the available material doesn't specify tiers, seat limits, or costs — check the pricing page directly rather than assuming a free tier.