Deployment patterns
Understand Clearly AI deployment options: multi-tenant, single-tenant, and private cloud.
Clearly AI supports three deployment patterns: multi-tenant SaaS, single-tenant SaaS, and private cloud. The product experience is the same across patterns; the difference is where infrastructure runs and how strongly the environment is isolated.
Multi-tenant SaaS
Multi-tenant SaaS is the standard hosted deployment. Clearly AI operates the application infrastructure, shared platform services, monitoring, and release process. Your organization has its own access controls, configuration, source connections, reviews, and data boundaries inside the hosted platform.
Use this when your team wants the fastest rollout and your connected systems can accept Clearly AI's hosted URLs, OAuth callbacks, webhooks, and static egress IPs.
Single-tenant SaaS
Single-tenant SaaS runs a dedicated Clearly AI environment for your organization. Dedicated resources include an AWS account boundary, VPC, compute services, storage, queues, secrets, logs, and monitoring.
Use this when your organization wants a hosted product experience with stronger tenant isolation, dedicated scaling, and clearer resource boundaries.
Private cloud
Private cloud runs Clearly AI inside your cloud environment. Clearly AI supports Bring Your Own Cloud deployments on AWS, Azure, and Google Cloud.
For AWS, Clearly AI also supports Bring Your Own VPC:
- BYOC: Clearly AI provisions a dedicated virtual network and required application infrastructure in your cloud account.
- BYOVPC: Clearly AI deploys into your existing AWS VPC using private subnets you provide.
This pattern keeps application infrastructure, data residency, and network policy inside your cloud boundary while preserving managed deployment, update, logging, and monitoring workflows. It is best suited when you already operate most connected systems inside your own cloud or private network.
Network access
Private cloud still needs to communicate with identity providers, model providers, source systems, and integrations. The exact network plan depends on where those systems live.
If your Jira, ServiceNow, GitHub Enterprise, Confluence, or internal APIs are also self-hosted in the same cloud or connected network, private cloud usually gives the cleanest integration path: traffic can stay inside routes, peering, VPN, PrivateLink-style connectivity, or firewall policy you control.
If a connected tool is hosted outside your network, plan inbound access for callbacks and webhooks. For example, a Jira Cloud automation webhook must be able to reach the Clearly AI private cloud endpoint. That may require public ingress, an allowlisted reverse proxy, DNS and TLS setup, WAF rules, and firewall changes. For outbound integrations, allow Clearly AI's private-cloud egress path to reach the provider APIs.
We generally recommend private cloud when you already self-host the systems Clearly AI needs to read from or write to, or when you already have a cloud networking pattern for safely exposing private applications to SaaS webhooks and OAuth callbacks.
Architecture
Across deployment patterns, Clearly AI runs containerized application services behind managed ingress, stores application data in managed cloud storage and database services, uses managed queues for background work, stores secrets in cloud secret stores, and emits logs and metrics to the deployment environment's observability stack. Each environment has independent network, compute, and storage allocation.
For Clearly AI-hosted multi-tenant and single-tenant stacks, application workloads run on AWS ECS Fargate in private subnets behind an Application Load Balancer with TLS certificates. DNS and certificates use Route 53 and AWS Certificate Manager where Clearly AI manages the domain. Storage uses S3 with block public access, SSL enforcement, encryption, and versioning. Application state and job metadata use DynamoDB tables. Background work runs through SQS FIFO queues with dead-letter queues.
Hosted AWS secrets and configuration are stored in AWS Secrets Manager and SSM Parameter Store. Container images are stored in ECR. CloudWatch provides logs, metrics, dashboards, and alarms. AWS WAF protects application ingress, and WAF and load balancer access logs are written to S3. VPC endpoints keep traffic to AWS services such as S3, DynamoDB, ECR, SSM, Secrets Manager, and CloudWatch Logs on AWS networking paths where supported. AWS Bedrock can be used as a model provider when configured for the environment.
Private cloud deployments run Clearly AI on Kubernetes in your cloud environment. Workloads run inside your cloud network with managed ingress, release channels, health checks, rollback, logs, and metrics. You can also connect your own observability, security monitoring, backup, disaster recovery, and network controls according to your cloud standards.