Host and runtime
Apple Silicon (macOS) or Linux host, Docker Engine 24+, Docker Compose v2, 16 GB RAM minimum, 50 GB free disk minimum.
Installation Process
One command. The agent drives the rest.
A single self-contained binary checks the host, installs and converges the platform, and proves it's healthy before handing you the Admin console URL. No Docker image to pull first, no browser wizard to keep open.
Flow
One agent, one command, the same path every time.
There's no separate browser UI to open and no state to lose if a terminal disconnects. The agent binary itself downloads, checks the host, converges the platform, proves it's healthy, and hands off — the same five steps whether this is a single laptop or the first node of a cluster.
Before You Start
Gather the few things the agent cannot guess.
The agent's own precheck detects hardware, Docker readiness, ports, stale Srasta state, GPU availability, and service health before it touches anything. 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.
Install Stages
Every install runs the same five stages, no screens to babysit.
Fetch the agent
One signed, checksum-verified binary carries the compose project, catalog, and policy defaults — nothing else to pull first.
Check readiness
Docker, disk, stale containers, port conflicts, GPU/VRAM, OS, and architecture — printed before anything touches the host, so a failure costs seconds, not minutes.
Converge the platform
Detects the right model for the hardware, materializes the compose project, brings the stack up, and reconciles until it matches the desired state.
Prove it's healthy
Service health, model routing, and a real inference smoke test — the install isn't declared done just because containers started.
Hand off, then stay resident
Sign-in URL and Admin console printed at the end, not buried mid-log. The same binary keeps running afterward as a host service, watching for drift.
Advanced
Download the agent binary directly.
The one-line command above downloads and verifies the same binary — this is for scripted installs, air-gapped-adjacent staging, or anyone who wants the signed artifact in hand before running it.
Each link resolves to the current release's signed, checksum-published binary and redirects straight to it — nothing is proxied through this site. Windows is not a supported host yet.
Topologies
Use the same agent from evaluation to production.
Single-node
Best for trials, prototypes, demos, and one-team evaluation. Everything runs on one Apple Silicon or Linux host.
Fastest pathMulti-host
Control plane on one host, additional nodes join by pairing code — zero SSH, no inbound rule ever opened. Each node pulls its own slice and converges itself.
Common production shapeKubernetes
Deploys via the certified Helm chart into an existing cluster — self-hosted or a managed EKS/GKE/AKS target you've already authenticated to.
Platform-team friendlyCloud & VMware
Srasta provisions the compute instance itself — AWS, GCP, Azure, or an on-prem VMware/vSphere cluster — via its own scoped-credential Terraform, then joins it automatically.
Rolling out with pilot customersAfter 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?
A single self-contained agent binary (no Docker required, no browser UI) checks host readiness, installs and converges the platform, and verifies health before handing you the Admin console URL. One command: curl -fsSL https://get.srasta.ai | sh.
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?
The installer can run platform wiring checks without a GPU, but current public private-inference profiles require Apple Silicon MLX or a certified NVIDIA/vLLM GPU path. CPU-only inference is not a current Community capability.
Can Srasta provision the machine for me, not just install onto one I already have?
Srasta is built to create the compute instance itself on AWS, GCP, Azure, Vast.ai, or an on-prem VMware/vSphere cluster, using credentials scoped to a machine identity Srasta never shares with anything else, then join it automatically with no inbound network rule ever opened. It's rolling out with pilot customers first; talk to us if that's the path you need.
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.