> ## Documentation Index
> Fetch the complete documentation index at: https://docs.bondata.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Cloud SaaS

> Multi-tenant deployment operated entirely by BonData.

**Cloud SaaS** is BonData's multi-tenant deployment model, intended for **proofs of concept and customers on lower-tier packages**. A single multi-tenant environment, operated entirely by BonData, serves these customers; tenants are isolated logically at the application layer and share the same managed AWS services in BonData's AWS account.

Enterprise customers and any customer with regulatory, contractual, or sovereignty requirements should use [Cloud-Prem on AWS](/platform/deployment-scenarios/cloud-prem-aws) instead - same software, single-tenant, running inside an AWS account the customer owns.

Cloud SaaS removes operational burden for the customers it targets: no AWS account to provision, no networking to configure, no upgrade cycle to schedule, and the same release cadence and operational telemetry that BonData uses internally.

<Frame caption="BonData Cloud SaaS, multi-tenant topology">
  <img src="https://mintcdn.com/bondata/BGXXgSUIAub5s7IL/images/platform/cloud-saas-architecture.png?fit=max&auto=format&n=BGXXgSUIAub5s7IL&q=85&s=3b51f24407b3ce065f3baa7486182d78" width="4094" height="1605" data-path="images/platform/cloud-saas-architecture.png" />
</Frame>

## Region and environment

Cloud SaaS is hosted on AWS in a dedicated production account with its own VPC, EKS cluster, RDS instance, message broker, and secret store. The **United States** is the default region; **EU** hosting is available on customer request.

## Tenancy and isolation

Tenant isolation is enforced at the application layer on every request, in three places:

* **Database queries** against the operational database and the data lake are filtered by tenant. A query that does not carry a tenant identifier is rejected at the API boundary.
* **Object-storage keys** in the internal S3 bucket are namespaced by tenant. Cross-tenant key access is not possible because the API never issues a key for a tenant other than the caller's.
* **Integration credentials** are stored per-tenant. A workflow runs as a specific user in a specific tenant, and the credentials used for any integration call are resolved from that tenant's credential set.

In addition, the user-facing application and the management application run as separate Kubernetes Deployments behind separate Descope projects. A user with administrative permissions inside a tenant cannot reach the platform-management surface.

## Encryption

| Layer                                                    | Cloud SaaS                                              |
| -------------------------------------------------------- | ------------------------------------------------------- |
| RDS PostgreSQL at rest                                   | AWS KMS (AWS-managed key)                               |
| S3 buckets                                               | SSE-S3; SSE-KMS (AWS-managed key) for sensitive buckets |
| EBS volumes                                              | AWS KMS (AWS-managed key)                               |
| Application-layer (integration credentials, auth tokens) | App-managed keys stored in AWS Secrets Manager          |
| In transit                                               | TLS 1.2+ at every hop                                   |

**Customer-managed encryption keys (BYOK) are not available in Cloud SaaS.** Customers who require BYOK should choose [Cloud-Prem on AWS](/platform/deployment-scenarios/cloud-prem-aws#encryption), which supports customer-managed AWS KMS keys for RDS, S3, EBS, and application-layer encryption.

## Public surface

| Hostname             | Purpose                                           |
| -------------------- | ------------------------------------------------- |
| `app.bondata.ai`     | Main user webapp                                  |
| `outputs.bondata.ai` | Published outputs (CloudFront-fronted, S3-backed) |

All public surface is fronted by **Cloudflare** (DNS, TLS, WAF, DDoS protection). Cloudflare terminates TLS and forwards to an AWS Application Load Balancer inside the cluster's VPC. Published outputs at `outputs.bondata.ai` are served through Amazon CloudFront. Both Cloudflare and CloudFront operate as global edge networks; customers with strict regional-residency requirements for ingress termination or published-output delivery should choose [Cloud-Prem on AWS](/platform/deployment-scenarios/cloud-prem-aws#network-and-connectivity), which supports an ALB-only ingress mode inside the customer's VPC.

## Operational ownership

| Area                                 | Owner                                                                  |
| ------------------------------------ | ---------------------------------------------------------------------- |
| AWS account, VPC, EKS, RDS, MQ, S3   | BonData                                                                |
| OS and node patching                 | BonData (EKS-managed node groups)                                      |
| Application code and releases        | BonData (Helm-driven deploys, see [Upgrade cadence](#upgrade-cadence)) |
| Database backups and PITR            | BonData                                                                |
| Secret rotation                      | BonData                                                                |
| Monitoring, alerting, on-call        | BonData                                                                |
| Customer user accounts and roles     | Customer                                                               |
| Customer SSO configuration           | Shared, customer provides IdP, BonData configures Descope              |
| Integration credential authorization | Customer (authorizes OAuth scopes / provides credentials)              |

## Operator access

BonData operator access to the Cloud SaaS environment is **SSO-gated** through BonData's internal identity provider, uses **short-lived AssumeRole credentials** with session-bound names, and is **outbound-only** from BonData's network - no inbound access from the public internet to operator tooling.

All operator activity is recorded in BonData's internal CloudTrail and SSO logs. **Tenant-scoped operator-access extracts are available on request as part of enterprise-tier SaaS contracts**, via `security@bondata.ai`, within the SLA defined in the contract. Customers requiring continuous, customer-visible CloudTrail logging of every operator action should use [Cloud-Prem on AWS](/platform/deployment-scenarios/cloud-prem-aws#operator-access-and-audit), where every BonData action is recorded in the customer's own CloudTrail in real time.

## AI and embedding providers

LLM calls and embedding generation in Cloud SaaS use the same default AI providers documented on the [Application architecture](/platform/application-architecture#ai-providers) page. Customers requiring an embedding option that keeps the call inside their own AWS account (AWS Bedrock Titan) should choose [Cloud-Prem on AWS](/platform/deployment-scenarios/cloud-prem-aws).

## Backups and disaster recovery

* **Backups.** RDS automated backups with point-in-time recovery. S3 versioning enabled on internal buckets. Iceberg snapshots provide time-travel on the data lake.
* **Disaster recovery.** Multi-AZ within the deployment region by default; cross-region DR is available on request.
* **RPO and RTO.** Specific recovery-point and recovery-time objectives are documented in the engagement contract for enterprise-tier SaaS customers.

## Upgrade cadence

Every change to production goes through the same release pipeline: a passing CI suite (unit, integration, and tenancy-isolation tests), peer-reviewed pull-request approval, and manual dispatch by an authorized release operator. Deploys are rolling updates only, no in-place upgrades; the API tier runs with multiple replicas across availability zones so customer requests are not interrupted during a deploy. Helm rollback to the previous chart revision is available if a regression surfaces post-deploy. Sentry releases are created on every production deploy for error-to-commit traceability.

## When to choose a single-tenant model instead

Choose [Dedicated Cloud](/platform/deployment-scenarios/dedicated-cloud) if you need single-tenant isolation with no shared services and a choice of region, but want BonData to continue owning and operating the AWS account. Same software, dedicated environment, fully managed.

Choose [Cloud-Prem on AWS](/platform/deployment-scenarios/cloud-prem-aws) if you have a regulatory, contractual, or sovereignty requirement to keep customer data inside an AWS account you own, or you require customer-managed encryption keys (BYOK). Same software, single-tenant, runs inside an AWS account you own.