Try Lens Agents on your laptop#

Install the full Lens Agents platform on your own machine, in a dedicated local single-node cluster with its own minikube profile, isolated from any existing clusters. Then launch Prism Agent, Lens Agents' ready-made managed agent, and chat with it in your browser. This path needs local Kubernetes tooling (docker, minikube, kubectl, helm). Run the install yourself step by step, or hand it to a coding agent with one prompt.

Try the Quickstart

The Quickstart runs on one cloud VM on a public HTTPS address, with nothing to install on your laptop.

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), 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. With a coding agent you can start without them: it prompts you to install any that are missing.

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.14+)	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 to connect the install to Lens Hub) and a Lens ID account. Sign up at app.k8slens.dev if you don't have one.

You also need an inference-provider credential for the platform's managed inference — the agent's LLM runs through it. The step-by-step Step 2 has tabs for OpenRouter, AWS Bedrock, Azure, and OpenAI; OpenRouter is the fewest steps, with one API key and no cloud account, IAM role, or region to decide first. Supported providers lists every backend the platform serves. A coding agent can't create the Lens ID account or the credential for you, so have both ready before you start.

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.

Install and launch Prism#

Both tabs end in the same place: the platform admin UI and Prism's chat UI, on the URLs above.

Step by stepWith a coding agent

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 at least 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. The tabs are alternatives for a first install, not a limit: set the values from more than one tab in the same helm install, or add a provider later with helm upgrade --reset-then-reuse-values and its values. An inference provider lists every provider's minimum values.

OpenRouter (fewest steps)AWS Bedrock (chart default)Azure (Claude on Foundry)OpenAI (GPT)

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.openrouter.token="<openrouter-api-key>" \
  --wait --timeout 10m

inference.openrouter.token — your OpenRouter API key, forwarded upstream as a bearer token. With it set, every organization can use the provider, and there is nothing else to configure.
Prism picks its own models on this backend and defaults to openai/gpt-5.6-sol for chat. Its long-term memory embeddings stay off here, because the vendors OpenRouter routes differ in embedding dimensionality.

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.
The platform sets no model: the agent names a Foundry deployment itself, or pin one with ANTHROPIC_MODEL in the policy's env.

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.openai.token="<openai-api-key>" \
  --wait --timeout 10m

inference.openai.token — your OpenAI API key, forwarded upstream as a bearer token. With it set, every organization can use the provider.
Optional: --set inference.openai.baseUrl="https://<host>/<prefix>" points the backend at an OpenAI-compatible endpoint instead of the vendor's platform. It must be https.

The three flags shared by every tab:

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

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

You can also omit the token altogether and add the key on the organization's Inference Keys page after you sign in; until a key is in place, no agent answers. Azure still needs its baseUrl.

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.

Every install enrolls with Lens Hub once before it runs agents. Connect this one from the browser.

Read the setup code the chart generated:

kubectl get secret lens-agents-hub-setup -o jsonpath='{.data.setupCode}' | base64 -d

Open http://localhost:3002, enter the code on the Connect to LNS Hub screen, and choose Continue to LNS Hub.
Sign in to Lens Hub with your Lens ID and choose who owns the installation. Lens Hub sends you back to the platform.
Sign in with your Lens ID. Create an organization if you have none; its creator is its admin, which you need to create sandboxes.

See Hub enrollment for what this sends. 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 OpenRouter, all AWS Bedrock, all Azure, or all OpenAI.

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 (OpenRouter, AWS Bedrock, Azure, or OpenAI — each appears only when the platform was installed with that provider's inference.* values 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=openrouter` (or `bedrock`, `azure`, or `openai`, 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.

This is the fastest local path. Hand the setup to a coding agent (Claude Code, Codex, OpenCode — CLI or desktop app) and let it drive: it installs the Lens Agents admin skill, stands up the platform, launches Prism Agent, and returns both URLs, pausing only for browser sign-ins.

The setup prompt#

Open your coding agent and paste this prompt:

Setup prompt

Install the Lens Agents admin skill from
https://github.com/lensapp/lens-agents-admin-skill/tree/main/lens-agents-admin
and follow it to set up Lens Agents.

It prompts you to install any missing host tools, asks which inference provider you hold, and installs the platform to match.

Run the setup#

To set up Lens Agents with a coding agent:

Open your coding agent and paste the setup prompt.
Install any missing host tools when the agent prompts you.
Complete the browser sign-ins when the agent pauses for them — connecting the install to Lens Hub and signing in, described in Step 4 of the Step by step tab.

The agent stands up the platform, launches Prism Agent, and returns the platform admin UI URL (http://localhost:3002) and the Prism chat UI URL (http://<slug>.localtest.me:3002).

To install the admin skill manually before running it — or to see the per-agent install commands — see Skills.

If something goes wrong#

The agent runs the same commands as the step-by-step install, so the same failures and fixes apply. See Troubleshooting for sandbox startup failures, unreachable chat URLs, and provider mismatches. To tear the trial down, follow Clean up.

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. Add one with `helm upgrade --reset-then-reuse-values` and the values from a Step 2 tab: `inference.openrouter.token`, `inference.bedrock.token`, `inference.azure.baseUrl` + `inference.azure.token`, or `inference.openai.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.