Skip to main content
This page takes you from zero to a passing Varianz test: a local coordinator, one instrumented function, and a test that overrides its result.

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 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:
It logs 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.
See Running the coordinator locally for TLS and Postgres-backed options, and Installation for the other key-authenticated artifacts.
2

Install the SDK

All Varianz packages are served from pkgs.varianz.io — no credentials needed. Pick your language:
Full per-ecosystem details (Maven, Docker, platform notes) are on the Installation page.
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/calculate interceptable without changing its behavior — see VPoints.
  • The CEL stage 42.0 replaced the return value for one session — see Stages and Sessions.
  • await_sync_or_fail blocked until the service confirmed it received the stage — see How tests work.
In Python and TypeScript, a test whose VPoint runs in the same process can skip steps 1 and 5 entirely: attach a plain callback with attach_stage / attachStage and neither a coordinator nor a session is involved. See local stages.You still need VARIANZ_ENABLED=true from step 4 — local stages are still the SDK, and it is disabled by default.

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.