Read the platform, end to end.

The Stradiva CLI is a single static binary. It runs on macOS, Linux, and Windows (x86_64 and arm64), self-updates in place, and stores credentials in the OS keychain. There is nothing to compile and no runtime to bring along.

01# macOS / Linux02curl -fsSL https://stradiva.dev/install.sh | sh03 04# Windows (PowerShell, run as user)05iwr https://stradiva.dev/install.ps1 -useb | iex06 07stradiva --version08# stradiva 3.2.1 (2026-04-18, darwin/arm64)

On corporate networks, set HTTPS_PROXY before running the installer. Air-gapped install is documented under Region pinning — the same binary mirrors are used for offline environments.

A service is a directory with a stradiva.yml manifest. Run stradiva init and the CLI generates a runnable scaffold for the runtime you pick. The default canary is five percent of traffic for ten minutes; both numbers are tunable.

01stradiva init hello --runtime node2202cd hello03stradiva deploy --region eu-west --canary 5 --hold 10m04 05# Watch traffic ramp from 5% to 100% if SLOs hold06stradiva status --watch

If the canary breaches an SLO, the deploy is held at the current weight and you're paged via the alert channels configured under Alerting & routing. No automatic promotion happens while a hold is active.

Workspaces have three built-in roles — owner, maintainer, and viewer — and arbitrary custom roles defined as OPA policies. Invites are sent by email and revocable per session.

01stradiva team invite jordan@northwind.dev --role maintainer02stradiva team list03 04# Promote later05stradiva team set jordan@northwind.dev --role owner

SSO (Okta, Entra ID, Google Workspace) lives under workspace settings. SAML metadata is exposed at /workspace/sso/metadata.xml once enabled.

Stradiva ingests OpenTelemetry over OTLP/HTTP and OTLP/gRPC on port 4317. There is no agent — point the standard OTel SDK at the collector endpoint and traces, metrics, and logs arrive together.

01import { NodeSDK } from '@opentelemetry/sdk-node';02import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-http';03 04const sdk = new NodeSDK({05  traceExporter: new OTLPTraceExporter({06    url: 'https://otel.stradiva.dev/v1/traces',07    headers: { authorization: 'Bearer ' + process.env.STRADIVA_TOKEN },08  }),09});10 11sdk.start();

Resource attributes service.name and deployment.environment are required; everything else is indexed lazily on first query.

Logs are queried with a small DSL inspired by Lucene and PromQL. Free-text search works without any syntax; structured filters use field:value pairs joined by AND / OR / NOT.

01# All errors from the checkout service in the last 15 minutes02service:checkout AND level:error | last 15m03 04# 5xx responses for one user, grouped by route05status:>=500 AND user.id:"u_94ab" | by route | last 1h06 07# Slow database calls08duration:>250ms AND db.system:postgres | last 1h | top 50

Saved queries can be pinned to a dashboard or turned into an alert with stradiva alert create --from-query.

Every captured trace can be replayed against a freshly built deployment to verify that a fix actually fixes the failing request. Replay runs in a sandboxed isolate with the original inputs and asserts equivalence on response, side effects, and downstream calls.

Retention

Replayable for 14 days (HEAD), 90 days (snapshot)

Throughput

Up to 10k traces / minute, per workspace

Mutation

Pure replay (default) or shadow-write to staging

Approval

Required when source trace contains PII

Replays cost roughly 1.3× a normal request — they reuse the cache hierarchy and downstream stubs whenever the original trace recorded an idempotent call.

Alerts route through channels (PagerDuty, Opsgenie, Slack, Webhook) and schedules (on-call rotations, follow-the-sun). A single alert can fan out to multiple channels with different severities — page the on-call for critical, post to Slack for warnings.

01alert "checkout_p95" {02  query     = "service:checkout | p95(duration) > 350ms for 5m"03  severity  = "page"04  schedule  = team.payments.on_call05  channels  = [pagerduty.payments, slack.alerts]06  runbook   = "https://runbooks.northwind.dev/checkout-p95"07}

Every build emits an in-toto SLSA-3 attestation signed by the workspace key. The attestation captures the source commit, builder identity, materials (lockfiles, base images), and the digest of every produced artifact. Verification runs inline at deploy time and out-of-band on demand.

