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. First confirm that your hardware matches a published supported profile; the public matrix currently covers single-node deployments.
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
Current single-node support and future deployment designs.
Single-node
Published Apple Silicon/MLX and NVIDIA/vLLM profiles use one host. Check the current matrix for hardware and runtime requirements.
Published support matrixMulti-host
Separating control and inference hosts is a design option that needs its own deployment proof.
Planning option · not publicly supportedKubernetes
A cluster deployment would need validated storage, ingress, GPU placement, identity, lifecycle, and recovery for the target environment.
Planning option · not publicly supportedCloud & VMware
Provider-specific provisioning would need a scoped pilot and separate validation before becoming a supported install path.
Planning option · discuss requirementsAfter 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. The current public support matrix lists single-node Apple Silicon/MLX and NVIDIA/vLLM profiles. Confirm the exact host requirements there before installing. Multi-host and Kubernetes are not published supported profiles today.
Does the installer require Kubernetes?
No. The currently published profiles are single-node. Kubernetes and guided multi-host deployments need separate validation and are not self-service supported profiles today.
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?
Not as a published self-service profile today. Cloud and VMware provisioning require provider-specific validation; contact Srasta to discuss a scoped pilot if you need that path.
Start Small, Install Cleanly
Use a trial install to validate your first governed workflow.
Begin with one clear use case, confirm a supported profile and data path, then expand only after the tested workflow and operator responsibilities are understood.