Prerequisites
- Docker (to run the local coordinator)
- One of the supported languages: Python 3.10+, Node.js 22+, Go, or JDK 17+ for Java/Kotlin
- A Varianz API key (
var_live_…) for the coordinator image — step 1 below. The SDK packages themselves need no credentials
1
Get and run a local coordinator
The coordinator is the service every SDK connects to. It ships as an image archive on
It logs See Running the coordinator locally for TLS and Postgres-backed
options, and Installation for the other
key-authenticated artifacts.
pkgs.varianz.io, fetched with your Varianz API key — no Google account and no gcloud.Pick the archive matching the machine that will run the coordinator — the package and
the filename differ per architecture, so use whichever line applies rather than editing one
into the other:docker load prints the tag it created. Then run it in-memory with plaintext enabled, which is
what you want for local development:LocalCoordinator listening on http://[::]:50051 (dual-stack) once ready.The key must travel in a header —
Authorization: Bearer … or x-api-key: …. A key in the
query string is rejected, deliberately: credentials in URLs end up in proxy and CI logs.Archives are per-architecture because docker load cannot read a multi-arch manifest. Loading
the wrong one succeeds and then fails to start with an exec-format error.2
Install the SDK
All Varianz packages are served from Full per-ecosystem details (Maven, Docker, platform notes) are on the Installation page.
pkgs.varianz.io — no credentials needed. Pick your language:3
Instrument a function
Give one function a VPoint name. The SDK derives its schema from the function’s types and registers it with the coordinator.
4
Enable the SDK
The SDK is disabled by default — an instrumented service with no configuration behaves as if Varianz weren’t there. Clients are also secure by default: they always verify TLS unless you explicitly allow plaintext, so the second variable below is the opt-in for the local dev coordinator from step 1 and isn’t used in TLS setups:Set both variables on the service process and on the test process. On startup the SDK logs one line confirming its state, e.g.
[varianz] ENABLED (source: env:VARIANZ_ENABLED).Java and Kotlin additionally need the
varianz-agent attached for interception — the Gradle/Maven plugins do this automatically for test and run tasks. See Configuration.5
Override it from a test
Insert a CEL stage that replaces the function’s result, wait for the service to confirm delivery, then call the function. Importing the instrumented module is what registers the VPoint and connects it to the coordinator, so the test imports from it directly.Run the test with your usual runner (
pytest, vitest, go test, ./gradlew test). The override applies only inside this test’s session — every other caller still gets the real result.What just happened
- The VPoint made
pricing/calculateinterceptable without changing its behavior — see VPoints. - The CEL stage
42.0replaced the return value for one session — see Stages and Sessions. await_sync_or_failblocked until the service confirmed it received the stage — see How tests work.
Next steps
Instrument a real service
Class methods, gRPC handlers, service registration, schemas.
Set up session propagation
One-time setup so the session ID flows through your whole service graph.
Override and observe
Conditional overrides, failure injection, and capturing samples.
Test across services
Multi-service flows, mixed-language harnesses.
