Where Samskara runs, and where your data doesn't.
SAMSKARA is a control plane, not a data store. Here's exactly what that means at the infrastructure level.
Where does SAMSKARA run?
Entirely on infrastructure you control — a VM, on-prem hardware, or your own cloud VPC. Docker Compose brings up the FastAPI backend, a background worker (scheduler, cleanup, report delivery), the AI service, Postgres, Redis, and the frontend as containers you own. Nothing runs in a SAMSKARA-operated cloud.
Where does my data live?
Notebook workspace files live on disk/volumes under your control, scoped per organization and project. ArrowLake tables land in your own S3-compatible object storage as real Iceberg data. Data you query through a database profile (Postgres, MySQL) stays in that database — SAMSKARA never copies it into a separate managed store.
Does data ever leave my network?
Only for AI Sparkle requests, and only if you point AI_BASE_URL at an external provider. Point it at a local Ollama instance instead and every prompt and completion stays inside your own network.
Where are secrets stored?
Org secrets are encrypted at rest with Fernet (AES-128) using a key you generate and control (SECRET_ENCRYPTION_KEY), stored in your own Postgres. Values are decrypted and injected into the runtime environment only at execution time and are never returned by the API.
How does AI connectivity work?
AI Sparkle assembles context — live session variables, ArrowLake schemas, the sm.* API surface, and relevant examples from ChromaDB — server-side, then forwards a single request to whichever OpenAI-compatible endpoint you've configured. The model itself never has standing access to your database or storage credentials.
How are notebook sessions isolated?
Each session runs in its own environment — a package-isolated virtualenv for the local Python runtime, or a dedicated Docker container per session when you enable the Docker runtime profile — so installed packages and variables never leak across notebooks or users.