lap.dev

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.

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:

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.

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

1. Install the lapdev-kube-manager deployment. This is the only component you add to the cluster. It is described as lightweight.
2. 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.
3. 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.
4. 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

Common points to verify before you start

• Cluster access for the install. You need to be able to deploy lapdev-kube-manager into 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.

Devbox and preview URLs are the two developer-facing features in Lapdev that sit on top of the environments it builds from your existing Kubernetes manifests. Devbox lets you intercept traffic destined for a service and route it to your local machine so you can run and debug code locally while still using the cluster's real dependencies. Preview URLs give each environment a shareable, production-grade address so PMs, QA, or stakeholders can open it without any local setup. Both assume you have already connected a cluster and created an App Catalog, since that is what defines the workloads and routing they operate on.

Devbox: run part of the stack locally, keep the rest in the cluster

The problem Devbox targets is the "100 copies of every service" trap. If every developer needs a full replica of the stack just to test one service, you pay for it in cost and in drift from production.

Devbox takes the opposite approach:

• Traffic interception. Devbox intercepts traffic that would otherwise go to a service in your environment and redirects it to localhost, where your locally running process handles it.
• IDE attachment. You attach your own IDE to that local process, so breakpoints, hot reload, and your normal tooling all work as usual.
• Real dependencies stay remote. Everything you are not running locally — databases, queues, upstream services — keeps running in the Kubernetes environment, so you are not mocking your way around the parts that actually break.

The practical result: you iterate on one service at full local speed while the surrounding system behaves like the deployed one.

When Devbox is the right fit

Use Devbox when your inner loop is dominated by one or two services you are actively changing, and the rest of the stack is stable enough to leave in the cluster. It is less useful if you need to change several services in lockstep, since you would be intercepting and running each of them locally anyway.

Preview URLs: a shareable address per environment

A preview URL is a production-grade URL attached to a Lapdev environment. Instead of asking a reviewer to clone a repo, install dependencies, and run the stack, you send them a link.

What that buys you:

• Reviewers without a dev setup. PMs, QA, and stakeholders open the URL in a browser. No cluster access, no local toolchain.
• Production-aligned behavior. Because the environment is built from the same manifests that ship to production, what the reviewer sees reflects the real routing and configuration rather than a hand-rolled demo.
• One click to share. Lapdev's description frames sharing as a single action, which matters when the alternative is a written setup guide per review.

When preview URLs are the right fit

Reach for preview URLs whenever feedback needs to come from someone who will not run the code themselves — design review, acceptance testing, a stakeholder demo. If your reviewers are all engineers who already run the stack locally, the marginal value is smaller.

How the two fit together

They are complementary rather than alternatives. A common pattern is to iterate with Devbox until the change behaves correctly, then share the environment's preview URL for sign-off.

What you need before either works

Both features depend on the same setup chain, so the prerequisites are shared:

1. Connect your Kubernetes cluster. Install the lightweight lapdev-kube-manager deployment. It opens an outbound TLS tunnel to Lapdev, so you do not need to open a port on your firewall to the cluster.
2. Create an App Catalog. Select the workloads that make up your application; Lapdev pulls the related ConfigMaps, Secrets, and Services into the blueprint. This is what eliminates YAML drift and keeps environments in sync with what you ship.
3. Launch an environment. Personal namespace, shared team baseline, or a branch environment — Lapdev handles routing and sync for each model.

Devbox and preview URLs operate on the environment that comes out of step 3. Without an App Catalog, there is no defined set of workloads for Devbox to intercept against or for a preview URL to expose.

Common sticking points

• Expecting Devbox to replace the environment. It does not. It redirects traffic for the services you choose; the environment still has to exist and be in sync.
• Treating preview URLs as public demos. They are tied to an environment built from your manifests, so access and lifecycle follow that environment, not a separate hosting setup.
• Skipping the App Catalog. Pointing Lapdev at a cluster and expecting environments to appear is not the flow — the catalog is the step that turns running workloads into something launchable.

Lapdev is in public beta, and pricing details are published on its pricing page rather than assumed here.

Lapdev is a Kubernetes development environment platform that turns the manifests you already run into production-aligned environments for every developer. Instead of writing new YAML, you point Lapdev at your cluster; it reads your running workloads, builds an App Catalog, and spins up personal namespaces, shared team baselines, or branch environments that stay in sync with what you ship to production. It is aimed at platform teams who want to give developers realistic environments without maintaining bespoke scripts.

How Lapdev works

Lapdev treats your Kubernetes cluster as the source of truth. The workflow has four steps:

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 the cluster.
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.
3. Launch environments instantly. Spin up personal namespaces, shared team baselines, or cost-efficient branch environments. Lapdev keeps them in sync and highlights when production manifests change.
4. Iterate with Devbox and preview URLs. Use Devbox to intercept traffic to localhost, attach your IDE, and share production-grade preview URLs with PMs, QA, or stakeholders.

Core capabilities

App Catalogs

Define your application once by reading the workloads already running in production or staging. Catalogs are designed to eliminate YAML drift and power every environment Lapdev creates.

Environment models

Give every developer a personal namespace, maintain shared baselines, or branch only the services you modify. Lapdev automates the routing and sync for each workflow.

Traffic routing per developer

Lapdev routes traffic per developer without running 100 copies of every service — useful when a full application has many services but a developer only needs to change one.

Devbox and preview URLs

Devbox intercepts traffic to localhost so you can attach your IDE and debug locally, while preview URLs let you share a running environment with non-engineers in a click.

Who it's for

Lapdev fits teams that already run Kubernetes and want developer environments that mirror production without duplicating every service per developer. Platform teams get environment orchestration, traffic routing, and local debugging in one place rather than through custom scripts.

If your team doesn't run Kubernetes, or you're looking for a hosted preview service that doesn't read your existing cluster, Lapdev's model — cluster as source of truth — won't match your setup.

Availability and pricing

Lapdev is in public beta. A pricing page exists at lap.dev/pricing/, but the available material doesn't specify plan details or costs, so check that page directly for current terms. The docs and dashboard are linked from the site for setup and team management.