Trial
Single supported Apple Silicon/MLX host for evaluation; confirm exact requirements and included capabilities in the support matrix.
Best for evaluation and first proof.Deployment planning reference
Start with a supported profile. Plan beyond it carefully.
The published support matrix is the source for what Srasta can install and support today. It currently lists single-node Apple Silicon/MLX and NVIDIA/vLLM profiles. The multi-host, Kubernetes, external-inference, and HA/DR shapes below are planning options, not additional supported profiles.
Recommendation Flow
Check fit before choosing an operating shape.
For a published single-node profile, verify the hardware and runtime requirements before installation. The broader intent, inventory, placement, and verification flow shown below is a design direction for future topologies; it does not expand today's public support matrix.
Profiles
Current profiles and future operating shapes.
Compact Single-Host
One GPU host runs control plane, stateful services, and bundled vLLM inference on the same machine.
Best for small teams with one strong box.Compact 1+1
CPU control plane plus dedicated GPU worker. Inference is separated from stateful and app workloads.
Planning option · not in the public support matrix.Production HA
Three or more hosts with role separation, app-tier HA, isolated inference, observability, auth, and backup agent.
Planning option · not in the public support matrix.Production HA + DR
Five or more hosts, full role separation, dedicated backup target, stronger RTO/RPO, and single-rack failure posture.
Planning option · not in the public support matrix.External Inference Variant
An external model endpoint can change the data path and operating responsibilities. Validate the exact provider, client, controls, and profile before using it.
Scoped integration option · not a published profile.Deployment Backends
Other substrates need their own validation.
The public matrix covers single-node deployments. Guided multi-host and Kubernetes designs may fit a customer's operating model, but neither is a currently published supported profile. Confirm requirements and validation evidence with Srasta before planning a production rollout.
Single-node deployment
Current published profiles cover one supported Apple Silicon/MLX or NVIDIA/vLLM host. Check the exact operating system and hardware requirements in the support matrix.
Guided multi-host Compose · planned
Design direction for coordinating control and inference hosts. It needs profile-specific proof before customer use.
Kubernetes / Helm · planned
Would need validation of storage, ingress, GPU placement, identity, upgrades, and recovery for a specific cluster.
Cloud Kubernetes · planned
Would add provider-specific GPU, networking, storage, and lifecycle proof to the Kubernetes work.
Placement
Hardware capability drives service placement.
For future multi-host designs, service placement would separate control-plane, app, stateful, observability, backup, and inference roles. This is architecture guidance, not a supported multi-host installation claim.
Control plane
Installer, plan/run state, topology, placement, access URLs, and operator lifecycle coordination.
App tier
Srasta API, Admin, RAG API, Audit Authority, service discovery, gateway, and related app workloads.
Stateful tier
Postgres, Milvus, MinIO, Valkey, audit volumes, backup metadata, and recovery state.
Inference tier
Catalog-certified vLLM or MLX runtimes, LiteLLM routing, GPU model placement, and parser-aware runtime configuration.
Observability
Langfuse, metrics, traces, audit review, and operator visibility surfaces.
Backup / DR
Backup agents, isolated backup targets, restore plans, recovery readiness, and DR validation.
Access Modes
Topology also includes how operators and users reach the runtime.
Private access
- LAN-only installs use private IP access and require no public ingress.
- Multi-host installs need reliable inter-node network reachability.
- WireGuard can provide a managed overlay when needed.
Public access
- Cloudflare Tunnel avoids public inbound firewall changes.
- Direct nginx + Let's Encrypt works with public DNS and open 80/443.
- A future Kubernetes profile would need cluster ingress and TLS controls to be validated.
Trade-Offs
The right profile depends on risk, not just scale.
A small team with regulated data may need stronger separation than a larger team running a low-risk internal assistant. Srasta keeps the trade-off visible: speed of install, local inference quality, availability, recovery posture, and operational complexity.
Evaluation speed
Trial and compact single-host minimize setup friction and help validate the first governed workflow quickly.
Inference isolation · planned
A 1+1 design would move GPU inference off the control plane, subject to separate validation.
Availability · planned
An HA design would need app and stateful-tier failure and recovery evidence before support is claimed.
Recovery · planned
An HA + DR design would need proven backup, restore, and recovery objectives for the customer's environment.
FAQ
Deployment Topologies FAQ
What topology should I start with?
Start with a profile in the published support matrix. Today that matrix lists single-node Apple Silicon/MLX and NVIDIA/vLLM profiles. Compact 1+1, HA, and HA + DR describe design options that need separate validation before they can be offered as supported deployments.
Does Srasta require a GPU?
No dedicated NVIDIA GPU is required for the published Apple Silicon/MLX profile. The NVIDIA/vLLM profile has its own hardware requirements. External inference may be suitable for a scoped integration, but it is not a published supported profile in the current matrix.
Can Srasta mix CPU and GPU architectures?
That is a multi-host design question. The public support matrix currently contains single-node profiles only; validate mixed-architecture placement with Srasta before planning a deployment around it.
When should Kubernetes be used?
Kubernetes is an architecture option discussed here, not a published supported deployment profile today. Review the current matrix and discuss any cluster requirement with Srasta before committing to it.
Next
Choose the operating shape before sizing hardware.
Once topology is clear, Srasta can guide model routing, GPU choice, access mode, verification, and day-2 operations without turning deployment into guesswork.