A secret update request is a link for entering secret values out-of-band. An agent (or you) names the keys it needs and gets a link; whoever holds the secrets opens it and pastes the values, which go straight to the cloud environment. The secret never passes through the agent’s conversation — it just picks it up on the next run.

How it works

vexly request STRIPE_SECRET_KEY
# prints a shareable link (expires in 24h)

1. Create the request. Run vexly request KEY [KEY …], naming the specific keys the app needs. The CLI returns a link that expires after 24 hours. The named keys must already exist in the environment — declare them first with vexly set KEY if needed. Creating a request requires vexly login.
2. Open the link and enter the values. Whoever holds the secrets opens the link, sees exactly the fields to fill, and pastes the values in. No account is needed to fulfill it. The link is reusable within its 24-hour window — reopen it to fix a typo or rotate a value — and can be revoked early.
3. The values are stored in the cloud environment.
4. The app picks them up on the next vexly run (or vexly pull on a readable environment).

Name several keys at once to collect them in a single link:

vexly request STRIPE_SECRET_KEY DATABASE_URL SENDGRID_API_KEY

The whole point is the handoff: the agent hands you a link, you paste the secret there, and the agent reads it from the cloud — the value never lands in the chat transcript.

Reading vs. not reading the value

Once the value is stored, an agent on a readable environment can pull it and therefore read it. If you need the agent to use a secret without ever being able to read it, that’s run-only mode — a separate, stronger guarantee. A request controls how the value gets in; the access mode controls who can read it afterward.

Commands

Next

• Access modes — keep a value unreadable with run-only.
• Managing secrets — declare empty keys to request later.
• Agent & CI access — the agent-safe handoff in context.