lapdev: Create Kubernetes Development Environments

Overview

Lapdev helps teams create development environments for applications already running on Kubernetes. It uses production workloads as a starting point, so developers can work with cluster resources and dependencies without building and maintaining every environment from scratch.

The project combines a hosted control plane, an in-cluster Kubernetes manager, and the Devbox CLI. It is most relevant to teams that want isolated or shared environments, or want to debug locally while routing traffic to services in their cluster.

Key Features

• Builds an app catalog from Kubernetes Deployments, StatefulSets, ConfigMaps, Secrets, and Services.
• Creates isolated personal namespaces, shared team environments, or branch environments.
• Monitors production workloads for changes and supports applying updates to development environments.
• Routes cluster traffic to a developer's laptop through Devbox for local debugging.
• Provides HTTPS preview URLs for services.
• Uses an in-cluster manager to mirror production workloads into development namespaces.

Use Cases

• Platform teams can offer developers consistent environments based on production Kubernetes workloads.
• Developers can test changes in isolated namespaces while using real in-cluster dependencies.
• Teams can create branch environments to review changes before merging.
• Engineers debugging a service can route cluster traffic to their local machine and iterate with Devbox.
• Teams sharing a baseline environment can publish preview URLs for services without manually managing DNS and certificates.

Getting Started

Connect a Kubernetes cluster, create an app catalog, and provision an environment using the getting-started guides. See the repository README for the project overview and links to setup instructions.

Considerations

• Lapdev requires a Kubernetes cluster and an in-cluster lapdev-kube-manager; it is not a standalone local environment tool.
• The architecture includes a SaaS control plane, so teams should review the architecture documentation and assess whether that model fits their operational and security requirements.
• Repository metadata reports the license as NOASSERTION, so confirm licensing terms before adopting it.