Choose an installation method

Select the Mission Control installation method that meets your organization’s needs based on your environment, use case, and deployment requirements.

DataStax recommends using Helm to install Mission Control. Helm provides more granular control over your deployment configuration, better integration with GitOps workflows, and greater flexibility for customization compared to other installation methods.

Follow these steps to select your installation path:

  1. Review the installation requirements.

  2. Prepare your Existing Kubernetes cluster.

  3. Choose your installation method:

    • Helm (Recommended): Use this method for fine-grained control and GitOps workflow integration

    • KOTS: Use this method for guided installation with default configurations and automated upgrades

    • Helm with separate cluster resources: Use this method when you need to manage cluster-scoped resources separately from the main installation. This functionality is available in Mission Control 1.12.0 and later.

    • OpenShift: Use this method when you run Red Hat OpenShift as your Kubernetes distribution

  4. Consider the following deployment factors:

    • Single vs multiple instances: Choose based on your availability and scalability requirements

    • Online vs offline installation: Choose based on your network connectivity and security requirements

    • Single vs multiple regions: Choose based on your geographic distribution and performance requirements

Installation environment

Mission Control is installed on your existing Kubernetes clusters, which provides the following benefits:

  • Leverages Kubernetes' scalability, flexibility, and ecosystem

  • Supports advanced Kubernetes features

  • Integrates with existing infrastructure

  • Enables automated scaling and workload management

  • Provides robust orchestration and self-healing capabilities

Compare installation methods

Choose your installation method from these options:

Installation method Use case Advantages Disadvantages

KOTS

Use this method for guided installation with default configurations and automated upgrades.

  • Simplifies installation and configuration.

  • Provides a guided setup process.

  • Supports automated upgrades.

  • Includes a web-based management interface.

  • Limited customization compared to Helm.

  • Less flexibility for advanced configurations.

  • Web interface required for management.

Helm

Use this method for fine-grained control and GitOps workflow integration.

  • Highly customizable using Helm values.

  • Supports automated upgrades.

  • Integrates with GitOps workflows.

  • CLI-based management.

  • Supports separate cluster-level resource management for organizations requiring separation of cluster administration and application management.

  • Requires familiarity with Helm and Kubernetes configuration management.

  • More complex initial setup.

  • Manual configuration required.

Helm with separate cluster resources

Use this method when you need to manage cluster-scoped resources separately from the main installation.

  • Enables separation of cluster-level and application-level resource management.

  • Useful for environments with different teams managing cluster and application resources.

  • Provides more control over the installation process.

  • Supports elevated privileges for cluster-scoped resources.

  • More complex setup and management process.

  • Requires coordination between cluster and application teams.

  • Manual resource management required.

OpenShift

Use this method when you run Red Hat OpenShift as your Kubernetes distribution.

  • Benefits from OpenShift’s security features and enterprise capabilities.

  • Seamless integration with OpenShift ecosystem.

  • Enhanced security and compliance features.

  • Limited to OpenShift environments.

  • Reduced portability to other Kubernetes distributions.

  • OpenShift-specific knowledge required.

Deployment considerations

Choose these deployment factors based on your requirements:

Single vs multiple instances

Deployment type Use case Advantages Disadvantages

Single Instance

Use this option for development or testing only. Production environments require a minimum of three nodes.

  • Simpler setup and management.

  • Requires fewer resources.

  • Lower operational complexity.

  • No built-in redundancy or failover.

  • Limited scalability.

  • Single point of failure.

Multiple Instances

Use this option for high-availability and production-grade deployments.

  • Ensures failover and reliability.

  • Supports horizontal scaling for workload distribution.

  • Better resource utilization.

  • Requires more infrastructure and management.

  • Increased complexity in configuration and maintenance.

  • Higher operational overhead.

Online vs offline installation

Installation type Use case Advantages Disadvantages

Online

Use this method when you have internet access and want to simplify the installation process.

  • Simplifies installation and updates.

  • Supports automated upgrades.

  • Access to latest features and fixes.

  • Requires internet access for installation and updates.

  • External dependencies for package downloads.

  • Potential security concerns.

Offline Airgap

Use this method when you operate in a secure or isolated environment without internet access.

  • Enables deployment in highly secure environments.

  • No external dependencies after initial setup.

  • Better control over updates.

  • Requires manual updates and package transfers.

  • More effort needed for installation and maintenance.

  • Delayed access to updates.

Regional deployment

Deployment regions Use case Advantages Disadvantages

One region

Use this option when you operate in a single geographic location.

  • Centralized management and monitoring.

  • Shared resources for all users.

  • Simpler configuration.

  • Limited to a single region.

  • Shared resources might impact performance.

  • No geographic redundancy.

Multiple regions

Use this option when you need to serve multiple geographic locations.

  • Isolated management and monitoring.

  • Dedicated resources for each group.

  • Geographic redundancy.

  • Increased complexity in configuration and management.

  • Requires additional resources for each region.

  • Higher operational overhead.

Next steps

First, prepare your existing cluster. After your installation environment is prepared, then you can follow the installation guide for your chosen installation method: KOTS, Helm, Helm with separate cluster resources, or OpenShift.

Was this helpful?

Give Feedback

How can we improve the documentation?

© Copyright IBM Corporation 2026 | Privacy policy | Terms of use |  Manage Privacy Choices

Apache, Apache Cassandra, Cassandra, Apache Tomcat, Tomcat, Apache Lucene, Apache Solr, Apache Hadoop, Hadoop, Apache Pulsar, Pulsar, Apache Spark, Spark, Apache TinkerPop, TinkerPop, Apache Kafka and Kafka are either registered trademarks or trademarks of the Apache Software Foundation or its subsidiaries in Canada, the United States and/or other countries. Kubernetes is the registered trademark of the Linux Foundation.

General Inquiries: Contact IBM