Try Lens Agents locally by hand#

Install the full Lens Agents platform on your own machine step by step — in a dedicated local single-node cluster, its own minikube profile isolated from any existing clusters — then launch Prism, Lens Agents' ready-made managed agent, and chat with it in your browser. To hand the setup to a coding agent instead, see Try Lens Agents locally with a coding agent.

Container-level isolation only

This local setup shares the node's host kernel. You get the standard sandbox harness — privilege dropping, kernel-level network lockdown (nftables/iptables), and proxy-mediated egress — but not microVM isolation. Production deployments add per-sandbox microVM isolation with a Kata Containers or gVisor runtime class, which a local minikube cluster cannot provide. Contact us to scope a production-grade environment.

What you'll end up with#

minikube (docker driver)
└── lens-agents (Helm release)
    ├── platform        ← Lens Agents server: API + Auth + Policies + Audit
    ├── postgresql      ← bundled database
    └── lens-agents-sandbox namespace
        └── prism-agent ← your agent, in an isolated sandbox

Platform admin UI on http://localhost:3002 (via port-forward)
Prism chat UI on http://<slug>.localtest.me:3002

Prerequisites#

Install these on the host, and confirm each responds:

Tool	Purpose	Check
`docker`	minikube's driver (see the note below)	`docker info`
`minikube`	the local cluster	`minikube version`
`kubectl`	talk to the cluster	`kubectl version --client`
`helm` (v3.8+)	install the chart	`helm version`
`openssl`	generate the encryption key	`openssl version`
`curl`	health checks and REST calls	`curl --version`

You also need outbound internet (to pull images and complete activation) and a Lens ID account. Sign up at app.k8slens.dev if you don't have one.

You also need one inference-provider credential for the platform's managed inference — the agent's LLM runs through it. Two providers are supported today, and you pick one in Step 2:

AWS Bedrock — a Bedrock API key.
Azure — a Microsoft Foundry resource URL and API key, with a Claude deployment.

Need a different provider (OpenAI, Google, self-hosted)? Contact Team Lens — we add them promptly.

minikube must use the Docker driver

Sandboxes lock down their network with nftables, so the node kernel needs nf_tables. The --driver=docker runs the node on your host kernel, which has it. minikube's VM drivers (vfkit, qemu, hyperkit) ship an ISO kernel built without nf_tables: the platform runs but every sandbox fails to start. Docker Desktop Kubernetes and kind work for the same reason. Do not substitute a VM driver.

Step 1 — Start the cluster#

Use a fresh, dedicated cluster — never an existing minikube

minikube start with no profile reuses the default minikube cluster if one already exists, which can collide with a cluster you rely on — and the teardown in this guide (helm uninstall, PVC deletes, minikube delete) could then remove workloads that aren't part of this trial. Always create a dedicated, named profile (-p lens-agents below) for Lens Agents, and never point the install or teardown at a shared context. Check what already exists first:

minikube profile list     # inspect existing instances — do NOT reuse them

Give it enough headroom — the platform, PostgreSQL, and a sandbox each need real resources.

minikube start -p lens-agents --driver=docker --cpus=4 --memory=6g
kubectl config use-context lens-agents
kubectl cluster-info

kubectl get nodes should show one Ready node. Every later kubectl/helm command in this guide runs against this lens-agents context.

Step 2 — Install the platform#

The platform ships as a Helm chart published to GHCR as an OCI artifact. It bundles PostgreSQL and defaults its identity provider to Lens ID, so a local install needs an encryption key, the URL it answers on, the wildcard host used for sandbox port exposure, and one inference-provider credential so the agent's LLM has somewhere to run.

Managed inference means the platform holds the provider credential and proxies every LLM call, so usage is metered, gated, and audited. Pick the tab for the provider whose credential you have; you'll select the matching provider on the policy in Step 5.

AWS Bedrock (default)Azure (Claude on Foundry)

helm install lens-agents oci://ghcr.io/lensapp/lens-agents \
  --set encryption.key="$(openssl rand -hex 32)" \
  --set config.publicUrl=http://localhost:3002 \
  --set sandboxIngress.host=localtest.me \
  --set inference.bedrock.token="<bedrock-api-key>" \
  --wait --timeout 10m

inference.bedrock.token — your Amazon Bedrock API key, forwarded upstream as a bearer token.

helm install lens-agents oci://ghcr.io/lensapp/lens-agents \
  --set encryption.key="$(openssl rand -hex 32)" \
  --set config.publicUrl=http://localhost:3002 \
  --set sandboxIngress.host=localtest.me \
  --set inference.azure.baseUrl="https://<resource>.services.ai.azure.com" \
  --set inference.azure.token="<azure-api-key>" \
  --wait --timeout 10m

inference.azure.baseUrl — the Foundry resource root on the *.services.ai.azure.com host (not the Azure OpenAI *.openai.azure.com host). Leave the surface suffix off; the proxy appends /anthropic itself. Copy the host from your Claude deployment's Target URI in the Foundry portal.
inference.azure.token — that deployment's Key, forwarded as the api-key header.
Optional: --set inference.azure.anthropic.model="<deployment>" sets the default Claude deployment name (defaults to claude-opus-4-8).

The three flags shared by both tabs:

