Inside the Salus architecture: stateless app, Snowflake data plane, zero-trust | Salus Agentic
Architecture

Inside the Salus architecture: stateless app, Snowflake data plane, zero-trust

How Salus separates a stateless application layer from the Snowflake data plane and the AI layer, so protected health information stays governed and your security team can review the design end to end.

6 min read All articles

Three planes, each with one job

Salus is built as three separate planes connected over private networking. The application layer, the API and web tier, is stateless: it holds no protected health information on disk and keeps nothing in a local database. It retrieves data, streams it to the user, and discards it when the session ends. The data plane is Snowflake, where the governed record of accessioning, results, and surveillance lives. The AI layer runs in a managed cloud AI service, kept separate from both so a model never becomes a place data quietly accumulates.

Separating these planes keeps the audit surface small. Because the application servers store nothing, a compromise of the app tier exposes no patient data, and the compliance question narrows to the data plane, where governance actually belongs.

Private by default, no public data path

Traffic between the application layer, Snowflake, and the AI service travels over private connectivity, cloud PrivateLink and VPC endpoints, not the public internet. Protected health information never crosses a public network boundary, and access follows a zero-trust posture: verify every request, grant least privilege, and assume the network is hostile rather than trusting anything inside a perimeter.

Everything is encrypted end to end, in transit with modern TLS and at rest with strong, customer-managed keys, so encryption is a property of the whole path rather than a single hop.

Access control at the grain that matters

Data isolation is role-based at the database, schema, and table level rather than through per-row filtering. Each customer runs in its own isolated database, so one organization cannot query another's data, and inside that database sensitive areas such as billing live in their own schema that only the right roles can reach. A technologist's role sees the operational data it needs and nothing more, without a lab having to author and maintain fragile row-level rules.

That coarse-grained, grant-based model is deliberate: it is easier to reason about, easier to audit, and harder to get subtly wrong than row-level security, while still enforcing separation of duties where it counts.

Built on Snowflake, with no lock-in

The data plane runs on Snowflake for enterprise scale, governed sharing, and analytics that run directly on the same data operations use. But building on a modern platform does not mean being trapped on it. Salus ships a zero lock-in export engine that returns your complete data, including audit logs, in open formats, JSON, HL7 FHIR, OMOP, Parquet, and CSV, on demand and without exit fees.

Your laboratory retains full ownership and direct control of all raw and processed data, in your own tenant, under your own governance. Nothing about the license restricts export or migration.

See it in your laboratory's context.

Explore the live demo, no login and no request form.