AWS EKS Deployment Prerequisites
Prepare infrastructure separately for Staging and Production. The overview defines deployment scope and responsibilities. The installation steps use the supplied scripts and configuration templates.
Application capacity and compute
Size the AICC deployment according to the number of agents used, automation frequency, concurrent executions, and agent complexity. One automation represents one agent execution. Small, Medium, and Large describe workload profiles rather than fixed agent-count or execution limits.
| Deployment size | Typical workload profile |
|---|---|
| Small | An initial deployment with a limited set of agents, less frequent automation, and low concurrent execution. |
| Medium | A growing deployment with more active agents, more frequent automation, or greater concurrency and workload complexity. |
| Large | A deployment with sustained high automation activity, substantial concurrent execution, or resource-intensive agents. |
For modest initial usage, plan for a Small workload and validate the required container resources in Staging. Increase capacity as you add agents, run automations more frequently, or need greater concurrency. Multiple conversational agents running in parallel can require additional resources even with relatively few agents. If the expected workload is demanding from the outset, provision accordingly before Production.
The following tables provide aggregate AICC application capacity starting points for each workload profile. The figures use the application-server values in the AICC system requirements as planning estimates; they are not benchmark-validated Kubernetes capacity guarantees. Validate the selected configuration with representative workloads in Staging before Production use.
Small deployment
| Resource | Minimum planning estimate | Recommended planning estimate |
|---|---|---|
| CPU | 4 cores, 2 GHz or faster | 6 cores, 2.5 GHz or faster |
| RAM | 8 GB | 12 GB |
| Application disk | 50 GB | 100 GB |
| Network | 1 Gbps | 1 Gbps |
Medium deployment
| Resource | Minimum planning estimate | Recommended planning estimate |
|---|---|---|
| CPU | 8 cores, 2.5 GHz or faster | 12 cores, 2.5 GHz or faster |
| RAM | 16 GB | 24 GB |
| Application disk | 100 GB | 250 GB |
| Network | 1 Gbps | 1 Gbps |
Large deployment
| Resource | Minimum planning estimate | Recommended planning estimate |
|---|---|---|
| CPU | 16 cores, 2.5 GHz or faster | 20 cores, 2.5 GHz or faster |
| RAM | 32 GB | 64 GB |
| Application disk | 250 GB | 500 GB |
| Network | 1 Gbps | 1 Gbps |
Apply the capacity estimates
Use the selected profile separately for each environment; Staging and Production may have different workload profiles. The estimates exclude Kubernetes overhead, databases, and other supporting infrastructure, including separate ingestion dependencies. Add capacity for those resources when planning the deployment. Application disk figures are storage planning estimates, not per-node disk requirements or PVC sizes.
These figures do not specify node sizes, container resource requests or limits, or replica counts. Monitor CPU, memory, execution times, queued work, database performance, concurrent voice sessions, and storage growth to determine when more capacity is needed. Follow the capacity and scaling guidance when adjusting resources; increasing service replicas requires validation of the service's supported scaling behavior.
The license file separately controls the permitted numbers of Server Agents and Local Agents. License limits do not establish infrastructure capacity. Local Agent execution requires separate Windows infrastructure outside this EKS deployment, as described in the deployment scope.
Use Linux amd64 (x86_64) worker nodes; ARM/Graviton application nodes are not supported by the supplied images. Two or more Ready nodes are recommended. Set CPU/memory requests and limits for each applicable service; application allocations are not supplied by default. Multiple nodes alone do not provide application high availability, and bundled Redis remains a single replica.
Infrastructure checklist
| Requirement | Preparation |
|---|---|
| EKS | Operational cluster, suitable nodes, cluster access and workload-management permissions |
| ECR | Repositories for six application images, Redis, and the OCI Helm chart; import/push rights and node pull access |
| ALB | AWS Load Balancer Controller with required AWS permissions and appropriate subnet/security-group configuration |
| DNS and TLS | Environment hostname and an Issued ACM certificate covering it in the ALB region |
| EFS | Encrypted file system, mount targets in worker-node Availability Zones, TCP 2049 access, EFS CSI driver and controller IAM permissions |
| StorageClass | efs.csi.aws.com, access-point provisioning, UID/GID 10001, reclaim policy Retain |
| Secrets | Independent master key per environment, secure backup outside the cluster, and TURN credential if used |
| Databases | Reachable primary database and conditional archival/ingestion stores |
| TURN | Reachable relay and sufficient bandwidth when browser voice is enabled |
| S3 | Optional document bucket, IRSA role, and bucket/object permissions |
The supplied configuration uses ALB target type ip, backend frontend Service port 80, and application container port 8080. TLS ends at the ALB. Set idle timeout to at least 3600 seconds, preserve forwarded client information, and support WebSockets and uploads up to the application's 1 GB limit. Validate large uploads through the complete ingress path. End-to-end TLS requires separate design and compatibility validation.
Tools and access
Run the scripts from Linux, macOS, WSL, Git Bash, or an appropriately configured CloudShell session. Verify tools rather than assuming they are preinstalled:
- AWS CLI with credentials for the intended account.
kubectlconfigured for the cluster and compatible with its Kubernetes version.- Helm 3.8 or newer for OCI chart support.
- Bash and common utilities, including
curl,tar,gzip,openssl, and a SHA-256 tool. unzipwhen extracting the package or bootstrapping ORAS on Git Bash.
The mirror script uses an installed ORAS binary or downloads a pinned, checksum-verified binary. Permit its GitHub release download or preinstall an approved ORAS version. A private cluster also requires an operator environment with network access to its API endpoint.
Separate ECR import/push permissions, application deployment permissions, and runtime permissions. Deployment uses AWS read access for ECR/ACM checks, Helm registry authentication, and Kubernetes permissions for the release resources and Secrets. Applying the StorageClass requires cluster-level permission. The optional preflight database check also needs diagnostic-Pod create/attach/delete permissions.
Databases and setup
The Customer Infrastructure team provisions, secures, backs up, and operates databases. This guide uses PostgreSQL; the package recommends PostgreSQL 15 as a starting point. Obtain release compatibility guidance for the selected database version. IB-X also supports SQL Server for its primary database with the corresponding release-specific configuration.
| Store | Technology | Requirement |
|---|---|---|
| Primary | PostgreSQL baseline | Required; platform data and execution history |
| Execution history archival | PostgreSQL | Required when archival is enabled |
| Ingestion | PostgreSQL | Required when Ingestion is enabled |
| Vector | Qdrant v1.17.0 or above | Required when Ingestion is enabled |
| Graph | Neo4j Server 5.26.x or above | Required when Ingestion is enabled |
Use separate stores and credentials per environment. The primary database connection is entered through the first-run wizard, not Helm values. The database account must initialize and modify the application schema and, where required, create the database. Archive policies may move historical records to a separate database or permanently delete them; configure retention deliberately.
Redis is bundled, mandatory, password-authenticated, and internal to the cluster. Keep it enabled and mirror its image to ECR. External Redis/ElastiCache is not supported by this deployment configuration. Its in-memory messaging state requires separate consideration from the persistent application database.
Persistent configuration
All application services share writable EFS storage using ReadWriteMany at /aicc. An EBS single-writer volume is not a substitute for this shared mount. The supplied EFS access point uses UID/GID 10001 and directory permissions 775. Configure the EFS CSI controller through EKS Pod Identity or IRSA with the appropriate EFS permissions.
Create a mount target in each worker-node Availability Zone, not each individual subnet. Regional EFS supports one mount target per Availability Zone. See AWS EFS mount-target guidance.
The default 5Gi PVC request does not cap EFS capacity. Isolate environments with separate file systems or access-point paths. A new volume need not be prepopulated: the wizard creates /aicc/data/appsettings.json. Back up configuration, documents, and other required persistent paths along with the matching master key. Retain protects backing storage from automatic reclamation; it is not a backup or a complete reinstall procedure.
Network connectivity
Use the following flows when planning security groups, firewalls, proxies, and network policies. Ports are defaults; match actual dependency endpoints and TURN configuration.
| Source | Destination | Protocol/port | Purpose |
|---|---|---|---|
| Browsers and applicable Windows Local Agents | ALB | TCP 443 | UI, APIs and WebSockets |
| ALB | Frontend Pods | TCP 8080 | HTTP after TLS termination |
| Application workloads | Primary/archival PostgreSQL | TCP 5432 | Database access |
| Application workloads | Bundled Redis | TCP 6379 | Queues and SignalR |
| Ingestion | PostgreSQL, Qdrant, Neo4j | TCP 5432, 6333/6334, 7687 | Conditional ingestion |
| Worker nodes | EFS mount targets | TCP 2049 | Shared storage |
| Worker nodes | ECR and required AWS image-pull dependencies | TCP 443 | Image pulls |
| Browsers and Voice | TURN | UDP/TCP 3478, TLS 5349 if configured, configured relay range | Conditional voice media |
| Voice and Worker | Configured AI providers | HTTPS 443 or provider-defined endpoints | Speech and language services |
| Mirror host | IntelliBuddies registry, ECR, Docker Hub, ORAS download host | HTTPS 443 | Artifact import and tooling |
Permit internal Kubernetes service traffic and cluster DNS. Confirm the Service ports and container target ports for the supplied chart; application container port 8080 and frontend Service port 80 are distinct.
| IntelliBuddies endpoint | Purpose | Requirement |
|---|---|---|
https://accounts.intellibuddies.com | License activation | Required |
https://registry.ib-x.ai | Artifact import and updates | Required from the import host |
https://igservices.intellibuddies.com | Integration Gateway | When corresponding services are used |
https://supportanalytics.intellibuddies.com | Integration Gateway analytics | When corresponding services are used |
Application Pods pull images from customer ECR. Direct image-pull access to the IntelliBuddies registry is unnecessary. Additional integrations need their own approved connectivity.
Browser voice
TURN is required when browser-based voice is enabled; non-voice deployments do not need it. The supplied deployment relays browser voice media through TURN. Provide browser and Voice-workload connectivity, transport/relay-port access, dedicated credentials, and bandwidth for concurrent calls. HTTPS is required for browser microphone access. The deployment guide uses Helm environment settings and a Kubernetes credential Secret.
Licensing
Activate a license for each environment before use. Enable required licensing connectivity and retain the licensing information supplied by IntelliBuddies. See License Activation for general guidance; complete activation through the EKS deployment's setup flow.