Why Veris
Stateful twins of the services your code calls, driven by your coding agent.
Veris runs stateful twins of the APIs, databases and services your code depends on. Coding agents build and test integrations against them instead of against a live vendor account.
A twin behaves like the real service, including its error shapes and its refusals, and it holds real state between calls. Your code reaches one without changing: same hostnames, same credentials, same client library. Where an address does move it moves through a variable your code already reads, never through an edit — a vendor base URL production already sets, or a twin with no hostname to intercept, such as a database, whose URL the run hands to your command.
What it is for
- Build integrations. The agent develops against a working service rather than a stub it wrote itself.
- Reproduce bugs. Recreate the exact dependency state and failure a report describes.
- Verify before a pull request. Cover the success path, the edge cases and the failures a real vendor will not produce on demand.
Core components
- Environment. The named list of twins. Defined once, outlives every run.
- Sandbox. One isolated running copy of an environment. Has a TTL, gets thrown away.
- Twin. One simulated vendor inside a sandbox.
- World. What a twin holds: its rows, its files, its armed failures, and the clock it shares with the other twins in that sandbox.
- Your tests. The part that does not change. They run where they always ran, and reach a sandbox without knowing it.
One environment, many sandboxes. Each sandbox runs its own twins, and each twin holds its own world.
Works with your setup
Use Veris from Claude Code or Codex. The usual path runs your tests on your own machine in a container, which needs Docker; setup takes a direct path, with no container, when your code already reads each vendor’s URL from an environment variable production sets.