Built for the things
that go to procurement.

The framework an enterprise team can adopt has to pass a longer list of questions than a startup's: how does multi-tenancy work, where do audit events go, can we self-host, does it run on our managed Postgres, what's the cluster story, how do traces flow. Voltro answers each of them with a primitive, not with a TODO. Built on Effect-TS — the same runtime Microsoft, Block, and Discord run in production today.

values-prod.yaml
Helm
# values-prod.yaml — Voltro's Helm chart, real cluster.
voltro:
  image:
    repository: registry.acme.com/voltro/acme
    tag:        v1.0.0
  replicas: 6

postgres:
  embedded: false                # Use the managed RDS / Cloud SQL
  url: ${POSTGRES_URL}            # Pulled from a sealed Secret

readReplicas:
  urls: ${POSTGRES_REPLICA_URLS} # Comma-separated
  regions: us-east-1,us-west-2

cache:
  backend: redis                 # ElastiCache cluster
  url: ${REDIS_URL}

observability:
  otelEndpoint: http://otel-collector.observability:4318
  serviceName: acme-app

session:
  secret: ${VOLTRO_SESSION_SECRET}  # From sealed Secret

audit:
  sink: console                  # Pipe stdout to Datadog / Splunk

# kubectl apply -f values-prod.yaml --namespace=acme-prod

Six requirements, six built-in answers.

Effect-TS production-grade internals

Voltro is built on Effect-TS — the runtime Microsoft Azure, Block, Discord, and others use in production today. Structured concurrency, typed errors, durable execution, OpenTelemetry — all features of the underlying platform we rely on, not features we re-implement.

Postgres-first, multi-dialect-tolerant

Postgres is the recommended primary store; MariaDB / MySQL / MSSQL / SQLite are first-class for enterprise procurement constraints. Read replicas, region-aware routing, RYW (read-your-writes) consistency policy — all opt-in env-var flags.

Row-level isolation via tenant mixin

The tenant() schema mixin AND-merges tenantId into every read at the runtime layer. Cross-tenant access is impossible by construction — not by a hand-rolled WHERE clause that someone forgot.

Full audit log

@voltro/plugin-audit records every mutation invocation (tag, subject, input, outcome, duration) to a configurable sink — console for dev, custom Effect for "pipe to Splunk/Datadog/SOC2 evidence". Schema-level audit() mixin adds createdAt/updatedAt/createdBy/updatedBy → actors on every row.

OpenTelemetry, end-to-end

Every primitive emits OTel spans: client.mutation, server mutation, store.transactional, action, subscription delivery, webhook. One traceId rides from React useMutation through to your downstream API call. Helm chart ships an OTEL_EXPORTER_OTLP_ENDPOINT wiring path.

Self-host today; managed cloud coming soon

The Helm chart, the Docker compose stack, the systemd baseline — all in your repo, all under your operations team. Voltro Cloud will be a managed deploy of the same primitives for teams who don't want to run the infra themselves — it's coming soon. Either way, engineering doesn't pick between two stacks.

The framework doesn't fight your platform team.

Enterprise platform teams have already standardised — on managed Postgres, on a k8s cluster, on a centralised observability stack, on a sealed-secret tool. A framework that requires its own database, its own scheduler, its own observability vendor, its own auth flow IS the integration project. Voltro is the framework that consumes what your platform team already runs.

The compliance-friendly story:

  • Auth. @voltro/plugin-auth ships HttpOnly session cookies signed via HMAC-SHA256 with a hardcoded algorithm (no JWT-alg-confusion). API keys via apiKeyStrategy with SHA-256 hash lookup. JWT bearer via JWKS via jwtBearerStrategy.
  • RLS. The tenant() schema mixin enforces row-level isolation at the runtime AND the DDL. SOC2 / ISO 27001 auditors get a clear "rows are partitioned by tenant" story without a custom Postgres RLS policy.
  • Audit log. Every mutation lands in the audit sink. Pipe to your SIEM. The schema mixin stamps WHO + WHEN on every row. "Who edited this customer record three months ago" is a one-query answer.
  • Data residency. Multi-region read replicas with DB_REPLICA_REGIONS routing. Pin reads to in-region replicas. Writes always to the primary.
  • Observability. Trace ID propagates frontend → API → downstream. Every log line carries it. Every span carries it. Audit failures and look at the WHOLE causal chain with voltro logs --trace.

The features your security review will ask about.

Open the framework. See it for yourself.

Every primitive on this page is in the framework today. Clone the starter, run `voltro dev`, and have it on screen in two minutes.