VoltroFramework

Gebaut für die Dinge,
die durch den Einkauf müssen.

Ein Framework, das ein Enterprise-Team einführen kann, muss eine längere Fragenliste bestehen als ein Startup: Wie funktioniert Multi-Tenancy, wohin gehen Audit-Events, können wir selbst hosten, läuft es auf unserem managed Postgres, wie sieht die Cluster-Story aus, wie fließen Traces. Voltro beantwortet jede davon mit einem Primitiv, nicht mit einem TODO. Gebaut auf Effect-TS — derselben Runtime, die Microsoft, Block und Discord heute in Produktion betreiben.

Quickstart lesen
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

Sechs Anforderungen, sechs eingebaute Antworten.

Effect-TS-Internals in Produktionsqualität

Voltro ist auf Effect-TS gebaut — der Runtime, die Microsoft Azure, Block, Discord und andere heute in Produktion einsetzen. Strukturierte Nebenläufigkeit, typisierte Fehler, durable Execution, OpenTelemetry — alles Features der zugrunde liegenden Plattform, auf die wir bauen, nicht Features, die wir nachbauen.

Postgres-first, Multi-Dialekt-tolerant

Postgres ist der empfohlene primäre Store; MariaDB / MySQL / MSSQL / SQLite sind erstklassig für Beschaffungsvorgaben im Enterprise. Read-Replicas, regionsbewusstes Routing, RYW-Konsistenzpolicy (read-your-writes) — alles per Env-Var zuschaltbar.

Row-Level-Isolation über den tenant-Mixin

Der tenant()-Schema-Mixin merged tenantId per AND in jeden Read auf der Runtime-Ebene. Cross-Tenant-Zugriff ist konstruktionsbedingt unmöglich — nicht durch eine handgeschriebene WHERE-Klausel, die jemand vergisst.

Vollständiges Audit-Log

@voltro/plugin-audit protokolliert jeden Mutation-Aufruf (Tag, Subject, Input, Ergebnis, Dauer) in einen konfigurierbaren Sink — Konsole im Dev, eigener Effect für "nach Splunk/Datadog/SOC2-Nachweis leiten". Der Schema-Level-audit()-Mixin ergänzt createdAt/updatedAt/createdBy/updatedBy → actors auf jeder Zeile.

OpenTelemetry, Ende-zu-Ende

Jedes Primitiv emittiert OTel-Spans: client.mutation, Server-Mutation, store.transactional, Action, Subscription-Delivery, Webhook. Eine traceId reicht von React useMutation bis zu deinem nachgelagerten API-Aufruf. Der Helm-Chart liefert einen OTEL_EXPORTER_OTLP_ENDPOINT-Verdrahtungspfad.

Heute self-hosten; Managed Cloud kommt bald

Der Helm-Chart, der Docker-Compose-Stack, die systemd-Baseline — alles in deinem Repo, alles unter deinem Ops-Team. Voltro Cloud wird ein managed Deploy derselben Primitive für Teams, die die Infra nicht selbst betreiben wollen — es kommt bald. So oder so muss Engineering nicht zwischen zwei Stacks wählen.

Das Framework kämpft nicht gegen dein Plattform-Team.

Enterprise-Plattform-Teams haben bereits standardisiert — auf managed Postgres, auf einen k8s-Cluster, auf einen zentralen Observability-Stack, auf ein Sealed-Secret-Tool. Ein Framework, das seine eigene Datenbank, seinen eigenen Scheduler, seinen eigenen Observability-Anbieter, seinen eigenen Auth-Flow verlangt, IST das Integrationsprojekt. Voltro ist das Framework, das nutzt, was dein Plattform-Team ohnehin schon betreibt.

Die Compliance-freundliche Story:

  • • Auth. @voltro/plugin-auth liefert HttpOnly-Session-Cookies, signiert per HMAC-SHA256 mit fest verdrahtetem Algorithmus (keine JWT-alg-Confusion). API-Keys über apiKeyStrategy mit SHA-256-Hash-Lookup. JWT-Bearer über JWKS via jwtBearerStrategy.
  • • RLS. Der tenant()-Schema-Mixin erzwingt Row-Level-Isolation auf der Runtime UND im DDL. SOC2-/ISO-27001-Auditoren bekommen eine klare "Zeilen sind pro Tenant partitioniert"-Story ohne eigene Postgres-RLS-Policy.
  • • Audit-Log. Jede Mutation landet im Audit-Sink. Leite ihn an dein SIEM. Der Schema-Mixin stempelt WER + WANN auf jede Zeile. "Wer hat diesen Kundendatensatz vor drei Monaten geändert" ist eine Ein-Query-Antwort.
  • • Data Residency. Multi-Region-Read-Replicas mit DB_REPLICA_REGIONS-Routing. Pinne Reads auf regionsinterne Replicas. Writes immer auf die Primary.
  • • Observability. Die Trace-ID propagiert frontend → API → nachgelagert. Jede Log-Zeile trägt sie. Jeder Span trägt sie. Untersuche Fehlschläge und betrachte die GESAMTE Kausalkette mit voltro logs --trace.

Die Features, nach denen dein Security-Review fragen wird.

Multi-Tenancy

Schema-Mixin, Runtime-erzwungen. Die saubere Antwort auf den "Erzählen Sie uns von der Cross-Tenant-Isolation"-Abschnitt des Security-Fragebogens.

Durable Workflows

Kein Temporal, kein Inngest — rein interne Effect-TS-Infrastruktur. Die Beschaffung muss keinen dritten Anbieter onboarden.

Typsicherheit

Branded TypeIDs, typisierte Fehler, kein Codegen-Schritt. Garantien auf Typ-Ebene bedeuten weniger reine Laufzeit-Bugs.

Öffne das Framework. Schau es dir selbst an.

Jede Primitive auf dieser Seite ist heute im Framework. Klone den Starter, lass `voltro dev` laufen, in zwei Minuten ist es auf dem Bildschirm.

Quickstart lesen