Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.poolside.ai/llms.txt

Use this file to discover all available pages before exploring further.

​
Deployment architecture

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 serves as the foundation for on-premises infrastructure provisioning and the automation and autowiring of Poolside environments. 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.
  • 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

​
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 role-based access control (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 with a consistent source of truth for infrastructure configuration
  • 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: Customer-managed infrastructure (networks, compute, and external services) remains separate from the Poolside-managed application stack, while preserving the tight integration required for platform behavior.

​
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.