Vexly is built so an AI agent can stand up and run your app without ever seeing the secrets it shouldn’t. The agent does the setup; you hand over only the sensitive values, and only through a channel the agent can’t read.

This page is the end-to-end workflow. Every step is an ordinary CLI command — the per-command guides have the detail.

The workflow

1. Create a project — no account needed

The agent runs vexly init to create an anonymous project. No login, no signup — it works immediately. A .vexly file is written (safe to commit); the secrets live in the cloud.

vexly init

2. Declare the keys the app needs

The agent knows which variables the app reads, so it declares them. Plain config it can set directly; for real secrets it declares the key with no value, to be filled in by you:

vexly set NODE_ENV=production LOG_LEVEL=info   # plain config — fine for the agent to set
vexly set DATABASE_URL STRIPE_SECRET_KEY       # secrets — declared empty, you fill them

set writes straight to the cloud environment — see managing secrets.

3. Request the secrets it must not see

For each value the agent shouldn’t handle, it mints a secret update request:

vexly request DATABASE_URL STRIPE_SECRET_KEY

This prints a link. You open it and paste the values; they go straight to the cloud environment. The secret never appears in the agent’s prompt, its output, or the transcript. This is the trust boundary that makes agent-driven setup safe.

Requesting is the one step that needs you signed in (vexly login) — the link is attributed to you and managed in Studio. On your own machine the agent reuses that login automatically, so it can mint the request for you.

4. Run the app with secrets injected

The agent runs your app through Vexly, which injects the secrets into the process — nothing is written to disk:

vexly run -- npm start

It can wire this into your scripts too ("dev": "vexly run -- vite"), so secrets are always present. See running commands.

What the agent can and can’t read

By default, an agent that can run can also pull the values into .env and read them. When you want an agent to use a secret but never read it, set the environment to run-only:

So the agent runs your app with real secrets, but those values stay out of its context. Run-only is set in Studio and applies to claimed projects.

Run-only keeps secrets out of an agent’s context — its transcript, output, and .env — it isn’t a wall against a hostile process. To truly contain an untrusted agent, run it where your login isn’t present (a container or CI job with only a scoped token). See access modes.

Headless and CI agents

An agent on your own machine reuses your vexly login automatically. For an agent running headless — in a container or CI — give it a scoped VEXLY_TOKEN instead, ideally for a run-only environment so it can run but not read.

Next