> For the complete documentation index, see [llms.txt](https://docs.cybus.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cybus.io/documentation/installation-and-upgrades/installing-connectware/installing-connectware-kubernetes.md).

# Installing Connectware (Kubernetes)

This guide walks you through installing Connectware on a Kubernetes cluster using Helm charts. The installation process includes configuring your Helm repository, customizing deployment settings in a `values.yaml` file, and verifying the installation.

## Prerequisites

Before installing Connectware, make sure to meet the following requirements:

* Connectware [license key](/documentation/installation-and-upgrades/licensing.md) is available.
* [Helm version 4](https://helm.sh/docs/intro/quickstart/#install-helm) is installed on your system.
* [kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl) is installed on your system.
* A Kubernetes cluster that meets the [cluster requirements](/getting-started/system-requirements.md#kubernetes-cluster-requirements).
* A chosen Kubernetes namespace for the installation (e.g., `cybus`).
* A chosen installation name (e.g., `connectware`).

{% hint style="info" %}
Throughout this guide, command examples use variables like `${NAMESPACE}`, `${INSTALLATION_NAME}`, and `${REPO_NAME}`. Replace these with your actual values. For example, replace `${NAMESPACE}` with `cybus` if that is your chosen namespace.
{% endhint %}

## Overview of the Installation Process

To install Connectware on Kubernetes, complete the following steps:

1. [Choose a chart version](#choosing-a-chart-version).
2. [Configure a `values.yaml` file](#configuring-the-values.yaml-file).
3. [Install Connectware](#installing-connectware).
4. [Verify the installation](#verifying-the-connectware-installation).
5. [Log into Connectware for the first time](#logging-into-connectware-for-the-first-time).

## Choosing a Chart Version

When installing Connectware, you can either use the latest chart version or pin to a specific version.

When you do not specify a chart version, Helm installs the latest chart, which targets the latest Connectware release.

To install a specific version, look up your target Connectware version in the [Compatibility Matrix](/cybus-helm-charts/compatibility-matrix.md#connectware-helm-chart), find the matching Helm chart version, and install that version of the chart with the `--version` flag.

{% hint style="info" %}
For production environments, install a specific chart version. This gives you reproducible deployments and prevents unintended upgrades.
{% endhint %}

## Configuring the values.yaml File

The `values.yaml` file configures your Connectware deployment through Helm. Use it to customize deployment parameters, manage resources, and configure version settings.

This guide focuses on basic Kubernetes configuration and commonly used parameters.

{% hint style="info" %}
We recommend that you store the `values.yaml` file in a version control system.
{% endhint %}

### Creating a Copy of the Default values.yaml File

A Helm chart includes default configuration values. We recommend creating a copy of the default `values.yaml` file named `default-values.yaml` for reference, and a new empty `values.yaml` file for your customizations.

* Extract the default values and store them in `default-values.yaml` via the following command:

**Example**

{% code lineNumbers="true" %}

```bash
helm show values oci://repo.cybus.io/charts/connectware > default-values.yaml
```

{% endcode %}

### Creating a values.yaml File

After creating the `default-values.yaml` file, create an empty `values.yaml` file for your custom configuration.

* Create and open the file with your preferred editor via the following command. This example uses **vi**. Substitute with your preferred editor:

**Example**

{% code lineNumbers="true" %}

```bash
vi values.yaml
```

{% endcode %}

### Specifying the License Key

A valid license key is required to install Connectware.

#### Choosing a Method

You have the following methods for providing your license key. Choose the method that best fits your security and operational requirements:

* **Method 1 - Plaintext License Key**: For quick testing and development environments.
* **Method 2 - Kubernetes Secret**: For production environments where secrets should be managed separately from configuration files.

#### Method 1 - Plaintext License Key

* Add your license key directly in the `values.yaml` file. Replace `<your-connectware-license-key>` with your actual license key.

{% code title="values.yaml" lineNumbers="true" %}

```yaml
global:
  licenseKey: <your-connectware-license-key>
```

{% endcode %}

#### Method 2 - Kubernetes Secret

Using this method, you manage your license key within your own workflow. You only provide Connectware with the name of a Kubernetes Secret that contains the key. This makes it suitable for production environments where security is a top concern.

When using this method, you must create at least one Secret:

* A generic Secret for the license key itself (required)
* A Docker registry Secret for pulling Connectware container images (optional, see warning below)

{% hint style="warning" %}
Unlike Method 1, the Helm chart does not automatically generate the image pull secret when using an existing Kubernetes Secret for the license key. You must create it manually in step 2 below, unless you are using a custom registry that does not require authentication.
{% endhint %}

1. Create a generic Secret containing your license key under the key `licenseKey`. Replace `<your-connectware-license-key>` with your actual license key, `${LICENSE_SECRET_NAME}` with your chosen Secret name, and `${NAMESPACE}` with your target namespace.

{% code lineNumbers="true" %}

```bash
kubectl create secret generic ${LICENSE_SECRET_NAME} \
  --from-literal=licenseKey=<your-connectware-license-key> \
  -n ${NAMESPACE}
```

{% endcode %}

2. Optional: Create the Docker registry Secret to allow your cluster to pull Connectware container images. Replace `${REGISTRY_SECRET_NAME}` with your chosen Secret name. For the Cybus registry, use your Connectware license key as the password and `license` as the username. Skip this step only if you are using a custom registry that does not require authentication. If using a custom registry with authentication, adjust the `--docker-server`, `--docker-username`, and `--docker-password` values accordingly.

{% code lineNumbers="true" %}

```bash
kubectl create secret docker-registry ${REGISTRY_SECRET_NAME} \
  --docker-server=registry.cybus.io \
  --docker-username=license \
  --docker-password=<your-connectware-license-key> \
  -n ${NAMESPACE}
```

{% endcode %}

3. Reference the Secrets in your `values.yaml` file. Replace `${LICENSE_SECRET_NAME}` with your chosen license Secret name. If you completed step 2, also replace `${REGISTRY_SECRET_NAME}` with your chosen registry Secret name. If you skipped step 2, omit the `image.pullSecrets` section.

{% code title="values.yaml" lineNumbers="true" %}

```yaml
global:
  existingLicenseKeySecret: ${LICENSE_SECRET_NAME}
  image:
    pullSecrets:
      - name: ${REGISTRY_SECRET_NAME}
```

{% endcode %}

### Specifying the Broker Cluster Secret

Connectware secures the internal broker cluster using a cluster secret.

{% hint style="warning" %}
Treat the broker cluster secret with the same care as a password. Store it securely and restrict access to authorized personnel only.
{% endhint %}

#### Choosing a Configuration Method

You have the following methods for configuring the broker cluster secret. Choose the method that best fits your security and operational requirements:

* **Method 1 - Auto-generated secret (Recommended)**: Best for most installations. Helm automatically generates a cryptographically secure random value with no configuration required.
* **Method 2 - Plaintext secret in Helm values**: For development/test environments. The secret is visible in your values file, so use only in non-production environments.
* **Method 3 - Existing Kubernetes Secret**: For production environments that use external secret management systems or GitOps workflows.

#### Method 1 - Auto-Generated Secret (Recommended)

For most installations, let Helm automatically generate a secure random secret. This is the simplest and most secure approach for new deployments.

* Leave the broker cluster secret configuration empty in your `values.yaml` file. Helm will generate and store the secret automatically during installation.

{% hint style="info" %}
The auto-generated secret is stored in a Kubernetes Secret and persists across Helm upgrades. You can retrieve it later if needed using `kubectl get secret -n ${NAMESPACE} -l app.kubernetes.io/name=broker-cluster-secret -o yaml`.
{% endhint %}

#### Method 2 - Plaintext Secret in Helm Values

Use this method for development environments or when you need to specify a known secret value for migration or testing purposes.

{% hint style="warning" %}
This method stores the secret in plaintext in your `values.yaml` file. Only use this in non-production environments or ensure your values file is stored securely.
{% endhint %}

* In the `values.yaml` file, specify the broker cluster secret in the Helm value `broker.clusterSecret`:

**Example**

{% code title="values.yaml" lineNumbers="true" %}

```yaml
global:
  licenseKey: cY9HiVZJs8aJHG1NVOiAcrqC_ # example value
broker:
  clusterSecret: Uhoo:RahShie6goh4eid # example value
```

{% endcode %}

#### Method 3 - Existing Kubernetes Secret

Use this method for production environments where you manage secrets through a dedicated secret management system or GitOps workflow.

1. Create the Kubernetes Secret in the same namespace where you will install Connectware. The Secret must contain a key named `clusterSecret` with your secret value. Replace `${SECRET_NAME}` with your chosen Secret name and `your-secret-value` with your actual cluster secret:

**Example**

{% code lineNumbers="true" %}

```bash
kubectl create secret generic ${SECRET_NAME} \
  --from-literal=clusterSecret='your-secret-value' \
  -n ${NAMESPACE}
```

{% endcode %}

2. In the `values.yaml` file, reference the Secret name in the Helm value `broker.existingClusterSecret`:

**Example**

{% code title="values.yaml" lineNumbers="true" %}

```yaml
broker:
  existingClusterSecret: ${SECRET_NAME}
```

{% endcode %}

{% hint style="info" %}
When using an existing Secret, Helm will not create or manage the cluster secret. You are responsible for ensuring the Secret exists before installation and for managing it throughout the lifecycle.
{% endhint %}

### Configuring DNS Names in Helm Values

{% hint style="info" %}
If you are replacing the external Connectware CA certificate chain and manage `cybus_server.crt` manually, ensure that any DNS name with which you address Connectware or individual components is included. You can skip adding them to `global.ingressDNSNames`.
{% endhint %}

To enable external agents to connect to the Connectware Control Plane, you must configure the `global.ingressDNSNames` through Helm values. This setting defines the hostnames that will be included in the Connectware server certificate's (`cybus_server.crt`) Subject Alternative Names (SAN) section.

* Set the `global.ingressDNSNames` list in your Helm values to include all hostnames used for Connectware access.

**Example**

If Connectware is accessible at hostname `company.io`, set the Helm value to:

{% code title="values.yaml" lineNumbers="true" %}

```yaml
global:
  ingressDNSNames:
    - company.io
```

{% endcode %}

#### Hostname Formats

You can include multiple hostnames in the list. The certificate will include all specified names in its SAN section.

The configuration accepts various hostname formats:

* Wildcards (e.g., `*.company.io`)
* Subdomains (e.g., `connectware.company.io`)
* Custom hostnames (e.g., `localhost`)

**Example**

{% code title="values.yaml" lineNumbers="true" %}

```yaml
global:
  ingressDNSNames:
    - company.io
    - localhost
    - *.company.io
    - connectware.company.io
    - 192.168.100.42
```

{% endcode %}

### Specifying the NATS Streaming Server Cluster Replica Count (Optional)

By default, Connectware uses three nodes for the control connection NATS streaming server cluster that is used for inter-service communication.

You may configure an odd number of nodes to suit your environment:

* **Increase the replica count** (e.g., 5) to improve redundancy. With 5 nodes, the redundancy factor increases from N+1 to N+2.
* **Reduce the replica count** (e.g., 1) for lightweight test environments. Note that a single-node setup provides no redundancy.
* Typical production configurations are 3 (default) or 5 nodes.

{% hint style="warning" %}
The `replicas` value is essential for the cluster configuration of the stream server and is shared across many Connectware components.

This setting can only be defined during the initial installation of Connectware and cannot be modified afterward. Do not attempt to scale the `nats` StatefulSet.
{% endhint %}

* In the `values.yaml` file, specify the number of NATS nodes in the Helm value `global.nats.replicas`.

**Example**

{% code title="values.yaml" lineNumbers="true" %}

```yaml
nats:
  replicas: 5
```

{% endcode %}

### Specifying the Broker Cluster Replica Count (Optional)

By default, Connectware uses three nodes for the broker cluster that moves data. You can specify a custom number of broker nodes. For example, increase the broker nodes to handle higher data loads or decrease the broker nodes for a testing environment.

* In the `values.yaml` file, specify the number of broker nodes in the Helm value `broker.replicas`.

**Example**

{% code title="values.yaml" lineNumbers="true" %}

```yaml
broker:
  replicas: 5
```

{% endcode %}

### Specifying Which StorageClass Connectware Should Use (Optional)

A Kubernetes cluster can contain several StorageClasses. You can specify which StorageClass Connectware should use.

* In the `values.yaml` file, specify the StorageClass in the Helm value `global.persistence.storageClassName`.

**Example**

{% code title="values.yaml" lineNumbers="true" %}

```yaml
global:
  persistence:
    storageClassName: gp2 # example value
```

{% endcode %}

There are several configuration parameters to control the StorageClass of each volume that Connectware uses.

### Specifying CPU and Memory Resources (Optional)

By default, Connectware is configured with resource requests only, allowing it to burst and utilize available node resources when needed. To control the CPU and memory available to Connectware, set the Kubernetes `requests` and `limits` values under a component's `resources` Helm value, such as `protocolMapper.resources`.

{% hint style="warning" %}
Adjusting CPU and memory resources can impact the performance and availability of Connectware. When you customize the settings for CPU and memory resources, make sure that you monitor the performance and make adjustments if necessary.
{% endhint %}

For per-chart syntax, defaults, and examples, see [Configuring Compute Resources](/cybus-helm-charts/working-with-cybus-helm-charts/compute-resources.md). For guidance on measuring actual usage and right-sizing these values, see [Right-Sizing Kubernetes Resources for Connectware](/guides/right-sizing-kubernetes-resources.md).

## Installing Connectware

Once you've configured your `values.yaml` file, deploy Connectware to your Kubernetes cluster.

* Run the following command, specifying your installation name and target namespace:

**Example**

{% code lineNumbers="true" %}

```bash
helm install ${INSTALLATION_NAME} oci://repo.cybus.io/charts/connectware --version ${VERSION} -f ./values.yaml -n ${NAMESPACE} --create-namespace
```

{% endcode %}

Replace `${VERSION}` with the chart version from the [Compatibility Matrix](/cybus-helm-charts/compatibility-matrix.md). Omit `--version` to install the latest available chart version.

**Result:** Connectware deploys to your cluster according to your kubectl configuration.

## Verifying the Connectware Installation

Monitor the Connectware installation progress to ensure everything runs smoothly and identify any potential issues.

### Monitoring the Installation Progress

The installation typically takes a few minutes. Choose one of these monitoring options:

* To monitor the current status of the installation process, enter the following command:

{% code lineNumbers="true" %}

```bash
kubectl get pods -n ${NAMESPACE}
```

{% endcode %}

* To monitor the continuous progress of the installation process, enter the following command. This command refreshes every 5 seconds to reflect the current status:

{% code lineNumbers="true" %}

```bash
while [ True ]; do clear; kubectl get pods -n ${NAMESPACE}; sleep 5; done
```

{% endcode %}

* To stop monitoring the continuous progress of the installation process, press <kbd>Ctrl</kbd>+<kbd>C</kbd>.

### Pod Stages During Installation

During the Connectware installation, pods progress through these stages:

* Pending
* PodInitializing
* ContainerCreating
* Init:x/x
* Running

When pods reach `Running` status, they complete their startup process before reporting as ready. All pods must reach `Running` status with all containers ready. This is shown when the READY column displays matching numbers (e.g., `1/1`).

**Example**

{% code lineNumbers="true" %}

```bash
kubectl get pods -n ${NAMESPACE}
```

{% endcode %}

| NAME                                   | READY | STATUS  | RESTARTS | AGE   |
| -------------------------------------- | ----- | ------- | -------- | ----- |
| admin-web-app-7cd8ccfbc5-bvnzx         | 1/1   | Running | 0        | 3h44m |
| auth-server-5b8c899958-f9nl4           | 1/1   | Running | 0        | 3m3s  |
| broker-0                               | 1/1   | Running | 0        | 3h44m |
| broker-1                               | 1/1   | Running | 0        | 2m1s  |
| connectware-ingress-7784b5f4c5-g8krn   | 1/1   | Running | 0        | 21s   |
| container-manager-558d9c4cbf-m82bz     | 1/1   | Running | 0        | 3h44m |
| ingress-controller-6bcf66495c-l5dpk    | 1/1   | Running | 0        | 18s   |
| postgresql-0                           | 1/1   | Running | 0        | 3h44m |
| protocol-mapper-67cfc6c848-qqtx9       | 1/1   | Running | 0        | 3h44m |
| service-manager-f68ccb767-cftps        | 1/1   | Running | 0        | 3h44m |
| system-control-server-58f47c69bf-plzt5 | 1/1   | Running | 0        | 3h44m |
| workbench-5c69654659-qwhgc             | 1/1   | Running | 0        | 15s   |

**Result:** When all pods show `Running` status with matching READY values, Connectware is installed and started. You can now access the [Admin UI](/getting-started/admin-ui.md) for additional configuration or verification.

### Troubleshooting Pod Stages

If a pod is in a different state than expected or if it is stuck at a certain stage for more than three minutes, there might be an issue.

* To investigate the pod status, enter the following command:

{% code lineNumbers="true" %}

```bash
kubectl describe pod ${PODNAME} -n ${NAMESPACE}
```

{% endcode %}

For help on solving issues, see [Troubleshooting Connectware on Kubernetes](/cybus-helm-charts/troubleshooting-on-kubernetes.md).

## Logging Into Connectware for the First Time

Access the [Admin UI](/getting-started/admin-ui.md) through the Kubernetes LoadBalancer Service. In your new Connectware installation, the LoadBalancer is named `connectware`. How to access the LoadBalancer depends on which LoadBalancer provider your cluster offers.

1. Check if your load balancer provider has connected to your Connectware service via the following command:

{% code lineNumbers="true" %}

```bash
kubectl -n ${NAMESPACE} get svc/connectware
```

{% endcode %}

2. Depending on the result, do one of the following:
   1. If your IP address or hostname is displayed in the `EXTERNAL-IP` column, you can access the Admin UI through it.
   2. If no load balancer provider is available in your cluster, you can add an external load balancer.
3. To verify that the installation was successful, enter the following command to forward the service to your local machine through kubectl:

{% code lineNumbers="true" %}

```bash
kubectl -n ${NAMESPACE} port-forward svc/connectware 10443:443
```

{% endcode %}

4. Access the Admin UI at `https://localhost:10443`. Connectware uses its own PKI infrastructure by default.
5. Accept the certificate warning in your browser.
6. Log in with the default credentials:
   * Username: `admin`
   * Password: `admin`

{% hint style="danger" %}
Immediately change the default username and password after your first login.
{% endhint %}

7. To change the username and password, see [Changing Usernames](/documentation/user-management/users.md#changing-usernames) and [Changing User Passwords](/documentation/user-management/users.md#changing-user-passwords).
8. Navigate to **System** > **Status** and verify all components show **Running** status.

**Result:** Your Connectware installation is ready to use.

For more information about LoadBalancer services, see [LoadBalancer (Kubernetes documentation)](https://kubernetes.io/docs/concepts/services-networking/service/#loadbalancer).


---

# 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.cybus.io/documentation/installation-and-upgrades/installing-connectware/installing-connectware-kubernetes.md?ask=<question>&goal=<endgoal>
```

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