Varolio DocsCloud-Prem
Full Varolio deployment inside the customer's own cloud account — AWS, GCP, or Azure
Cloud-Prem
Cloud-Prem is Varolio's deployment model for organizations that require their data and compute to remain in their own cloud account. The customer owns the account; Varolio provisions and operates the platform inside it through a revocable operator identity the customer creates and controls.
The software running in the customer's account is functionally identical to Cloud SaaS — same services, same data layer, same AI surface. The difference is that the entire stack is single-tenant, dedicated, and bounded by the customer's cloud account.
Unlike vendor-locked offerings, Cloud-Prem is cloud-agnostic: the customer chooses the vendor, and Varolio deploys on AWS, GCP, or Azure. Select your provider to see the architecture, terminology, and provisioning steps for that cloud:
AWS WAF + Application Load Balancer
Amazon EKS clustercontainer images deployed via Helm · GitOps
How it works
A dedicated AWS account holds the Varolio environment: a VPC, an Amazon EKS cluster, Amazon RDS for PostgreSQL, search (Amazon OpenSearch Service, or self-managed Elasticsearch via the ECK operator in the cluster), ElastiCache for Redis, Amazon S3 object storage, and AWS Secrets Manager. The customer creates a cross-account IAM role that Varolio uses to provision (infrastructure as code) and operate (Helm-driven deploys) the environment.
The customer's data never leaves their account, except for HTTPS calls to AI model providers. On AWS, Amazon Bedrock can be invoked directly in the customer's account, so those model calls don't have to leave it; calls to other providers (e.g. Vertex AI for Gemini) cross the customer's egress.
A dedicated GCP project holds the Varolio environment: a VPC, a GKE cluster, Cloud SQL for PostgreSQL, search (self-managed Elasticsearch via the ECK operator in the cluster, or Elastic Cloud from the GCP Marketplace — see the note below), Memorystore for Redis, Cloud Storage buckets, and Secret Manager. The customer creates a service account grant via Workload Identity Federation that Varolio uses to provision (infrastructure as code) and operate (Helm-driven deploys) the environment.
The customer's data never leaves their project, except for HTTPS calls to AI model providers. On GCP, Vertex AI (Gemini) can be invoked directly in the customer's project, so primary model calls don't have to leave it; calls to other providers (e.g. Amazon Bedrock) cross the customer's egress.
Search deployment note. Elastic Cloud purchased through the GCP Marketplace runs in Elastic's own in-region GCP organization, not inside your project. If search data must stay inside the project boundary, choose the self-managed ECK option — Varolio operates it inside the GKE cluster.
A dedicated Azure subscription holds the Varolio environment: a VNet, an AKS cluster, Azure Database for PostgreSQL – Flexible Server, search (self-managed Elasticsearch via the ECK operator in the cluster, or Elastic Cloud from the Azure Marketplace — see the note below), Azure Managed Redis, Azure Blob Storage, and Azure Key Vault. The customer creates an Entra ID app registration with federated credentials that Varolio uses to provision (infrastructure as code) and operate (Helm-driven deploys) the environment.
The customer's data never leaves their subscription, except for HTTPS calls to AI model providers (Vertex AI, Amazon Bedrock), which cross the customer's egress.
Search deployment note. Elastic Cloud purchased through the Azure Marketplace runs in Elastic's own in-region Azure environment, not inside your subscription. If search data must stay inside the subscription boundary, choose the self-managed ECK option — Varolio operates it inside the AKS cluster.
What runs in your cluster
Varolio's services ship as signed container images and are deployed into the Kubernetes cluster via Helm and GitOps — each as a standard Kubernetes workload in its own namespace:
| Workload | Role |
|---|---|
| Engine | API service — terminates all traffic, the only service with control-plane (PostgreSQL) access |
| Agent | AI orchestration and retrieval — the only service that talks to Elasticsearch, reached via the Engine |
| Worker | Executes asynchronous Temporal workflows |
| MCP Server | Model Context Protocol endpoint |
| Temporal | Self-hosted workflow orchestration (replaces Temporal Cloud used in Varolio-hosted models) |
What's the same as Cloud SaaS
- Every service runs unchanged: engine (API), agent (AI orchestration), worker (Temporal workflows), archiver, MCP server, web applications.
- The data layer is the same shape: PostgreSQL, Elasticsearch, object storage, Redis, Temporal (self-hosted in the cluster).
- The release pipeline is the same: CI-gated, peer-reviewed builds; the customer's cluster pulls signed container images from Varolio's registry.
What's different
| Cloud SaaS | Cloud-Prem | |
|---|---|---|
| Tenancy | Multi-tenant | Single-tenant, dedicated |
| Cloud account | Varolio's | Customer's |
| Cloud vendor | AWS + GCP | Customer's choice: AWS, GCP, or Azure |
| Region | EU (Frankfurt) | Customer's choice |
| Operator access | Varolio internal SSO | Varolio SSO + customer-created revocable identity |
| Egress to model providers | Via Varolio's NAT | Via customer's NAT |
| Cloud bill | Included in subscription | Direct to customer |
| Upgrade cadence | Rolling, gated by CI + review | Scheduled with customer |
Operator access model
Varolio never receives standing user accounts in the customer's cloud. Access is granted through one identity, created by the customer and revocable at any time:
The customer creates a cross-account IAM role in the deployment account with a trust policy toward Varolio's deploy account, conditioned on an sts:ExternalId unique to the engagement. Varolio's operator tooling assumes the role with short-lived STS credentials — no long-lived access keys, no IAM users. Every operator action is recorded in the customer's own AWS CloudTrail under the assumed-role session identity.
The customer creates a service account in the deployment project and grants Varolio's deploy identity access to it via Workload Identity Federation — a keyless trust between the customer's workload identity pool and Varolio's operator identity. No service-account keys are ever exported. Every operator action is recorded in the customer's own Cloud Audit Logs under the impersonated service-account identity.
The customer creates an Entra ID app registration with federated credentials trusting Varolio's operator identity, and assigns it scoped roles on the deployment subscription. Federated credentials are keyless — no client secrets or certificates are exchanged. Every operator action is recorded in the customer's own Azure Activity Log under the service principal's identity.
On top of the cloud identity, day-to-day operation of the cluster uses scoped Kubernetes RBAC — Varolio's operational tooling is limited to the namespaces and resources of the Varolio deployment.
| What Varolio can do | Provision and update the platform's infrastructure (tagged/prefixed resources only), deploy and roll back application releases, read platform logs and metrics, manage platform secrets |
| What Varolio cannot do | Access resources outside the Varolio deployment's scope, create cloud users, or reach the account from anywhere but its SSO-gated operator tooling — all operator access is outbound-only with short-lived credentials |
| How you revoke it | Disable the trust policy / federation / role assignment — a one-line change on your side. The deployment continues to run; Varolio loses the ability to operate it until the grant is restored |
Account requirements
- A dedicated AWS account for the deployment, separate from the customer's primary production workloads.
- A region where Amazon EKS, Amazon RDS for PostgreSQL, and Amazon S3 are available.
- Sufficient service quotas for the EKS cluster, RDS instances, and NAT Gateway egress before provisioning.
- AWS Organizations SCPs are supported; Varolio publishes the IAM actions the deployment requires so they can be allow-listed.
- A dedicated GCP project for the deployment, separate from the customer's primary production workloads.
- A region where GKE, Cloud SQL for PostgreSQL, and Cloud Storage are available.
- Sufficient quotas for the GKE cluster, Cloud SQL instances, and Cloud NAT egress before provisioning.
- Organization policies are supported; Varolio publishes the IAM permissions and APIs the deployment requires so they can be allow-listed and enabled.
- A dedicated Azure subscription for the deployment, separate from the customer's primary production workloads.
- A region where AKS, Azure Database for PostgreSQL – Flexible Server, and Azure Blob Storage are available.
- Sufficient quotas for the AKS cluster, database instances, and NAT Gateway egress before provisioning.
- Azure Policy is supported; Varolio publishes the role definitions and resource providers the deployment requires so they can be allow-listed and registered.
Network and connectivity
Ingress. Public access is fronted by AWS WAF on an Application Load Balancer inside the customer's account, with TLS 1.2+ enforced at the edge. The public hostname is scoped per engagement — either a {customer}.varolio.io subdomain managed by Varolio or a customer-owned domain.
Egress. All outbound traffic exits via the customer's NAT Gateway. The AI model provider endpoints and the integration endpoints the customer activates (Microsoft Graph, Gmail, WhatsApp, Recall.ai) must be reachable from the customer's egress.
Ingress. Public access is fronted by Cloud Armor on a Global External Application Load Balancer inside the customer's project, with TLS 1.2+ enforced at the edge. The public hostname is scoped per engagement — either a {customer}.varolio.io subdomain managed by Varolio or a customer-owned domain.
Egress. All outbound traffic exits via the customer's Cloud NAT. The AI model provider endpoints and the integration endpoints the customer activates (Microsoft Graph, Gmail, WhatsApp, Recall.ai) must be reachable from the customer's egress.
Ingress. Public access is fronted by Azure Application Gateway with WAF v2 inside the customer's subscription, with TLS 1.2+ enforced at the edge. The public hostname is scoped per engagement — either a {customer}.varolio.io subdomain managed by Varolio or a customer-owned domain.
Egress. All outbound traffic exits via the customer's NAT Gateway. The AI model provider endpoints and the integration endpoints the customer activates (Microsoft Graph, Gmail, WhatsApp, Recall.ai) must be reachable from the customer's egress.
Customer data sources. The deployment reaches the customer's mail tenant and other SaaS integrations over their public APIs with OAuth credentials the customer authorizes — the same as every other deployment model.
Encryption
| Layer | Default | Customer-managed key option |
|---|---|---|
| Databases and search at rest | AES-256, AWS-managed | AWS KMS customer-managed key, configurable per engagement |
| Object storage (S3) | AES-256, AWS-managed (SSE-S3) | AWS KMS customer-managed key (SSE-KMS) |
| Application secrets | AWS Secrets Manager | Customer KMS-key-wrapped secrets |
| In transit | TLS 1.2+ at every hop | n/a |
| Layer | Default | Customer-managed key option |
|---|---|---|
| Databases and search at rest | AES-256, Google-managed | CMEK (Cloud KMS customer-managed key), configurable per engagement |
| Object storage (Cloud Storage) | AES-256, Google-managed | CMEK on the bucket |
| Application secrets | Secret Manager | CMEK-protected secrets |
| In transit | TLS 1.2+ at every hop | n/a |
| Layer | Default | Customer-managed key option |
|---|---|---|
| Databases and search at rest | AES-256, Microsoft-managed | Key Vault customer-managed key, configurable per engagement |
| Object storage (Blob Storage) | AES-256, Microsoft-managed | Key Vault customer-managed key on the storage account |
| Application secrets | Azure Key Vault | Customer HSM-backed Key Vault keys |
| In transit | TLS 1.2+ at every hop | n/a |
Blob Storage support is delivered through Varolio's object-storage adapter layer — the same abstraction that backs S3 and Cloud Storage in the other deployment targets.
Because the account is customer-owned, customer-managed encryption keys (BYOK) are supported — the keys remain under the customer's control at all times.
Provisioning lifecycle
- Kickoff. Customer provides the AWS account ID and chosen region. Varolio provides the infrastructure-as-code module and the IAM role definition (permission set + trust policy) for review.
- Identity grant. Customer creates the cross-account IAM role with the published, least-privilege permission set and the engagement-specific
sts:ExternalId. - Provisioning. Varolio applies the infrastructure-as-code: VPC, EKS cluster, RDS, search, ElastiCache, S3 buckets, Secrets Manager entries.
- Install. Varolio installs the platform via Helm, pinned to a known release; secrets sync from Secrets Manager into the cluster.
- Identity onboarding. SSO is configured against the customer's IdP; the first admin user is invited.
- Cutover. The customer begins using the deployment. Varolio operates and monitors it on a cadence agreed with the customer.
- Kickoff. Customer provides the GCP project ID and chosen region. Varolio provides the infrastructure-as-code module and the Workload Identity Federation configuration for review.
- Identity grant. Customer creates the service account and workload identity pool trusting Varolio's deploy identity, with the published, least-privilege role set.
- Provisioning. Varolio applies the infrastructure-as-code: VPC, GKE cluster, Cloud SQL, search, Memorystore, Cloud Storage buckets, Secret Manager entries.
- Install. Varolio installs the platform via Helm, pinned to a known release; secrets sync from Secret Manager into the cluster.
- Identity onboarding. SSO is configured against the customer's IdP; the first admin user is invited.
- Cutover. The customer begins using the deployment. Varolio operates and monitors it on a cadence agreed with the customer.
- Kickoff. Customer provides the Azure subscription ID and chosen region. Varolio provides the infrastructure-as-code module and the app registration definition (role assignments + federated credential) for review.
- Identity grant. Customer creates the Entra ID app registration with federated credentials trusting Varolio's operator identity and the published, least-privilege role assignments.
- Provisioning. Varolio applies the infrastructure-as-code: VNet, AKS cluster, Azure Database for PostgreSQL, search, Azure Managed Redis, Blob Storage accounts, Key Vault entries.
- Install. Varolio installs the platform via Helm, pinned to a known release; secrets sync from Key Vault into the cluster.
- Identity onboarding. SSO is configured against the customer's IdP; the first admin user is invited.
- Cutover. The customer begins using the deployment. Varolio operates and monitors it on a cadence agreed with the customer.
When to choose a different model
- Choose Dedicated Cloud if you need single-tenant isolation and region choice but prefer Varolio to own and bill the cloud account.
- Choose BYO Data Store if hosting the content data plane (search, LLM, object storage) is sufficient and you don't need the full stack in your account.