Skip to content

Self-Hosted Deployment Guide

Deploy CloudAEye Code Review in your AWS account with the CloudAEye Terraform configuration.

Learn about Cluster size, Auto scaling, LLM config and debug support.

Options

Choose SAAS to get CloudAEye running in minutes without managing infrastructure.

Choose self hosted when you do not want your data to leave the VPC or want to use your LLM provider.

Deployment Options

AWS ECS - We only support AWS ECS for self hosting CloudAEye.

Cluster Sizing Guide

Use deployment_user_count to tell Terraform the approximate number of active developers for the self hosted deployment. Terraform uses that value to set the default always on ECS task counts.

deployment_user_count Standard App Tasks Code Review Tasks Indexer Worker Tasks
< 20 1 1 1
20-99 1 2 2
100-299 2 3 3
300-400 2 4 4
401-999 3 6 6
1000+ 4 8 8

Standard app tasks apply to the default public application services such as the UI, API, auth, repository, webhook, and indexer API services. Code review tasks apply to cloudaeye-reviews. Indexer worker tasks apply to cloudaeye-indexer-worker.

MongoDB and ChromaDB each run as one private ECS service with one task and dedicated managed capacity. They use single ECS managed EBS volumes.

Use these Terraform settings when tuning cluster size:

  • deployment_user_count sets the default always on task counts.
  • ecs_managed_*, mongodb_ecs_managed_*, and chroma_ecs_managed_* settings define the CPU and memory limits ECS Managed Instances can use for each capacity pool.

Autoscaling Behavior

The deployment uses ECS Managed Instances for baseline capacity. Fargate is used only as overflow capacity for autoscaled background workers.

The autoscaled services are:

  • cloudaeye-reviews, which processes the code review queue.
  • cloudaeye-indexer-worker, which processes the indexing queue.

For each autoscaled service, Terraform creates:

  • a baseline ECS service that runs on ECS Managed Instances
  • a separate -fargate-overflow ECS service that starts at 0 tasks
  • an Application Auto Scaling policy for the Fargate overflow service

Application Auto Scaling changes only the Fargate overflow service desired_count. The fixed ECS Managed Instances baseline stays in place so there is always worker capacity, while burst work can scale out on Fargate.

Scaling is based on messages in SQS queue.

Debug FAQ

Debug logging can increase CloudWatch volume and cost. After collecting a support bundle, change it back to info.

How Do I Create A Support Zip?

Use the log collection script from the Terraform bundle:

python scripts/collect_cloudwatch_logs.py \
  --since 2h \
  --app-name cloudaeye \
  --environment onprem \
  --region us-east-2

The script reads CloudWatch log groups named:

/ecs/<app_name>-<environment>/<service-name>

It collects logs for the default ECS services and writes a zip file under log-bundles/, such as:

log-bundles/cloudaeye-onprem-logs-YYYYMMDDTHHMMSSZ.zip

If you use an AWS CLI profile, include it:

python scripts/collect_cloudwatch_logs.py \
  --since 2h \
  --region us-east-2 \
  --profile <aws-profile>

To collect one service at a time, use --service:

python scripts/collect_cloudwatch_logs.py \
  --since 2h \
  --service cloudaeye-reviews \
  --service cloudaeye-indexer-worker

What Should I Send To Support?

Email the generated zip file to:

support@cloudaeye.com

Include:

  • Detailed description of the issue you faced.
  • The approximate time the issue happened.
  • The affected repository or pull request, if relevant.
  • The Terraform app_name, environment, and AWS region.
  • Any ECS service names that were unhealthy.
  • The generated support zip from scripts/collect_cloudwatch_logs.py.

Do not email terraform.tfvars, Terraform state, private keys, API keys, or GitHub App secrets.

Troubleshooting

Application Is Not Reachable

Check:

  • allowed_app_cidr includes your current network.
  • The ALB security group allows inbound traffic on app_port.
  • ALB endpoint matches the URL you are opening.
  • Public ECS services are healthy in the ECS console.

Services Are Not Healthy

Check ECS service events and CloudWatch logs:

aws ecs describe-services \
  --cluster "$(terraform output -raw ecs_cluster_name)" \
  --services <service-name>

Also verify MongoDB and ChromaDB services are running, because application services depend on private data services.

Destroy

To remove the deployment:

terraform destroy

This deletes the infrastructure created by the stack, including ECS services and the ECS-managed EBS data volumes. Export or back up any required data before destroying the deployment.