What you get.

Everything it does. No demo to sit through.

No port numbers

Real names like frontend.my-feature.localhost instead of localhost:3847.

Starts things in the right order

Works out what depends on what, starts it all (in parallel where it can), and shuts down cleanly in reverse.

Run your e2e tests on it

Point veld start --oneshot at a test command: it spins up every service the tests need, runs them, prints the results, then tears it all down — and the test's exit code becomes veld's. One line in CI.

Real HTTPS, no warnings

Every URL is https:// with a trusted certificate. Set up once — no browser warnings.

Waits until things are ready

You don't get a URL until the service actually responds — and veld keeps watching after it's up. Not everything in a dev environment is a web server, either: a file watcher, a background compiler, a desktop shell can all sit in the same graph, supervised and torn down with the rest, with no port and no URL.

Restarts what crashes — and remembers why

If a service falls over, veld brings the environment back on its own. Every run leaves a record: when it ran, how it ended, and its logs — so veld runs answers "why did last night's run die?" days later.

One config, many setups

Run a service locally, in Docker, or against a remote — and start your go-to combinations with one short name. Give each a number that never moves when someone adds another, and a line saying who it’s for, so “which one do I run?” has an answer for the designer and the coding agent.

A config a monorepo can live with

Comments where you need them — call the file veld.jsonc and your editor stops arguing. Split it across per-directory files so each team owns theirs. Say a value once and reference it everywhere. It deduplicates values, never structure — so opening a service’s file still tells you what it runs, and grepping for an env var still finds the line that sets it.

Your command, not the shell’s opinion

Write it as a list and veld runs it directly. A password with a space in it stays one argument — not two arguments and an incident. Want a pipe? Ask for a shell.

Secrets it never keeps

veld holds a pointer, not your password: an env var, a file, or a command that prints one. Mark it secret and it refuses to put it on a command line, where ps would read it out to the whole machine.

The bits that differ per laptop

Some values in a checked-in config aren’t project facts, they’re machine facts — which container runtime you have, how much memory this machine can spare, where a tool lives. Declare a default, and each person answers once with veld config set. Kept per machine and shared across all your worktrees, so you answer it once, not once per checkout.

Wrong config, caught early

veld lint lists every problem at once and fails CI. Typo’d variable, one that is real but means nothing where you wrote it, a preset pointing at a node that moved, a service reading a URL that only exists under some presets, secret about to leak. Better now than 9am Monday.

Many runs, side by side

Give every branch or git worktree its own environment — they run in parallel without clashing. Re-running by name just resumes.

Scripts & agents love it

Every command has a --json mode for CI, scripts, and coding agents.

A dashboard in your browser

See health, per-service memory & CPU, tail logs, search, browse past runs, and stop/restart — all at veld.localhost.

Memory numbers that are actually true

Adding up a process tree’s memory double-counts everything its processes share, so Veld reports the real footprint instead. Expand a service for a scrubbable graph of memory or CPU — by memory type, or by which subprocess is eating it.

What your build actually costs

Measuring starts when the run does, not when it finishes. Your build steps and installs are graphed while they run, and a dev server’s startup ramp is recorded — so “why does this need 12 GB” is a question you can answer.

Browser errors in your terminal

Captures the app's console logs and crashes so you can read them from the CLI.

Tell your team what changed

You move the test command; everyone else finds out when it breaks for them. Write a short note into the project’s config alongside the change — a headline and one sentence — and each teammate is told once, the next time they open the IDE. Capped at five notes and 44 characters of headline, so it stays worth reading.

The laptop stays awake

Long builds and overnight agents die when the machine suspends. One button in the top bar holds it awake — for 30 minutes, a few hours, or until you say otherwise — and lets go the moment Veld does, so nothing is left pinned on. Shut the lid and walk away: on Linux, and on a Mac set up with veld setup privileged, that works on battery too. Sharing does it for you without being asked, capped, and asked separately for mains and battery — but it will never hold the lid shut on battery unless you say so yourself.

Share with a teammate

Send a colleague an encrypted link; they open the same URLs on their machine. No accounts, no server.

Or share with anyone

veld share --web gives you a real public URL — the other person doesn't need Veld at all.

Read what your agent wrote, in place

Ask for a slide deck or an analysis written as HTML and you used to leave for Chrome to look at it. Run open deck.html in a Veld terminal, or pick it off a newest-first list showing what changed and how long ago, and it opens in a pane beside the shell that made it — then reloads itself each time that file changes — including one you reached by a link out of it, so a set of decks that link to each other behaves like one document. Served over HTTP from an origin of its own, so module scripts and fetch work where a file:// URL would render the page blank.

$ claude building the next big feature… teaching your flaky tests to pass on the first try… negotiating a ceasefire with your Docker daemon… removing three more port numbers that never existed… convincing localhost to finally love you back…

Claude is already working on it. Probably. Check back never — it'll just show up.

The commands.

What you'll actually type. Every one speaks --json.

