What Vera stores, and where it goes

Vera runs tests against your application, so it necessarily sees your application. This page says exactly what that means — what leaves your machine, what is kept, for how long, and who else ever sees it.

It is written to be checkable. Where a claim depends on a specific behaviour, the behaviour is described plainly enough that you can verify it yourself.

The short version

• Running your tests never sends us your source code. The agent executes on your machine and reports results and artifacts.
• Connecting a GitHub repository does send it — temporarily, to propose test rules, and short excerpts are kept as reviewable evidence. This only happens if you connect a repo.
• Vera records your running application — screenshots, video, traces — because that is what a test report is made of.
• AI runs on your own API key. Your prompts go to your provider, not ours.

Running tests

When you run a test with the local agent (vera-agent), the browser and your application stay on your machine. The agent sends back:

No repository content is sent by the agent. When Vera works out which tests a code change affects, it sends file paths only — never file contents.

Self-healing and page structure

If a test step fails because an element moved or was renamed, Vera can ask an AI model to suggest a replacement selector. To do that it sends a snapshot of the page's structure (up to 256 KB).

Before that snapshot leaves your machine, Vera removes:

• the contents of every <script> block (where API keys, session tokens and bootstrapped user data usually live)
• stylesheet and SVG contents
• HTML comments
• the value of every input field — text, email, password, hidden (including CSRF tokens) and any other type — except the ones the page itself wrote: button labels (submit, button, reset) and checkbox/radio option values
• the contents of every <textarea>
• the text inside every rich-text editor (an element marked contenteditable), including everything nested in it — the tags and their attributes stay, so the editor can still be located, but each piece of text becomes [redacted]. An editor whose closing tag cannot be found is scrubbed to the end of the snapshot
• long inlined data: images and fonts

If a script, stylesheet, SVG or comment has no closing delimiter, Vera removes its contents through the end of the snapshot. These scans take linear time, including on malformed markup, before the snapshot size limit is applied.

Vera also replaces with ***, everywhere in the request (the snapshot, the failed selector, the step's error, and the list of controls offered when a heal picks from the page instead of having the AI write a selector):

• the run's passwords, TOTP seeds and project variable values (4 characters or longer)
• every value the run captured with a step marked sensitive: an extract, an api-request capture or a wait-for-email code or link

This happens after the removals above and before any size limit is applied. Where page text was already shortened (a control's label, an alert), a text that ends in the first three or more characters of one of these values has that ending replaced too.

The same applies when an intent block's goal is resolved on a live page, and to the copy of the request kept in your AI history. With vera-agent, the agent does this on your machine before anything is sent. A heal whose broken selector was built from one of those values may therefore be declined rather than guessed.

What remains is the structural markup a selector is built from: tags, ids, classes, data-testid, roles, labels, placeholders, <select> options and visible text outside those fields and editors.

Attributes are not removed beyond the input values above. If your application copies what a user typed into an attribute of its own (a data-draft="…", a title), that copy is still in the snapshot. If your tests type sensitive data into such an application, run them without self-healing.

Repair suggestions and diagnosis

When a failed test is repaired (Suggest fix, the MCP suggest_fix tool, or auto-repair) Vera sends the AI the test's steps, the step's error and a list of the controls on the page the test was on. Diagnose sends the steps, the errors, and the tail of the run's console and network logs. Steps are sent as written, so a {{variable}} stays a placeholder.

Values the run captured with a step marked sensitive are never stored, so after the run Vera only knows that one was captured, not what it was:

• Auto-repair re-runs the test first. That re-run's passwords, TOTP seeds, variable values and sensitive captures are replaced with *** in the list of controls, the error and the stored AI history, before any size limit is applied (with the same rule for shortened text as above).
• If Vera cannot show it has every value the run captured (no re-run, or one captured after the last point Vera learned them), a repair suggestion is made without the list of controls when the test captures a sensitive value before the failed step.
• Diagnose never sends the console and network logs of a run that captured a sensitive value. Those logs are stored as the browser produced them, and a one-time value from that run is not the one a re-run captured.

Connecting a GitHub repository

This is optional, and nothing below happens unless you connect a repo.

To propose testing rules from your code, Vera:

1. fetches a tarball of the repository at a specific commit,
2. extracts it to a temporary directory on Vera's server,
3. reads it (read-only — no writes, no command execution),
4. deletes the directory when it finishes.

Short excerpts are kept. Each proposed rule stores the file path, the line number, and up to 2,000 characters of the code the rule was read from. That evidence exists so a human can judge whether a proposed rule is real before approving it — rules are never applied automatically. The excerpts are deleted when you delete the rule or the project.

If you would rather Vera never read your repository, don't connect one. Every other part of the product works without it.

AI

Vera is bring-your-own-key. Prompts — including the page snapshots described above — go to the provider you configure (Anthropic, OpenAI or Google) under your own account and their terms.

The one exception is the free onboarding grant: a small, fixed number of AI calls for new workspaces, made with Vera's key so you can try the product before supplying one. Once you add a key, it is always used in preference.

Where data is stored

Vera Cloud runs on Railway in the United States (US West). Run artifacts — screenshots, video, traces — are stored in object storage in the same region. Credentials you give Vera (project logins, API keys, device-cloud tokens) are encrypted at rest.

Retention follows your plan. Runs and their artifacts are deleted when they pass the retention window; deleting a project deletes its runs, tests and artifacts.

One thing outlives the run, on purpose: the definition it executed. Every run freezes the exact step list it was about to run — flows already inlined, values still {{tokens}} — and that frozen copy is the only record anywhere of what a reusable flow used to look like, because editing a flow overwrites it in place. When retention deletes a run it keeps that copy, deduplicated so an unchanged test holds exactly one however many times it has run, and capped per test so it cannot grow without bound. Nothing else about the run survives: no results, no timings, no video, no screenshots. Deleting the project deletes these too.

Self-hosting

Running Vera yourself keeps everything on your own infrastructure. Two features are then available that are deliberately not offered on Vera Cloud, because they read the server's own filesystem:

• source-directory auto-configuration
• source-directory rule discovery

Both refuse to run on any network-reachable deployment, including a self-hosted one bound to a public interface. This is enforced in code, not by convention.

What Vera never does

• Sell or share your data with third parties.
• Read repositories you have not connected.
• Execute commands on your machine without your consent. Project setup actions of type command run on an agent only when the machine's operator sets VERA_ALLOW_SETUP_COMMANDS=true and the token was minted with the setup-commands capability. Either one withheld means they do not run, and the run reports them as skipped.

Questions

Anything not covered here, or a specific requirement to check against: use Send feedback in the dashboard sidebar.