encryption.key — 64 hex chars, used for at-rest encryption.
config.publicUrl — the URL the platform answers on.
sandboxIngress.host=localtest.me — required for sandbox web UIs. localtest.me is public wildcard DNS that resolves *.localtest.me to 127.0.0.1, so a sandbox's exposed port becomes reachable over your port-forward with no ingress.

Keeping the token out of your shell history

Both providers also accept the token from an existing Kubernetes Secret instead of --set …token: --set inference.<provider>.existingSecret=<secret-name> (default key NEXUS_BEDROCK_TOKEN / NEXUS_AZURE_TOKEN; override with existingSecretKey). On a real cluster (EKS) Bedrock can also resolve credentials from an IAM role and skip the token entirely.

Confirm the rollout:

kubectl rollout status deploy/lens-agents --timeout=5m
kubectl get pods

The lens-agents-* and lens-agents-postgresql-* pods should be Running.

Step 3 — Expose the platform#

Port-forward the service, and keep it running for the rest of the session.

kubectl port-forward svc/lens-agents 3002:3002

Confirm it answers:

curl -fsS http://localhost:3002/health && echo OK

The forward binds 127.0.0.1, and because *.localtest.me also resolves to 127.0.0.1, both the platform and every sandbox web UI are reachable from this machine over this one forward.

Note

If your resolver blocks public names that point at loopback (DNS-rebinding protection), add an /etc/hosts entry for the sandbox host from Step 5, or run a local dnsmasq wildcard for *.localtest.me.

Open the platform in your browser and activate it.

Open http://localhost:3002.
On the activation screen, follow the device-flow prompt to register this install with Lens Cloud.
Sign in with your Lens ID. The account you activate with becomes the organization admin, which you need to create sandboxes.

You land in the platform UI, logged in, with an organization. The platform is running, but the evaluation isn't finished — continue to Step 5 to launch your first agent.

Step 5 — Create the policy and launch Prism#

Prism reaches its LLM through the platform's managed inference, so it needs a policy that enables inference and a sandbox that attaches it. Create both in the platform admin UI at http://localhost:3002.

Match the provider you enabled in Step 2

Choose the same provider in all three places or the agent won't answer: the platform install (Step 2), the policy's provider, and the sandbox's LLM_PROVIDER environment variable — all AWS Bedrock, or all Azure.

Project. Use the default project, or create one under Projects (for example, demo).
Policy. Under the project's Policies, create a policy named prism-base, enable Managed inference, and choose the provider that matches Step 2 (AWS Bedrock or Azure — Azure appears only when the platform was installed with inference.azure.* set). Save.
Binding. Add a policy binding named prism-everyone that attaches prism-base to the subject everyone.

Sandbox. Under Sandboxes, click Create and set:

Field	Value
Image	`ghcr.io/lensapp/prism-agent:latest`
Command	`exec ./start.sh`
Env	`AGENT_NAME=Prism Demo`, `TEAM_NAME=Demo`, `AGENT_ID=prism-demo-1`, `LLM_PROVIDER=bedrock` (or `azure`, matching the policy)
Volume	mount path `/data`
Exposed port	name `chat`, port `3003`, auth `public`
Policy	attach `prism-base`

Open it. When the sandbox reaches running, the UI shows the exposed port's link (http://<slug>.localtest.me:3002). Open it — that's Prism's chat UI.

Exposed port: public vs private

Setting the exposed port to public makes the chat URL openable without a platform session — convenient for a local trial. Use private (requires platform auth) for anything beyond evaluation.

Troubleshooting#

Symptom	Cause and fix
Sandbox stuck in `creating`/`error`, platform fine	Almost always the `nftables` kernel — you're on a minikube VM driver. Recreate the profile with `minikube delete -p lens-agents && minikube start -p lens-agents --driver=docker …`.
`exposedPorts[0].url` stays `null`	`sandboxIngress.host` wasn't set at install. Reinstall (Step 2) with `--set sandboxIngress.host=localtest.me`.
Chat URL won't resolve in the browser	Your resolver blocks loopback DNS. Add an `/etc/hosts` entry for the `<slug>.localtest.me` host, or use dnsmasq.
Prism UI loads but the agent doesn't answer	The platform has no inference credential. Reinstall Step 2 with `inference.bedrock.token` or `inference.azure.baseUrl` + `inference.azure.token`. The chat link itself still works.
Agent answers on Bedrock but fails after switching to Azure	Provider mismatch. The platform (`inference.azure.`), the policy provider, and the sandbox (`LLM_PROVIDER=azure`) must all* name Azure. See Models.
Pods `Pending`	Cluster too small. `minikube stop -p lens-agents && minikube start -p lens-agents --driver=docker --cpus=4 --memory=6g`.

Useful logs:

kubectl logs deploy/lens-agents --tail=100
kubectl get pods -n lens-agents-sandbox

Clean up#

Confirm you're on the trial's context first (kubectl config current-context → lens-agents), then:

helm uninstall lens-agents --wait
kubectl delete pvc -l app.kubernetes.io/instance=lens-agents --ignore-not-found

To discard the whole cluster: minikube delete -p lens-agents. This removes only the dedicated profile — other minikube instances are untouched.

Ready for production?

This trial is deliberately minimal: container-level isolation, port-forward access, a bundled database, and a single inference credential passed at install. A production deployment adds microVM sandbox isolation (Kata or gVisor runtime classes), real ingress and TLS, a managed database, RBAC, and hardened inference-credential management. Contact us and we'll help you size and stand up a production-grade cluster.