01stradiva attest verify ghcr.io/northwind/checkout@sha256:9af...02 03# Pin a policy: only signed-by org keys allowed04stradiva policy apply policies/signed-only.rego

A canary policy is a sequence of weight steps with SLO guards. The default policy moves 5% → 25% → 50% → 100% over thirty minutes, held at each step until p95 latency and error rate are within bounds of the previous version.

01canary "careful" {02  steps   = [1, 5, 10, 25, 50, 100]03  hold    = "10m"04  abort_on {05    error_rate = ">1.5x baseline"06    p95        = ">1.25x baseline"07    saturation = ">0.85"08  }09}

Services can pin to any subset of the 22 Stradiva regions. Pinning is a hard constraint — the scheduler will refuse to place an instance in an unlisted region even under capacity pressure. For sovereignty needs, pin a service to eu-* and the corresponding data residency policy is applied automatically.

Regions

22 (8 NA · 7 EU · 5 APAC · 2 ZA/SA)

Air-gapped

Available on Enterprise (mirrored binary + offline OPA bundles)

Sovereignty

EU-only, US-only, India-only, AU-only profiles ship by default

Failover

Per-region; controllable per service via policy

Every deployment is immutable and addressable by digest. Rollback is a re-route, not a re-build — traffic shifts back to the previous version in under five seconds and the canary policy is replayed in reverse to make sure the regression doesn't bite a second time.

01# To the previous successful deploy02stradiva rollback --to previous03 04# To a specific digest05stradiva rollback --to sha256:9af0c11b...06 07# Pause a deploy without rolling back08stradiva deploy pause --reason "investigating spike"

Pipelines are defined in HCL. Each pipeline has exactly one source and one or more destinations; transformations are declared as step blocks that the planner schedules in topological order. The full grammar is below — fields you don't use can be omitted entirely.

