Host and runtime
Linux host, Docker Engine 24+, Docker Compose v2, 16 GB RAM minimum, 50 GB free disk minimum.
Installation Process
Install the governed AI runtime with an operator-first wizard.
Srasta's installer turns infrastructure setup into a guided workflow: validate the machine, detect hardware, choose the right topology, configure inference and access, deploy the stack, and verify that the runtime is ready before operators start using it.
Quick start
curl -fsSL https://get.srasta.ai | sh Starts the installer UI on port 9000. The wizard performs readiness checks before deployment begins.
Flow
One install path, multiple deployment shapes.
The installer is a deterministic state machine, not a loose chat flow. Each screen captures one operator decision, records the result, and carries that context forward into validation, placement, deployment, and day-2 advisories.
Before You Start
Gather the few things the wizard cannot guess.
The installer can detect hardware, Docker readiness, ports, stale Srasta state, GPU availability, and service health. It still needs the operator to bring the infrastructure access and business intent.
License posture
Trial installs can validate after deployment. Production and HA intents should validate the license up front.
Inference plan
CPU-only for evaluation, local GPU for private inference, or external inference where policy allows it.
Access model
LAN-only, public nginx/TLS, or Cloudflare Tunnel depending on who needs to reach the installation.
Wizard Stages
Each screen answers one operational question.
Intent
Trial, dev, staging, production, or production HA + DR. This determines warnings, license gates, and topology fit.
Deployment mode
Single machine, guided multi-host, or existing Kubernetes cluster. Invalid combinations are warned, not hidden.
Readiness and hardware
Docker, disk, stale containers, port conflicts, GPU/VRAM, OS, architecture, SSH, and Kubernetes capability checks.
Runtime configuration
Model selection, local or external inference, secrets provider, add-ons, identity, domain, and ingress choices.
Deploy and verify
Preflight, image pulls, service placement, model preparation, health checks, smoke verification, and Admin URL handoff.
Topologies
Use the same installer from evaluation to production.
Single-node
Best for trials, prototypes, demos, and one-team evaluation. Everything runs on one Linux host.
Fastest pathGuided multi-host
Control plane on one host, inference and supporting services placed across worker nodes. SSH bootstrap is handled by the installer.
Common production shapeKubernetes
Uses kubectl and Helm against an existing cluster. The installer validates namespace, storage class, RBAC, nodes, GPU capacity, and ingress readiness.
Platform-team friendlyAfter Install
Success means the runtime is usable, observable, and recoverable.
The installer should not declare success just because containers started. Srasta treats deployment as complete only when operators have health visibility, access to Admin, a validated gateway, and a path to troubleshoot or reset safely.
Expected handoff
- Admin panel URL and API endpoint.
- Service health and smoke test status.
- License activation path.
- Model routing and inference availability.
- Drift, backup, recovery, and notification surfaces.
- Next steps for document ingestion, auth, alerts, and add-ons.
FAQ
Installer questions buyers usually ask first.
What does the Srasta installer do?
The Srasta installer runs a browser-based wizard that checks host readiness, detects hardware, recommends deployment topology, configures inference and access, deploys services, and verifies health.
Can Srasta install on one machine?
Yes. A single-node install is the fastest path for trials, prototypes, and team evaluations. Production deployments usually use multi-host or Kubernetes for better separation and availability.
Does the installer require Kubernetes?
No. Srasta supports Docker Compose for single-node and guided multi-host deployments, plus Kubernetes/Helm for customers that already operate clusters.
Can the installer run without a GPU?
Yes. CPU-only inference is supported for low-concurrency evaluation. GPU-backed local inference is recommended for serious enterprise workloads.
Start Small, Install Cleanly
Use a trial install to validate your first governed workflow.
Begin with one clear use case, confirm topology and access, then expand once the control plane, inference path, memory boundary, and operator workflow are verified.