Environments

veld start NODE:VARIANT --name NStart an environment

veld start --preset NAME|KEYStart a preset — a saved selection of nodes (e.g. fullstack). Or just veld start and pick from the list

veld start NODE --oneshotRun a command node as a one-off — start its deps, run it to completion, tear down, exit with its code (e.g. e2e tests)

veld stop [--name N] [--all]Stop a running environment

veld restart [--name N]Restart an environment

veld status [--name N]Show run status

veld stats [--processes] [--history] [--cpu]Detailed CPU & memory — split by memory type and by subprocess, with history

veld urls [--name N]Show URLs for a run

veld logs [-f] [-s TERM] [--run ID]View logs (follow, search, source filter — including past runs)

veld graph / nodes / presets / runsInspect the config and the run history

veld lintCheck the config for problems — every one at once, exits non-zero in CI

veld config --files / --why PWhich file defines which node, and where an effective value came from

veld config vars / set / unsetValues that differ per machine — answered once, shared across your worktrees

veld settings [get / set / describe]Veld’s own preferences from the terminal — describe gives an agent the type, default and allowed values

veld action NAMERun a node-defined action (e.g. open the DB in a GUI)

Sharing

veld share [RUN] [--web]Share a run over an encrypted P2P tunnel (or the open web)

veld join TICKETJoin a shared env; the same URLs materialize locally

veld sharesList shares, joins, and pending requests with transport info

veld approve / deny REQGate who connects to your share

veld unshare / leaveStop hosting, or disconnect from a joined share

Setup & misc

veld setup [privileged]One-time system setup (clean URLs need privileged; unprivileged is no-sudo)

veld initCreate a new veld.json (veld reads veld.jsonc too)

veld uiOpen the management dashboard

veld feedback nextPull the next in-browser review comment (agent-facing)

veld doctor / gcCheck extension status; clean up stale state

veld backup [now / restore]Copies of veld's own state database, and putting one back

Install.

One line. No sudo. Detects your OS and architecture.

curl -fsSL https://veld.oss.life.li/get | bash

This installs veld to ~/.local/bin. Commands auto-bootstrap on first use with HTTPS on port 18443. For clean URLs with no port suffix, run the one-time veld setup privileged — sudo once, never again. Prefer no sudo at all? veld setup unprivileged supports the full feature set on .localhost domains.

Upgrading from an older veld? Your veld.json needs "schemaVersion": "3" — earlier versions no longer load. It is a handful of lines, and the error you get names every change: the migration guide is written so you can hand it to your coding agent, then run veld lint to check the result.

Hand it to someone.

Two ways to share what you're running. Both opt-in, both encrypted.

To a teammate

Veld-to-Veld over iroh. Your colleague opens the same URLs on their own machine — and a database port you share turns up as a local port on theirs. No redeploy, no staging server.

To anyone, on the web

Expose a service to anyone with a browser — no Veld required. A self-hosted veld-gateway mints a real public URL.

End-to-end encrypted

Traffic flows through an encrypted P2P tunnel (iroh / QUIC). A relay only forwards sealed bytes — it never sees your URLs or content.

Password-protected by default

Web shares get a generated password out of the box. Send the URL and password over different channels, or use the one-link that hides the password in the URL fragment.

You approve every join

Peer shares are gated by a capability token and your explicit approval. Nothing connects without your say-so.

Opt-in per port

Consent sits on the port, not the service — share an app and withhold its admin console. What leaves your machine is explicit and auditable, and nothing is exposed by accident.

Your relays, your rules

Keep traffic on infrastructure you control with self-hosted relays (one Docker container). The free public relays are great for dev and testing; for production, run your own. Your call, per project.

No accounts, no lock-in

No sign-up, no Veld-hosted server. Shares live in your daemon and expire on a TTL; stop the run and they're gone.

Build it with your agent.

veld isn't just something your coding agent can drive — it's where the two of you meet. --json on every command, an llms.txt it can read, and a skill so it knows the ropes.

npx skills add prosperity-solutions/veld

Installs the veld skill for Claude Code, Cursor, Codex, Windsurf, and 40+ more — so your agent can configure, run, and share environments without you narrating each step.

The feedback loop

Every app veld serves gets an in-browser overlay. Review the running thing and hand comments straight to your agent — no copy-pasting screenshots into a chat.

Launch the loop. In your agent, type /veld-launch-feedback-loop and hit enter — it parks on veld feedback next and waits for you.
You comment on the live app. Click any element, leave a note — right there in the browser, on the real running page.
Your agent pulls the next item with veld feedback next — element, selector, screenshot, and your words, in one call.
It fixes the code and replies on the thread. The change hot-reloads; you see it live.
Repeat until you click Done. A tight human-in-the-loop review loop, without leaving the page.

Fun fact: this entire page was built and refined through exactly that loop.

Like if Kubernetes and localhost had a magic, agentic baby — with a gorgeous UI.