Cloud-Prem is BonData’s deployment model for organizations that require their data and compute to remain in their own cloud account. The customer owns the AWS account; BonData operates the software inside it via an IAM role the customer creates and can revoke at any time. The software running in the customer’s account is functionally identical to Cloud SaaS, same APIs, same runners, same data layer, same AI surface. The difference is that the entire stack is single-tenant, dedicated, and bounded by the customer’s AWS account.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.
How it works
A dedicated AWS account holds the BonData environment, VPC, EKS cluster, RDS PostgreSQL instances, AWS MQ broker, S3 buckets, KMS keys. The customer creates an IAM role (BonDataOperator) that BonData uses to provision (Terraform) and operate (Helm). The deployment is published as {customer}.app.bondata.ai through a BonData-managed Cloudflare subdomain, the customer does not need to configure DNS. The EKS cluster that BonData provisions, node groups, networking, add-ons, IAM, is documented in Amazon EKS reference architecture.
The customer’s data never leaves their AWS account, except for HTTPS calls to AI model providers (Anthropic, OpenAI, Google, e2b), which cross the customer’s egress.
What’s the same as Cloud SaaS
- Every service runs unchanged: API, management API, MCP server, workflow runners, webapps, chat agent.
- The data layer is identical: RDS PostgreSQL, Iceberg on S3 + Athena + Glue, Redshift Serverless, in-cluster Redis.
- The messaging fabric is Amazon MQ running RabbitMQ.
- The identity provider is Descope, with a dedicated project for the customer.
- The CI/CD pipeline is the same; customers pull signed container images from BonData’s ECR via a pull-through cache in their own account.
What’s different
| Cloud SaaS | Cloud-Prem | |
|---|---|---|
| Tenancy | Multi-tenant | Single-tenant, dedicated |
| AWS account | BonData’s | Customer’s |
| Region | US by default, EU on request | Customer’s choice |
| Public surface | app.bondata.ai | {customer}.app.bondata.ai |
| Operator access | BonData internal SSO | BonData SSO + AssumeRole into customer’s IAM role |
| Egress to model providers | Via BonData’s NAT | Via customer’s NAT |
| AWS bill | Included in subscription | Direct to customer |
| Upgrade cadence | Rolling, gated by CI + peer review | Scheduled with customer |
AWS account requirements
- A dedicated AWS account for the deployment, separate from the customer’s primary production workload.
- A region where Amazon EKS, RDS for PostgreSQL, Amazon MQ for RabbitMQ, S3, and AWS Secrets Manager are all available. Regions BonData validates by default: US East (Virginia), US West (Oregon), and EU West (Ireland). Other regions, including EU Central (Frankfurt), are available on request.
- AWS Organizations SCPs are permitted; BonData publishes the actions the deployment requires so they can be allow-listed at the OU level.
- Service quotas for EKS clusters, RDS instances, AWS MQ brokers, and NAT gateways must be sufficient before provisioning.
IAM
The customer creates a single IAM role,BonDataOperator, that BonData assumes for both Terraform provisioning and ongoing operation.
Trust policy. Trusts a BonData deploy account (account ID shared during onboarding) with an sts:ExternalId condition keyed to the customer’s account.
Permissions. Least-privilege, broken down by service. No *:*, no iam:*, no s3:*.
| Service | Actions (summary) |
|---|---|
| EKS | Describe/list cluster and node groups; create, update, and delete clusters, node groups, and addons. |
| EC2 (VPC, SG, NAT, EBS) | Scoped to resources tagged bondata:managed=true. Includes VPC, subnet, security group, NAT gateway, and EBS lifecycle actions. |
| RDS | Describe/list and create/modify/delete DB instances, subnet groups, and parameter groups, scoped to instances tagged bondata:managed=true. |
| Amazon MQ | Describe, list, create, update, and delete brokers. |
| S3 | Object, policy, and bucket actions scoped to buckets prefixed bondata-{customer}-*. |
| KMS | Create, describe, encrypt, decrypt, and generate data keys on BonData-tagged keys. Customer-managed keys, when used, remain under customer control. |
| AWS Secrets Manager | Get/put secret value, create secret, describe, scoped to secrets prefixed bondata/{customer}/*. |
| ECR (pull-through) | Authorization and image pull on the BonData registry. |
| IAM | Create role, attach policy, pass role, only for roles prefixed bondata- (used for IRSA service accounts). No user creation. |
| CloudWatch Logs | Create log group, put log events on bondata/* log groups. |
| Route 53 | Manage records on the private zone created by Terraform. The public zone ({customer}.app.bondata.ai) is managed on BonData’s Cloudflare. |
Network and connectivity
Ingress. Public access is via Cloudflare on{customer}.app.bondata.ai. The Cloudflare Tunnel controller runs in the cluster and dials outbound to Cloudflare; the customer’s AWS account does not need to accept inbound from the public internet. An ALB-fronted ingress is available where customer policy requires it.
Egress. All outbound traffic exits via the VPC NAT gateway. The destinations BonData calls, Anthropic, OpenAI, Google, e2b, and the integration endpoints the customer has activated, must be reachable from the customer’s egress.
Connectivity to the customer’s data sources. The BonData deployment runs in the customer’s AWS account and reaches the customer’s databases, warehouses, and SaaS through whichever path the customer prefers: same-VPC (default), VPC peering, or site-to-site VPN.
Encryption
| Layer | Default | Customer-managed key option |
|---|---|---|
| RDS PostgreSQL at rest | AWS KMS (AWS-managed) | Customer KMS key, configurable per engagement |
| S3 buckets | SSE-S3; SSE-KMS for sensitive buckets | Customer KMS key, configurable per engagement |
| EBS volumes | AWS KMS (AWS-managed) | Customer KMS key, configurable per engagement |
| Application-layer (integration credentials, auth tokens) | App-managed keys in AWS Secrets Manager | Customer-KMS-wrapped Secrets Manager |
| In transit | TLS 1.2+ at every hop | n/a |
Operator access and audit
All BonData operator access is outbound from BonData’s network to the customer’s AWS API. No inbound rules are added to the customer’s account. Operator access is SSO-gated; AssumeRole credentials are session-bound and short-lived; every action is recorded in the customer’s CloudTrail under the operator’s session name. EKS audit logs and application logs are written to the customer’s CloudWatch in the customer’s account. Customers can additionally forward application logs to their own SIEM (Splunk, Datadog, Panther, and similar).Provisioning lifecycle
- Kickoff. Customer provides an AWS account ID and chosen region. BonData provides the Terraform module and the
BonDataOperatorIAM role definition. - IAM role creation. Customer creates the role via CloudFormation or Terraform. Trust policy permits the BonData deploy account; permissions are scoped to the action list above.
- Terraform apply. BonData runs Terraform via the role: VPC, EKS, node groups, RDS, Amazon MQ, S3, KMS, IRSA service accounts, Route 53 private zone, AWS Secrets Manager entries.
- Helm install. BonData runs the umbrella Helm chart pinned to a known version. External Secrets Operator pulls credentials from AWS Secrets Manager into Kubernetes secrets.
- Cloudflare hook-up. BonData adds the
{customer}.app.bondata.airecord on the BonData Cloudflare zone and configures the Cloudflare Tunnel ingress in the customer’s cluster. - Identity onboarding. A dedicated Descope project for the customer is provisioned. SSO is configured to the customer’s IdP. First admin user is invited.
- Cutover. Customer begins using the deployment. BonData operates and monitors.
Ready to start a Cloud-Prem deployment?
Contact us to kick off the engagement. We’ll walk through the AWS account requirements, IAM trust policy, and Terraform module with your security and platform teams, and agree a target onboarding schedule.
Backups, disaster recovery, and upgrades
- Backups. RDS automated backups with point-in-time recovery, inside the customer’s account. S3 versioning enabled on internal storage. Iceberg snapshots provide time-travel on the data lake.
- Disaster recovery. Multi-AZ within the chosen region by default. Cross-region DR is scoped per engagement.
- Upgrades. New BonData versions are applied via Helm by BonData against the customer’s cluster, on a schedule agreed with the customer. Rolling updates; zero downtime for the API tier.