Supported deployments

Poolside supports a defined set of deployment options that have been tested and validated in enterprise environments.

​

Deployment options

Poolside supports the following deployment options across cloud and on-premises environments. The table below summarizes the key characteristics and supported configurations.

​

Cloud deployments

For AWS deployment options, architecture, and operational considerations, see AWS cloud deployment.

​

On-premises deployments

For supported on-premises hardware configurations, architecture constraints, installation approach, and operational responsibilities, see On-premises deployment. For the certified on-premises software stack and version inventory for this release, see Certified on-premises software stack.

​

Deployment architecture: Why Terraform for Poolside

Poolside is architected as a tightly integrated AI platform where infrastructure and application components are intentionally coupled to ensure optimal performance and reliability. This architectural approach drives the deployment methodology. Terraform supports all Poolside deployment options and serves as a common foundation for infrastructure provisioning and the automation and autowiring of Poolside environments across deployments. While more native tools exist for specific parts of the stack (for example, Helm is typically favored in Kubernetes clusters), deploying Poolside requires linking the infrastructure and deployment layers more intimately than a single tool like Helm can provide alone. Another benefit of Terraform is drift detection and remediation, along with the ability to test and validate all supported deployment options across new installations and supported upgrade paths.

​

Platform integration architecture

Poolside adapts its internal architecture based on the deployment environment. Cloud deployments:

• Use cloud-managed services such as Amazon RDS, Amazon EKS, Application Load Balancers, Amazon ECR, and optionally Amazon Cognito
• External service endpoints drive internal routing and authentication flows
• Network topology is defined by VPC and security group configuration

On-premises deployments:

• Run all required infrastructure components within the Kubernetes cluster, including PostgreSQL, object storage, identity provider, and container registry, supporting offline and air-gapped environments while maintaining deployment consistency
• Rely on internal service discovery and in-cluster certificate management
• Use different networking patterns and storage backends than cloud deployments

Why this matters: These are not just configuration differences - they represent different data flows and service architectures. While authentication remains consistent through OIDC-compliant identity providers, the underlying storage, networking, and service discovery patterns differ between cloud deployments and on-premises deployments.

​

Platform evolution requirements

AI platform development velocity: The AI space evolves rapidly, and Poolside continuously expands platform capabilities to better serve customer needs. The deployment approach must accommodate coordinated changes across infrastructure and application layers, including:

• Model architecture evolution:
  New model types require updated serving configurations, memory allocation, and prompt template management
• Emerging AI capabilities:
  Server-side execution, agent orchestration, Model Context Protocol (MCP) integration, and advanced indexing features
• Enterprise integration expansion:
  Third-party tool integrations, enhanced Poolside Console administrative capabilities, and evolving RBAC requirements
• Performance and scale optimizations:
  Infrastructure changes that directly impact application configuration and runtime behavior

Update scenarios:

• Routine platform updates:
  Application: New container images, model configurations, feature toggles
  Timeline: Weekly to monthly updates
• Model architecture changes:
  Application: Serving configurations, prompt templates, resource allocation
  Infrastructure: No infrastructure changes required for most model updates
  Timeline: Typically quarterly or less frequently
• Infrastructure expansion:
  Infrastructure: New GPU pools, storage backends, networking policies
  Application: Updated configurations to leverage new infrastructure
  Timeline: Quarterly or as needed for major capabilities

Deployment validation: This integrated approach enables comprehensive testing of complete configuration flows across all supported deployment modalities. Each pathway is validated in the testing pipeline, ensuring deployed configurations match the configurations that have been tested and certified.

​

Enterprise integration considerations

Deployment orchestration: Terraform-based deployments integrate with enterprise change management processes:

• Infrastructure changes are typically reviewed by infrastructure and security teams and occur infrequently
• Platform-level changes are reviewed by application or platform teams and support routine updates without re-provisioning infrastructure
• Most ongoing updates affect only the platform layer, allowing operational independence from infrastructure changes

Enterprise state management:

• Remote state storage: Centralized state management using S3 or Azure backends with DynamoDB locking
• Drift detection: Automated identification of configuration changes outside Terraform control
• State recovery: Ability to restore deployments to known-good configurations
• Audit trail: Complete history of infrastructure and application changes with attribution

Existing enterprise tooling:

• Terraform modules run through standard enterprise CI/CD systems such as Jenkins or GitLab CI, as well as the CLI
• Standard Terraform plan and apply workflows with existing approval gates
• Infrastructure outputs such as endpoints and certificates automatically injected into application configuration

Operational boundaries: Clear separation is maintained between customer-managed infrastructure (networks, compute, external services) and the Poolside-managed application stack, while preserving the tight integration required for platform functionality.

​

Technical implementation

Self-contained Terraform delivery: Poolside provides a self-contained Terraform-based deployment that includes all required modules, providers, and dependencies with pinned versions to ensure consistent and repeatable installations. Kubernetes resource management: Poolside uses Terraform’s native Kubernetes provider with kubernetes_* resources, providing:

• Full visibility into created resources and dependencies
• Reliable resource decommissioning following the correct dependency order
• Integration with external infrastructure without manual configuration injection

Selective Helm integration: Complex third-party components such as GPU operators and load balancer controllers use Helm charts where operational benefits outweigh integration complexity. Application components use direct Kubernetes resources to enable tighter control and dynamic configuration injection. Configuration consistency: Infrastructure outputs automatically populate application configuration through validated configuration data stores, ensuring compatible and correctly configured Poolside deployments. This eliminates manual configuration steps and ensures consistent, compatible deployments across supported environments.

​

Support and compatibility

This integrated approach enables Poolside to provide consistent platform behavior and comprehensive support across diverse enterprise environments. For questions about integration with specific enterprise tooling or deployment workflows, contact a Poolside representative.