Kubernetes makes deploying apps easy, well, sort of. But that 100 microservices app makes the development flow hard. You can't fit the whole app on your workstation, without pain. The most sensible way is probably running the development flow in Kubernetes itself. Have a pipeline to build and deploy your code changes. But the feedback is slow.
Tools like Skaffold can sync your code changes to pods directly, and tools like Telepresence can intercept traffic to your local machine which enables you to do local debugging. That makes things feel like good old local development again. But,
How do you manage all the Kubernetes resources? The deployments, ConfigMaps, services, secrets - who maintains them? Do developers share the same resources, or does everyone get separate environments? If they're separate, how do you keep them in sync? How do you ensure changes to the app propagate to all dev environments? And what about domains, DNS, and HTTPS for developers to actually access their work?
Lapdev Kubernetes Environment solves all these pains so that you don't have to.
Lapdev reads your production Kubernetes manifests directly from your cluster. Just tell Lapdev which workloads your app needs, and it automatically replicates:
- The workloads (Deployments, StatefulSets, DaemonSets, etc.)
- Associated ConfigMaps and Secrets
- Services and networking configuration
Your production manifests become the single source of truth - no duplicate YAML files to maintain, no config drift between prod and dev.
- Lapdev continuously monitors your production manifests for changes
- App Catalogs automatically update when their source workloads change
- Environments notify you when updates are available - sync with one click when you're ready
- No surprise interruptions during development - you control when to pull in changes
Personal Environments: Each developer gets a complete, independent copy of all workloads. Perfect for testing breaking changes or complex multi-service interactions with full isolation.
Branch Environments (Cost-Effective): A shared baseline environment runs all services once. Developers create lightweight "branch environments" for only the services they're actively modifying. Lapdev automatically routes your traffic to your version while everything else uses the shared baseline.
Lapdev includes Devbox, a CLI tool that integrates seamlessly with your environments:
- Intercept cluster traffic to your local machine for real-time debugging
- Use your local IDE, set breakpoints, and see live logs
- Transparently access in-cluster services (databases, caches, internal APIs) as if you're running inside the pod
- No complex VPN or tunneling setup required
Create Preview URLs for any service in your environment:
- Unique HTTPS URLs automatically generated for each service
- Automatic TLS certificates and DNS configuration
- Traffic proxied directly to your in-cluster services
- Optional access control - configure URLs to be accessible only to Lapdev logged-in users
- No firewall changes, no manual Ingress configuration, no cert-manager setup
Share your work with teammates, PMs, or QA instantly - they can test your changes without any cluster access or VPN.
Lapdev requires just one deployment lapdev-kube-manager installed in your cluster. That's it.
- Connect Your Kubernetes Cluster
- Create an App Catalog
- Create Your First Environment
- Start Local Development with Devbox
Learn more about Core Concepts.