01pipeline "<name>" {02  source      = <connector>(<args>)03  destination = <connector>(<args>)04 05  step "<id>" {06    type   = "transform" | "enrich" | "filter"07    sql    = "select ... from <prev>"08  }09 10  field <name> {11    type      = "string" | "int" | "uuid" | "timestamp" | "json"12    indexed   = true | false13    pii       = true | false14    nullable  = true | false15  }16 17  retention = "<duration>"   # "30d", "1y", "forever"18  backfill  = "auto" | "manual" | "off"19  schema    = { strict = true, evolve = "additive" }20}

The connector catalog ships with 47 entries. Sources include Kafka, Kinesis, Pub/Sub, Postgres CDC, MySQL CDC, MongoDB change streams, S3, GCS, Azure Blob, HTTP webhooks, and arbitrary OTel logs. Destinations include Snowflake, BigQuery, Redshift, Databricks, ClickHouse, Postgres, Elasticsearch, S3 (Parquet/Iceberg), and any HTTP endpoint.

Sources

Kafka · Kinesis · Pub/Sub · Postgres CDC · MySQL CDC · MongoDB · S3 · HTTP · OTLP

Destinations

Snowflake · BigQuery · Redshift · Databricks · ClickHouse · Postgres · Elastic · S3 (Iceberg) · HTTP

Custom

Bring-your-own connector via WASM module (TS, Go, Rust)

Schema

Inferred on first batch; locked when pipeline goes to prod

Pipelines track schema versions automatically. Additive changes (new nullable field) deploy without intervention. Backwards-incompatible changes (type narrowing, dropped required field) require an explicit migration plan and a backfill window.

01# Show the diff between HEAD and prod02stradiva schema diff events03 04# Plan and apply a migration with a 24h backfill05stradiva schema migrate events --plan06stradiva schema migrate events --apply --backfill 24h

Backfills replay historical data through a new or modified pipeline. They run as a separate workload class so they never starve live ingest, and progress is tracked at the partition level — a failure restarts only the partitions that didn't commit.

Throughput

Up to 8× live ingest, throttled to keep live latency in budget

Concurrency

Per-pipeline cap (default 4 partitions); raise with care

Idempotency

Required — destinations must accept the same row twice

Cost

Compute charged separately from live ingest

Edge functions run inside V8 isolates. Cold start is sub-5ms because isolates share a process and warm pool. An isolate lives for as long as it has traffic, plus a configurable grace window — after that it's reaped and any in-flight work drains gracefully.

Cold start

< 5ms (p95)

Memory

128 MB default, 1 GB max

CPU time

50ms / request, 5s / cron job

Grace window

30s after last request (configurable)

01export default {02  async fetch(req: Request): Promise<Response> {03    const url = new URL(req.url);04    return new Response('hello from ' + (url.searchParams.get('region') ?? 'edge'));05  },06};

Edge code routes to the nearest region by default. To pin to a subset, attach a regions selector to the deployment. Selectors support continent codes (eu), country codes (de), and explicit region IDs (eu-fra-1).

01# EU + UK only02regions = ["eu", "uk"]03 04# Three specific regions05regions = ["eu-fra-1", "eu-ams-1", "us-iad-1"]06 07# Everywhere except APAC08regions = ["!apac"]

A globally-replicated key-value store, accessible from inside isolates with single-digit-millisecond reads and consistent writes through a regional primary. Use it for session data, feature flags, and small per-tenant config — not for large blobs.

01import { kv } from '@stradiva/edge';02 03// Read (edge-local, eventually consistent)04const session = await kv.get('session:' + cookie);05 06// Write (regional primary, strongly consistent)07await kv.put('session:' + cookie, JSON.stringify(payload), {08  ttl: 60 * 60 * 24 * 7,09});

The REST API is JSON over HTTPS, versioned through the path (/v3). Every endpoint takes a Authorization: Bearer ... header. Rate limits are per-token and exposed via the standard x-ratelimit-* headers.

01# List services02curl -H "Authorization: Bearer $STRADIVA_TOKEN" \03     https://api.stradiva.dev/v3/services04 05# Deploy06curl -X POST \07     -H "Authorization: Bearer $STRADIVA_TOKEN" \08     -H "Content-Type: application/json" \09     -d '{"region":"eu-west","canary":5}' \10     https://api.stradiva.dev/v3/services/checkout/deployments

The full OpenAPI 3.1 spec is downloadable and renders cleanly in Stoplight, ReDoc, and Swagger UI.

The gRPC surface mirrors REST one-to-one. Use it for high-frequency or bidirectional flows — control-plane traffic, log tailing, trace streams. The .proto files are versioned in the public schema registry and can be vendored or fetched at build time.

01import { createClient } from '@stradiva/grpc';02 03const client = createClient({ token: process.env.STRADIVA_TOKEN });04 05for await (const evt of client.logs.tail({ service: 'checkout' })) {06  console.log(evt.timestamp, evt.level, evt.message);07}

@stradiva/sdk targets Node 20+ and modern browsers. It ships ESM and CJS builds, full type definitions, and a tree-shakeable surface — typical bundles add ~12 KB gzipped.

01npm install @stradiva/sdk02 03# or04pnpm add @stradiva/sdk

01import { Stradiva } from '@stradiva/sdk';02 03const stradiva = new Stradiva({ token: process.env.STRADIVA_TOKEN! });04 05await stradiva.services.deploy('checkout', {06  region: 'eu-west',07  canary: 5,08  hold: '10m',09});

The Go SDK targets Go 1.22+. It uses standard context.Context cancellation, returns rich error types implementing errors.Is, and is fully gRPC under the hood.

01go get github.com/stradiva/stradiva-go@v3

01# Example: see github.com/stradiva/stradiva-go/examples/deploy02go run ./examples/deploy --region eu-west --canary 5

The Python SDK targets 3.10+. It exposes both sync and async clients on the same surface, supports httpx transport configuration, and pulls authentication from STRADIVA_TOKEN by default.

01pip install stradiva02 03# or with uv04uv add stradiva

01from stradiva import AsyncStradiva02 03stradiva = AsyncStradiva()04 05await stradiva.services.deploy(06    "checkout",07    region="eu-west",08    canary=5,09    hold="10m",10)

The Rust SDK is built on tonic + tokio. It exposes typed request and response structs generated from the gRPC schema, plus a thin convenience layer for the most common operations. MSRV is 1.78.

01cargo add stradiva@0.9

Examples (deploy, log tail, KV) live in the examples/ directory of the public repository. Each is a single-file main.rs you can copy verbatim.