What are Devbox and preview URLs in Lapdev?

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.