Five Rust libraries that every SOMA suite stands on — and the first piece of the platform to go public. Everything SOMA ships ends up open source; the foundation leads because everything else compiles against it.
The whole platform — every suite, every library, this website — is Apache 2.0. Repos open in maturity order, not marketing order: the foundation is already public, the flagship follows, and each suite opens as it hardens.
The shared foundation
Every SOMA suite builds on a common foundation: SOMA-DevKit, a git submodule consumed by every suite workspace. It provides five libraries — backend plumbing, a migration runner, a component library, a cryptographic audit trail, and client SDKs. One build graph must see exactly one DevKit copy, which is why the submodule model is non-negotiable: a lockfile collision surfaces immediately if two copies slip in.
soma-infra
soma-infra is the backend plumbing layer every SOMA suite consumes instead of re-implementing. It ships the primitives: the Postgres pool, the AES-256-GCM cipher, the OTLP telemetry init, the preconfigured rustls HTTP client. Every dependency is feature-gated and [optional]; a service that needs only a pool and Argon2 links zero LLM, Redis, or storage code. The central invariant is called the line: soma-infra owns the mechanism, the service owns the policy. A service passes its own HKDF info string and maps SQLSTATE to its own domain errors. The primitive lives here. The decision does not.
the pain
Service B copies the pool config, changes one param, leaks connections under load.
Hand-rolled AES-GCM in four services: four IV implementations, four items on the security audit.
OpenSSL version collision from a transitive dep breaks CI at 3am.
Copy-pasted telemetry init points at the wrong OTLP endpoint; errors vanish for weeks.
with soma-infra
Every dependency is [optional]; a Postgres-only binary links zero LLM, Redis, or storage.
connect_from_env() is the one pool configuration; every service uses the same tested path.
100% rustls across every binary; no OpenSSL in the build graph.
AES-256-GCM, Argon2id, HKDF-SHA256, HMAC-SHA256, AES-KW in one location; each service passes its own parameters.
soma-schema
soma-schema is a Postgres migration runner published at v0.4.0. It embeds in the server binary and migrates at startup, or runs as a standalone CLI. Execution order comes from migration-order.yaml; the manifest is the source of truth, not filesystem sort, so two branches landing the same day cannot produce different schema states. Every UP and DOWN script is SHA-256 checksummed; a rollback script that rotted untested registers as a startup error, not a 2am discovery. A Postgres advisory lock, keyed per service, prevents two replicas racing to apply the same migration on a rolling restart.
the pain
Two branches create migrations with the same timestamp; both run on the merge deploy.
A DOWN script untouched for six months drops a column now constrained NOT NULL.
Someone edits an applied migration; environments silently diverge on the next replica start.
Two replicas restart after a crash; both see an empty migration table and race.
SHA-256 over UP and DOWN detects rollback script drift before it runs.
Applied migrations are immutable by checksum; editing one flags the runner on next startup.
Postgres advisory lock per service; concurrent replica restarts cannot double-apply a migration.
soma-ui
soma-ui is the component library shared across every SOMA frontend: 160+ Leptos 0.8 components across 13 categories, written in Rust with no JavaScript framework. A single file, tokens.css, is the design-token source for soma-ui/web (the CSR/WASM dashboard kit) and soma-ui/site (the SSR kit that renders this website); visual consistency between the two packages is structural, not a convention teams agree to maintain. Component props are Rust types: a renamed field is a compile error, not a runtime shape mismatch. Fonts are self-hosted; the page makes no third-party requests for assets.
the pain
Rename a backend field; the JS component receives a string and silently breaks.
Tokens in two repos: six months later, amber is two different hex values.
A forgotten Google Fonts @import reaches out to a third party before first paint.
A JS major version forces a component library rewrite; typed contracts don't transfer.
with soma-ui
160+ Leptos 0.8 components across 13 categories, including SecurityGraph and SchemaDiagram ERD.
Rust-typed component props: a mismatched prop is a compile error, caught before any deploy.
tokens.css is the single design-token source for soma-ui/web and soma-ui/site.
Self-hosted fonts: no Google Fonts requests, no third-party DNS lookups at runtime.
soma-audit
soma-audit is a three-crate cryptographic audit trail. The core crate is zero-IO — pure chain math: each event's HMAC-SHA256 covers the previous link, keys derive per source via HKDF, and Ed25519 seals let an auditor verify a range without write access. The Postgres sink and the outbox client are separate crates, so a service can adopt the chain without adopting the storage. Every crate carries #![forbid(unsafe_code)].
soma-sdks
Four client crates for talking to SOMA services — or for using the primitives standalone.
soma-crypto
Argon2id · ES256 JWT · AES-256-GCM
↳the crypto primitives, usable outside SOMA
soma-iam-sdk
JWKS verifier
↳validate IAM tokens server-side, no round-trip
soma-flags-core
IO-free flag evaluation · WASM-safe
↳sub-millisecond local evaluation, zero network
soma-sdk
Server-side + local evaluation wrapper
↳the one dependency a consuming service adds
License
All of it ships under the Apache License 2.0: every suite binary, every DevKit library (soma-infra, soma-schema, soma-ui, soma-audit, the SDKs), and this website. You can use, modify, and distribute under those terms — including commercially, without royalties, without asking.
There is no open-core split. No features are reserved for a paid tier. There is no plan to relicense. The Apache 2.0 commitment covers the codebase as it exists today and as it grows.
Repositories
The SOMA repos are on GitHub under the soma-platform organization. Repos go public in the order drawn above — the platform is pre-1.0 and some suites are still in active early development. The roadmap page has the current state of every component; to follow along, watch the changelog or the GitHub organization directly.