×
![]()
Choosing your ITRS Analytics deployment model
Before you deploy ITRS Analytics, you must select the right deployment model. This choice determines how the platform is hosted, who manages the underlying Kubernetes infrastructure, what resiliency and backup capabilities are available to you, and how operational responsibilities are divided across your teams.
This guide walks you through the two primary deployment dimensions:
- SaaS vs. Self-Hosted — where and how the platform is operated.
- Bring Your Own (Kubernetes) Cluster (BYOC) vs. Embedded Cluster (EC) — how Kubernetes is provisioned within a self-hosted deployment.
Use the comparisons and guidance on this page to align your deployment choice with your organization’s infrastructure, compliance, availability, and operational requirements.
Note
For a detailed breakdown of resiliency design, high availability architecture, and disaster recovery planning after you have chosen a model, see ITRS Analytics deployment planning and resiliency.
SaaS vs. Self-Hosted Copied
The first decision is whether ITRS manages the platform infrastructure for you (SaaS) or whether your organization operates it on your own infrastructure (Self-Hosted).
| Feature | SaaS | Self-Hosted |
|---|---|---|
| Hosting location | AWS Public Cloud, managed by ITRS | On-premises, private cloud, or public cloud via Bring Your Own (Kubernetes) Cluster or Embedded Cluster |
| Platform management | ITRS Cloud Operations teams | Internal Kubernetes DevOps team |
| Data residency | Client’s choice of AWS Region (costs may vary by region) | Client’s full choice of location and environment |
| Security | TLS, mTLS, Equinix Cloud Connect | TLS, mTLS, service mesh |
| High availability | Deployment spans two availability zones within a single region | Must follow architecture best practices aligned with your business requirements |
| Data backup | Daily automated backups | Daily backups available for BYOC deployments |
| Upgrade management | Planned upgrades, client-approved, no more than two weeks after a release | Client’s responsibility for image mirroring and upgrade execution |
| Application customization | Full identity, role, and access management available with SSO | Full identity, role, and access management available with SSO |
| Cost model | Software costs plus hosting costs (Small, Medium, Large, Extra-Large sizes); optional 2 TB additional storage | Software costs only; infrastructure costs are the client’s responsibility |
When to choose SaaS Copied
Choose SaaS when:
- You want ITRS to manage platform operations, upgrades, and infrastructure health.
- Your team does not have dedicated Kubernetes or cloud operations expertise.
- You require a predictable, fully managed cost model that bundles software and hosting.
- Data residency requirements can be met by an available AWS region.
- You need enterprise-grade high availability across two availability zones without managing the underlying infrastructure yourself.
When to choose Self-Hosted Copied
Choose Self-Hosted when:
- Your organization requires data to remain within a specific on-premises environment or private cloud that is not covered by SaaS regional options.
- You have an existing Kubernetes operations team capable of managing platform lifecycle.
- Your organization’s procurement, security, or compliance policies require full infrastructure ownership.
- You need to integrate ITRS Analytics into an existing internal platform ecosystem (networking, security tooling, storage, observability pipelines).
Note
With Self-Hosted deployments, your internal teams are responsible for patching, upgrades, backup management, and maintaining infrastructure resiliency. Ensure you have the appropriate platform expertise before selecting this model.
BYOC vs. Embedded Cluster (Self-Hosted only) Copied
If you select Self-Hosted, you must then choose how Kubernetes is provisioned: either by bringing your own Kubernetes cluster (BYOC) or by using ITRS’s bundled Kubernetes distribution (Embedded Cluster).
Note
Bring Your Own (Kubernetes) Cluster (BYOC) is the recommended deployment model for production. It provides the broadest set of resiliency, security, and operational capabilities. Embedded Cluster is best suited for proof-of-value deployments or controlled production scenarios where Kubernetes expertise is not available, with the explicit understanding of its limitations.
Quick selection guidance Copied
- Select BYOC when enterprise high availability, backup and restore, standard security tooling integration, and predictable scaling are required.
- Select Embedded Cluster for proof-of-value evaluations or tightly controlled production environments where Kubernetes expertise is unavailable and the HA and data protection limitations are acceptable.
Feature comparison Copied
| Feature | Bring Your Own Cluster (BYOC) | Embedded Cluster |
|---|---|---|
| Platform ownership | Customer-managed Kubernetes (EKS, AKS, GKE, OpenShift, self-hosted) | Kubernetes bundled and managed through ITRS-packaged K0s |
| High availability | Full HA options supported; workloads can reschedule across nodes automatically | Limited HA; stateful workloads depend on the specific node they were scheduled on |
| Storage architecture | Persistent volumes are decoupled through storage classes; supports dynamic expansion | Storage is tied to local node disks; data loss risk if a node fails without HA configured |
| Backup and restore | Supported using platform tooling such as Velero | Not supported; Velero does not support node-local filesystem storage classes used by Embedded Cluster |
| Load balancing and networking | Supports native cloud and enterprise load balancers with DNS integration | No built-in load balancer; customers must supply and manage their own |
| Security | Kubernetes-native security model integrates cleanly with platform policies | Security tooling has view-only access; traditional security agents can interfere with cluster operations |
| Operational responsibility | Clearly divided across infrastructure, platform, and application teams; cluster issues resolved at the appropriate layer | Cluster issues must be escalated to ITRS; limited internal visibility into platform-layer problems |
| Maintenance and patching | Integrates with existing customer patching and lifecycle processes for Kubernetes, OS, storage, and networking | Increased coordination risk; patching and upgrades may require downtime and careful change management |
| Disaster recovery | Not built-in; deploy multiple independent ITRS Analytics instances for DR | Not built-in; deploy multiple independent ITRS Analytics instances for DR |
Decision summary Copied
Use the following summary to confirm your deployment choice before proceeding to installation.
| Requirement | Recommended model |
|---|---|
| ITRS manages all infrastructure | SaaS |
| Data must stay in a specific AWS region | SaaS |
| Data must stay on-premises or in a private cloud | Self-Hosted |
| Full control over Kubernetes platform | Self-Hosted and BYOC |
| No in-house Kubernetes expertise, evaluation only | Self-Hosted and Embedded Cluster |
| Production-grade high availability required | SaaS or Self-Hosted and BYOC |
| Backup and restore required | SaaS or Self-Hosted and BYOC |
| Native security tooling integration required | Self-Hosted and BYOC |
| Existing cloud Kubernetes service (EKS, AKS, GKE) | Self-Hosted and BYOC |
| Deployment on VMs or bare metal without Kubernetes | Self-Hosted and Embedded Cluster |
| Strict compliance or audit data retention | SaaS or Self-Hosted and BYOC |
Plan your rollout Copied
- For resiliency architecture, high availability design, and continuous operations guidance after selecting your deployment model, see ITRS Analytics deployment planning and resiliency.
- For infrastructure sizing and resource requirements, see ITRS Analytics Sizer.
["ITRS Analytics"]
["User Guide", "Technical Reference"]