Admin & Operator Guide

Srasta is operated through visible, verifiable workflows.

A governed AI platform cannot be a black box after install. Srasta Admin gives operators a day-2 operating surface for health, runtime truthfulness, configuration drift, access, audit, license posture, upgrades, rollback, backup, restore, self-heal, and support readiness.

Day-2 Control Plane

Admin turns platform state into operator action.

Srasta treats operations as product workflows. The Admin surface shows what is healthy, what is degraded, what changed, what can be safely fixed, and what needs an operator decision.

Srasta Admin day-2 operator workflow Srasta Admin operating loop runtime truth · lifecycle actions · audit evidence Runtimesnapshot Health +drift Verify +self-heal Rollback +restore Audit +evidence Active environmentdesired vs observed Operator actionspreview · approve · run Evidence traillogs · backups · reports

Admin Surfaces

Operators need a cockpit, not a pile of scripts.

Srasta Admin is designed to reduce SSH-dependent operations and tribal knowledge. It gives operators and security reviewers a single place to see state, understand risk, and launch controlled workflows.

Overview

Platform status, active issues, architecture map, service health, and drift banners.

Runtime

Desired service set compared with observed services, agent status, stale telemetry, and runtime drift.

Access

Users, roles, invite state, direct admin credential handoff, reset-password path, and model access posture.

Audit

Consolidated feed for auth, inference, tools, admin actions, license events, policy blocks, and exports.

Recovery

Backup sets, backup verification, restore planning, rollback preview, DR planning, and recovery readiness.

Operations

Verify deployment, self-heal status, notifications, security scans, config sync, upgrades, and support workflows.

Runtime Truthfulness

Green should mean verified, not merely hoped for.

Weak operator UX

  • Shows desired service state as if it were observed runtime state.
  • Hides stale agents and reports a believable false green state.
  • Leaks services from another environment into the active view.
  • Leaves operators to infer drift from logs.

Srasta operator UX

  • Separates desired topology from live runtime evidence.
  • Marks stale agent telemetry as offline and raises an issue.
  • Scopes runtime views to the active environment.
  • Turns drift into visible warnings and remediation plans.

Lifecycle Actions

Day-2 actions are previewable and auditable.

Srasta productizes the operations that usually become hand-walked support calls. Operators can verify, self-heal, roll back, inspect backups, create restore plans, and review disaster recovery prerequisites from a controlled surface.

01

Verify

Run deployment verification and inspect pass/fail summaries before expanding workloads.

02

Self-heal

Review bounded restart candidates, rate limits, recent restart history, and safe-restart policy.

03

Rollback

Preview rollback version, target images, and captured state before executing a rollback.

04

Upgrade

Run preflight, backup, migration hooks, image deployment, smoke tests, and rollback-on-failure flow.

05

Backup verify

Check backup sets, retention, MinIO location, and verification status for audit evidence.

06

Restore planning

Create restore or DR plans that include prerequisites, backup readiness, and post-restore verification.

Access and License

Admin is also where operating authority becomes visible.

Admin workflows make role assignment, model access, license posture, and break-glass paths visible to the operator instead of burying them in deployment files.

Roles

Platform admin, security admin, operator, auditor, developer, viewer, and tenant roles define operating scope.

Model access

Admin-published role-to-model grants control which roles can reach approved model routes.

License posture

License status determines edition behavior, trial posture, and license-gated routes.

Credential handoff

First-time admin credentials are shown once, acknowledged, and reset through a break-glass path when needed.

Recovery

Backup and restore are evidence workflows.

Srasta upgrade backups include `.env` snapshots, Postgres dumps, and Milvus collection metadata in the customer-controlled backup location. Restore planning makes the prerequisites and post-restore checks explicit.

Backed upConfiguration snapshot, Langfuse Postgres dump, and Milvus metadata.
Re-ingestedFull vector data is recovered from source documents when Milvus volume data is lost.
RetainedUpgrade flow keeps recent backup sets and prunes older ones according to policy.
VerifiedBackup verification output becomes operational and compliance evidence.

FAQ

Admin and Operator Guide FAQ

What does the Srasta Admin surface show operators?

The Admin surface shows platform status, service health, active issues, architecture maps, drift banners, verification status, audit feed, configuration, license posture, recovery workflows, notifications, and operator lifecycle actions.

How does Srasta avoid misleading operators?

Srasta separates desired state from observed runtime state, scopes health to the active environment, marks stale agents as offline, and surfaces runtime drift instead of reporting a false green state.

Can operators roll back or recover without SSH?

Srasta provides productized verify, rollback preview, rollback execution, bounded self-heal, backup set, backup verification, restore-plan, and disaster-recovery plan APIs. Some deeper recovery tasks may still require infrastructure access depending on deployment mode.

Where does Admin read audit data from?

In Kubernetes, srasta-admin mounts the shared audit log volume read-only and reads consolidated audit feeds written by Srasta API, RAG API, Tool Gateway, and related services.

Next

Install cleanly, then operate with proof.

The installer gets Srasta running. Admin keeps it truthful, recoverable, governed, and reviewable as teams begin using the runtime.

Review install