Making software production-ready means assembling a control plane from separate products — each with its own runtime stack, vendor relationship, and documented resource appetite.
The documented minimums are not small. Keycloak, a common IAM starting point, requires 1,250 MB base memory per pod with a minimum of 2 services.1 Infisical's self-hosted secrets management puts the baseline at roughly 16 GB across three required services.2 Assemble a conventional full stack and the total reaches 18–21 containers and $540–640/month on AWS before the first customer — derived from the documented minimums above.3
The operational surface is the bigger problem. Cross-service tokens, rate limits, account sprawl, per-tool onboarding for every new engineer. The stack grows faster than the team managing it, and most of it sits between you and production without being under your control.
I built SOMA to replace that stack.
SOMA is an open-source, all-Rust ecosystem of startup infrastructure. It ships equivalents of the above as self-hosted Rust binaries, all backed by a single Postgres database. No per-MAU fees, no per-host meters, no vendor dashboards you cannot inspect. You deploy it, you own it.
1. keycloak.org/high-availability — 1,250 MB base per pod; minimum 2 services required. 2. infisical.com/docs — ~16 GB across 3 required services (app containers + PostgreSQL 8 GB + Redis 4 GB). 3. Derived from vendor-documented minimums; AWS us-east-1 on-demand pricing. Vendor minimums are for idle/light load and grow with usage; SOMA targets are early-stage and pending production-scale validation.
What ships today
The core is soma-control: a single Axum binary that boots IAM, a secrets vault, feature flags, and a licensing engine on one port, sharing one process and one Postgres connection pool. I cover the technical structure in a separate post; the summary is that it is 341 routes across four functional areas with no Docker Compose mesh required for the control plane.
The IAM module has 216 routes across 37 route modules and 52 applied migrations. The authentication surface covers WebAuthn/Passkeys (with AES-256-GCM encrypted credential blobs), SAML 2.0 federation, OIDC with JWKS-published ES256 keys, SCIM 2.0 provisioning, TOTP, email OTP, device authorization flow, M2M tokens, personal access tokens, and multi-tenant RBAC with deny overrides. None of this is gated behind a tier.
The vault module (46 routes) uses envelope encryption: AES-256-GCM for data, AES-KW for key wrapping. It validates secret payloads against JSON Schema and supports transit encryption for application data. The flags module (42 routes) propagates changes over Redis pub/sub in real time, with multi-environment support, segments, and a change-request workflow. The licensing module (37 routes) handles plans, usage meters, coupons, addons, and webhook delivery — no percentage of revenue.
All cryptography in soma-control is pure Rust: AES-256-GCM, ECDSA P-256, Argon2id, HKDF-SHA256, HMAC-SHA256, AES-KW. OpenSSL is not linked. Every server crate in the platform carries #![forbid(unsafe_code)].
Each service has a Leptos WASM dashboard — 30 pages for IAM, 15 for vault, 10 for flags, 11 for licensing. The compiled dashboard bytes are embedded in the soma-control binary via rust-embed. There is no CDN to configure and no Node.js process to keep running.
Observability comes from soma-observe, which ingests OTLP/HTTP and OTLP/gRPC (metrics, logs, traces, errors, and continuous profiles) into Postgres. It also runs an MCP JSON-RPC server so LLM agents can call query_metrics, query_logs, query_traces, and get_service_map against production telemetry directly.
soma-analytics compiles YAML metric models to type-safe SQL and exposes an MCP server (list_cubes, describe_cube, run_query) so an AI agent can interrogate your analytics warehouse. The event ingest API is Mixpanel-compatible, so existing instrumentation ports without changes.
soma-audit-server provides a hash-chained audit log in Postgres: HMAC-SHA256 chain integrity, multi-source HMAC keys, and seal/verify endpoints.
soma-notify handles transactional notifications: campaign and journey orchestration, segment targeting, outbound webhook delivery with retry, click and open tracking, quiet hours, and unsubscribe. It has 76 routes and 19 applied migrations.
To run the complete stack:
docker run -p 80:80 soma/ecosystem:local
That single command boots all nine SOMA services with embedded Postgres, Redis, and Caddy. A seed container provisions a tenant, admin user, and flag environments on first boot. The image builds locally today — there is no published registry image yet.
What is still in progress
SOMA-Security has a functioning graph engine (petgraph, in-process per tenant with an LRU tenant cache), a CEL/SQL compliance rule engine with CIS benchmark packs that hot-reload via Postgres LISTEN/NOTIFY, and CIEM analysis tested against real Azure data — 392 identities and 16,749 activity events. The API, scanner, and frontend are in active development. I will write about Security separately when more of it is ready.
SOMA-AI is an early build-out. 35+ route files, 31 migrations, multi-agent orchestration, RAG with pgvector, HITL approvals, evaluations, MCP integration, and WebSocket event streaming — 31,167 lines of code as of today, seven commits over the last four days. The design is architecturally complete; the implementation is not. Do not run it in production.
The client SDKs (TypeScript, Python, Go) and the Terraform provider exist but lack test suites. The SOMA-Insights dashboards have pre-built dist/ but are not yet embedded in the server binaries the way soma-control's dashboards are.
Why I built this as a solo project
A solo founder running serious infrastructure today either pays SaaS fees that compound with growth, or writes and maintains the plumbing unassisted. The SaaS route hands control of your auth tokens, secret material, and production telemetry to vendors whose pricing and terms change on their schedule. The DIY route means building things that are not your product.
SOMA is the third option: one codebase, one deployment unit per service, your Postgres. The memory footprint reflects the actual work being done rather than the overhead of a separate runtime for every concern.
The code is on GitHub. soma-control is functionally complete and self-hostable now. If you want to run it, read the source, or contribute — start there.