Supported deployments
Hardware and runtime profiles Srasta can actually install and support.
Srasta only lists a deployment profile here once it has real evidence behind it. Each profile packages the hardware, runtime adapter, inference engine, model defaults, topology, and proof gates we can support. Built means end-to-end validation passed; Validating means real infrastructure validation is still in progress. Anything not listed here is not yet a supported public deployment.
Support matrix
Current supported deployment profiles.
| Deployment profile | Hardware | Runtime | Status | Evidence |
|---|---|---|---|---|
| Apple Silicon / MLX single node | apple-m | mlx | Built | L4-hardware-validated on real Apple Silicon — the full install, prove, and handover spine passed end-to-end. |
| NVIDIA Blackwell / vLLM single node | blackwell | vllm | Built | GB10 proof model validated; broader single-node validation is in progress before this profile moves to Built. |
Sourced from Srasta's catalog authority — the same source the installer uses to decide which deployment profiles are safe to install. See inference & model routing for how a supported deployment becomes a governed model route.
FAQ
Supported deployment FAQ
What is a certified deployment profile?
It is Srasta's customer-facing support unit: hardware, runtime adapter, inference engine, model defaults, topology, and proof evidence that have been tested together. Internally, this maps to a Srasta Cell in the catalog authority.
What does "Built" mean here?
Built means the deployment profile has passed real validation end to end: install, activation, runtime binding, and proof/handover ran against the actual runtime, not a simulated or mocked environment.
What does "Validating" mean?
Validating profiles run on real infrastructure and have passed initial proof steps, but broader hardware, model, and workload validation is still in progress before we call them Built.
Why are there only two rows today?
This matrix only lists deployment profiles with real certification evidence behind them today. Multi-host, Kubernetes, and cloud-provider profiles stay internal until they have their own validation evidence.
Where does this data come from?
Srasta's catalog authority, the same source the installer itself uses to decide which hardware, runtime adapter, inference engine, and model bindings are safe to install.
Next
See where the rest of the platform is headed.
Additional hardware and topology profiles become public only after they have committed validation evidence behind them.