Varolio DocsBYO Data Store
Host the data plane yourself — Varolio connects to your Elasticsearch, LLM, and object storage
Bring Your Own Data Store (BYO)
BYO Data Store lets you keep the platform's data plane on infrastructure you control. You host an Elasticsearch/OpenSearch deployment, an LLM endpoint, S3-compatible object storage — or any combination — and provide Varolio with connection credentials. Varolio's application connects to your deployment instead of its managed stores, so conversation content, search indexes, and attachments live where you decide.
This model composes with either Cloud SaaS or Dedicated Cloud as the base: the application keeps running where it runs today, and only the data plane moves to you.
Amazon EKS cluster
What you can host
| Component | What it stores / does | Requirements |
|---|---|---|
| Elasticsearch / OpenSearch | Threads, messages, cases, knowledge index, embeddings | An Elasticsearch- or OpenSearch-compatible deployment reachable over TLS, with credentials scoped to Varolio's indices |
| LLM endpoint | All model inference (extraction, drafting, case evaluation) | An endpoint for your own model deployment or provider account, reachable over TLS |
| S3-compatible object storage | Email bodies, attachments, large objects | An S3-compatible bucket with scoped access keys |
You can adopt any subset — for example, hosting only the search index while keeping Varolio's default LLM providers, or only routing inference to your own model deployment.
How it works
Varolio's application code is identical in every deployment model. Internally, all retrieval, inference, and object-storage operations go through a single abstraction (DialogueApi) that exposes the data plane behind three interfaces:
getRetrieverApi()— every read/write of threads, cases, and knowledge goes through the retriever interface, backed by ElasticsearchgetLlmApi()— every model call goes through the LLM interface, which resolves the configured model endpoint- the object-storage interface — attachment and large-object uploads/downloads
In a BYO configuration, these interfaces are wired to your connection targets for your workspace. No application logic changes; only the connection targets do.
Credential handling
- You provide connection credentials (Elasticsearch API key, LLM endpoint key, object-storage access keys) during onboarding.
- Credentials are stored in Supabase Vault, which applies authenticated encryption (AEAD, libsodium) to every secret before it is written to disk; encryption keys are managed by Supabase's key-management infrastructure and are never stored in the database alongside the data. Secrets are resolved at runtime for your workspace only, under the same per-tenant credential isolation used for all integrations.
- Rotating a credential on your side and updating it with Varolio is sufficient to cut over; revoking it immediately severs Varolio's access to the data store.
What lives where
| Data | Location in BYO |
|---|---|
| Threads, messages, cases, knowledge index, embeddings | Your Elasticsearch/OpenSearch |
| Email bodies, attachments, large objects | Your S3-compatible storage (when hosted) |
| Inference inputs/outputs | Your LLM endpoint (when hosted) |
| Application metadata: accounts, workspaces, configuration, workflow state | Varolio's Supabase (PostgreSQL) in the base deployment |
Network requirements
Your hosted components must be reachable over TLS (HTTPS 443) from Varolio's environment. Supported connectivity paths: public endpoint with IP allow-listing of Varolio's egress addresses, or private connectivity (VPC peering / private link) scoped per engagement — the latter is most natural when combined with Dedicated Cloud.
When to choose a different model
- If application metadata (PostgreSQL) must also live in your account — not just the content data plane — choose Cloud-Prem.
- If your requirement is regional residency rather than self-hosting, Dedicated Cloud is operationally simpler.