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 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 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.
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 |
Public surface
| Hostname | Purpose |
|---|
app.bondata.ai | Main user webapp |
outputs.bondata.ai | Published outputs (CloudFront-fronted, S3-backed) |
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, 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) |
| 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, 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 page. Customers requiring an embedding option that keeps the call inside their own AWS account (AWS Bedrock Titan) should choose Cloud-Prem on 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 Cloud-Prem instead
Choose Cloud-Prem on AWS if you are an enterprise customer, are on an enterprise-tier package, or have a regulatory, contractual, or sovereignty requirement to keep customer data inside your own cloud account. Same software, single-tenant, runs inside an AWS account you own.
