If you found Lapdev in 2024, what you read described a different product. We think it's worth being direct about that.

What Lapdev was

The original Lapdev was a self hosted alternative to GitHub Codespaces and Gitpod. The idea was straightforward: spin up remote development environments on your own servers, using the same Devcontainer standard that VSCode and Codespaces support, without paying cloud prices. It used Podman and Postgres, and it was deliberately simple to run. No Kubernetes required.

We launched it in March 2024, and people tried it. The feedback was useful. But as we worked with more teams, we kept running into a different problem entirely.

The problem we kept seeing

The teams that were most frustrated with their development setup weren't working on solo projects or simple apps. They were running 10, 20, sometimes 30 services on Kubernetes. Nobody could run the full stack locally. So developers picked a subset of services to run on their machine and pointed the rest at a shared staging cluster, or they waited on a platform team to provision them a namespace.

The real bottleneck wasn't the dev box. It was the environment. Ops teams maintained separate copies of manifests for dev, staging, and production. Config drifted. A developer's environment stopped matching what was actually deployed. Feedback cycles that should take minutes stretched to days.

We could see a clean solution to this: if you treat the production Kubernetes cluster as the source of truth and build dev environments directly from the manifests you already ship, you eliminate the duplication. No separate YAML to maintain. No drift.

What Lapdev is now

Lapdev today is a Kubernetes environment platform. Here is what that means in practice:

You install a lightweight agent in your cluster. Lapdev reads the workloads already running there and assembles an App Catalog from them, pulling in the related config, secrets, and services. From that catalog, any developer on the team can spin up their own environment without writing a single new YAML file.

For teams with many services, branch environments let each developer work on just the services they are changing. A shared baseline runs everything else. Our sidecar proxy routes requests using OpenTelemetry headers so each developer sees their own version end to end. In practice this reduces infrastructure usage by up to 88% compared to giving everyone a full clone of the stack.

Devbox lets you run a single service on your local machine while it stays connected to the cluster. Your IDE attaches to a process that behaves exactly as it would in production, with real traffic, real dependencies, and real config.

Why we moved on from the original idea

The original Lapdev solved a real problem. Self-hosted remote dev environments are genuinely useful for certain teams. But the Kubernetes microservices problem is bigger, more common, and harder to solve without purpose built tooling. Every team we talked to running services on Kubernetes was dealing with some version of it.

We could have kept building the Codespaces alternative while chasing the other problem on the side. We chose to focus. That meant leaving the old product behind and rebuilding around the new one.

Try it

Lapdev is free during the public beta. If your team runs services on Kubernetes and developer environments are a source of friction, we would like to show you what it looks like. You can get started at app.lap.dev or read the install guide. If you want to talk through your setup first, get in touch.