Runtime Services
Siesta AI uses independently deployable services so that public ingress, platform APIs, retrieval workloads, external tools, and background processing can be secured and scaled separately.
Workload Groups
| Workload | Purpose | Operational focus |
|---|---|---|
| Frontend | User and embedded interfaces | TLS, origin policy, health, user-facing availability |
| Platform API | Authentication, entities, agents, workflows, business logic | Authorization, database health, latency, audit correlation |
| Retrieval API | Query-time retrieval and search operations | Private access, search latency, model and index dependencies |
| Retrieval worker | Ingestion, extraction, chunking, embeddings, indexing | Queue depth, retries, poison items, throughput, quota |
| Tool service | Governed calls to external systems | Credential scope, approval, provider failures, egress |
| Function and scheduled workloads | Event-driven and background processing | Identity, idempotency, retries, timeout, dead-letter handling |
Production Requirements
Every workload should have:
- a dedicated runtime identity where practical,
- explicit inbound and outbound network paths,
- minimum and maximum scale appropriate to the workload,
- startup and health probes,
- bounded retries and timeouts,
- structured logs, metrics, traces, and correlation IDs,
- documented dependencies and failure behavior,
- a rollback or recovery path.
Avoid embedding secrets directly into runtime environment values. Reference a secret store or fetch secrets through the workload identity. Separate static configuration from secret-classified values as described in Secrets and Configuration.