> For the complete documentation index, see [llms.txt](https://docs.catalyx.solutions/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.catalyx.solutions/catalyx-blockchain-manager/canton-network/version-2.0/architecture.md). # Technical Architecture CAT-BM is a Kubernetes-native solution designed to manage Canton's distributed ledger infrastructure with high availability, enterprise-grade security, and operational automation. CAT-BM uses a custom Kubernetes operator and custom resource definitions (CRDs) to manage Canton components across environments. While the reference setup runs on Amazon EKS, it is fully portable to Microsoft Azure (AKS), Google Cloud (GKE), or on-premises Kubernetes / OpenShift. Beyond infrastructure management, CAT-BM provides operational capabilities at the Canton and Daml application level, including managing parties and users, deploying DARs, configuring identity providers, performing backup and restore operations, monitoring, integration with wallet providers, and handling upgrades. ## In this section
System ContextHow CAT-BM relates to the systems around it./pages/pHUWGLqpGCfV76ES8KRV
High-Level ArchitectureThe components inside CAT-BM and how they interact./pages/4kMtpmzvtlnMxSnfoR98
Canton Network TopologyPrivate subnets, bridge validators, and the global network./pages/81LdNO4gGGQbWsOSxUQL
Cloud InfrastructureThe reference cloud deployment and its building blocks./pages/c6XohGyNjZ9eYRyaxNu4
High Availability & Disaster RecoveryRedundancy, failover, and recovery mechanisms./pages/tj1jExNyuODFIZdRgvIJ
Security & PrivacyAuthentication, infrastructure security, and key management./pages/Z5LsLhJZ6YvlYeWVA2uL
Performance & ScalabilityHow a Canton deployment scales./pages/Jw03oEUzrG3YZJXpxqp6
*** ## Design principles The platform is built around the following capabilities. ### High availability * All critical Canton components are deployed with high availability in mind, ensuring continuous operation, resiliency, and fault tolerance. * **Multi-AZ deployment** — all Canton services and dependencies can be deployed across multiple availability zones within a region, so a single zone failure does not affect system availability. * **Multi-region redundancy** — where required, deployments can be extended across multiple geographic regions, enabling disaster recovery and regional failover. Cross-region data replication and failover mechanisms ensure continuity in the event of a regional outage. * **Self-healing and auto-recovery** — the Kubernetes control plane monitors all workloads and automatically reschedules or restarts failed pods based on probe feedback or node availability. * **Rolling updates and zero-downtime deployments** — component updates and configuration changes are rolled out gradually using Kubernetes' rolling upgrade strategy. Traffic is only directed to healthy, ready pods during deployment. * **Load balancing and traffic routing** — service traffic is distributed using internal Kubernetes load balancers, ensuring even distribution and automatic rerouting on pod or node failure. * **Pod anti-affinity rules** — Canton components are scheduled with anti-affinity rules to distribute replicas across nodes and zones, maximising failure domain isolation. * **Persistent storage with replication** — components that require storage (for example Canton participants backed by PostgreSQL) are provisioned with multi-AZ replication support. * **Kubernetes-native health checks** — liveness probes detect and restart non-responsive components, readiness probes ensure only fully initialised pods receive traffic, and startup probes manage services with longer initialisation periods. ### Enterprise-grade security * Encrypted persistent storage and encrypted communication channels (TLS / mTLS). * Secure secret management via cloud secret managers or Kubernetes Secrets. * Integration with enterprise Key Management Services (AWS KMS, Azure Key Vault) for encryption key lifecycle management. * Support for integration with external Wallet-as-a-Service providers for secure signing and transaction management. * Support for OIDC-compliant identity providers (Keycloak, Okta, Microsoft Entra ID, Auth0, Ping Identity, and others) for authentication and authorisation. * Fine-grained access control using scope and claim mapping from the identity provider. * Role-based access control (RBAC). * Network-level security: IP allowlisting, VPN, and firewall / WAF integration options. * Security audit logging with integration into SIEM platforms. * Regular security patching and vulnerability scanning of container images and dependencies. ### GitOps-driven operations * All infrastructure and deployment configuration is defined declaratively using Helm charts and managed through GitOps practices. * ArgoCD can be used to synchronise desired state from Git repositories to the Kubernetes cluster, enabling traceable, auditable, and consistent deployment pipelines across development, test, staging, and production environments. ### Infrastructure-as-Code * All cloud infrastructure is defined declaratively using Infrastructure-as-Code tooling such as Terraform, enabling reproducible and version-controlled provisioning. * IaC configurations are stored in Git repositories, supporting GitOps-style workflows for infrastructure changes. * Automated pipelines apply changes, ensuring traceable and consistent deployments across environments. * Modular, reusable configurations standardise resources, promote best practices, and reduce configuration drift. ### Automated lifecycle management * CAT-BM automates node provisioning, dependency management, certificate distribution, and topology orchestration. * Built-in support for scaling, patching, and configuration updates through CRDs. ### Monitoring and observability * Integrated with Prometheus and Grafana for metrics collection, visualisation, and alerting. * Logs are aggregated and forwarded to a centralised log store such as Loki. * Health checks, liveness and readiness probes, and custom metrics are exposed for proactive monitoring and incident response. ### Scalability and extensibility * Horizontal and vertical pod autoscaling based on resource usage. * Support for multi-tenant deployments and workload isolation via Kubernetes namespaces and network policies. *** ## Supported versions | Component | Version | | --------------- | --------------- | | Canton Protocol | v2.10 or higher | | Daml | v2.10 or higher | --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.catalyx.solutions/catalyx-blockchain-manager/canton-network/version-2.0/architecture.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.