> 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/2-4-1/cybus-helm-charts/connectware-helm-chart/load-balancer.md).

# Configuring the Load Balancer for the connectware Helm Chart

The `connectwareIngress` component is exposed as a Kubernetes Service of type `LoadBalancer` by default. Accessing Connectware from outside the cluster requires a network load balancer, and the specific provider depends on your infrastructure. Use `connectwareIngress.service` to configure how Connectware is exposed.

{% hint style="info" %}

## connectwareIngress vs Kubernetes ingress

`connectwareIngress` is the ingress into Connectware, not a Kubernetes Ingress resource. It is a required internal Connectware component that handles authentication and request routing for all inbound traffic, and cannot be replaced by a Kubernetes Ingress resource.
{% endhint %}

## Load Balancer Requirement

Connectware requires a network (Layer 4) load balancer, not an HTTP ingress controller. The provider depends on where Connectware runs:

* **Cloud-managed clusters** (AWS EKS, Azure AKS, and similar): a load balancer is provisioned automatically when a Service of type `LoadBalancer` is created, provided the appropriate cloud controller is running.
* **Bare-metal or self-managed clusters**: a load balancer controller such as [MetalLB](https://metallb.io) must be installed separately before deploying Connectware.

The `connectwareIngress.service.type` value defaults to `LoadBalancer` and does not need to be changed. If you want to use a different setup, configure and test it thoroughly before using it in production.

## Configuring Access from Outside the Cluster

How you configure access to Connectware from outside your cluster depends on your infrastructure. Use `connectwareIngress.service.annotations` to pass provider-specific configuration to your load balancer controller.

### AWS EKS

The following example provisions an internet-facing Network Load Balancer (NLB) using the [AWS Load Balancer Controller](https://kubernetes-sigs.github.io/aws-load-balancer-controller/):

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

```yaml
connectwareIngress:
  service:
    annotations:
      service.beta.kubernetes.io/aws-load-balancer-type: 'external'
      service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: 'ip'
      service.beta.kubernetes.io/aws-load-balancer-scheme: 'internet-facing'
```

{% endcode %}

The AWS Load Balancer Controller must be installed in the cluster for these annotations to take effect. Refer to the [AWS Load Balancer Controller documentation](https://kubernetes-sigs.github.io/aws-load-balancer-controller/) for installation instructions and the full list of supported annotations.

### MetalLB

The following example assigns an IP address from a named MetalLB address pool:

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

```yaml
connectwareIngress:
  service:
    annotations:
      metallb.universe.tf/address-pool: '${ADDRESS_POOL_NAME}'
```

{% endcode %}

Replace `${ADDRESS_POOL_NAME}` with the name of the MetalLB `IPAddressPool` configured in your cluster. MetalLB must be installed and at least one address pool must be configured before deploying Connectware. Refer to the [MetalLB documentation](https://metallb.io/configuration/) for installation and pool configuration instructions.

### Azure AKS

On AKS, the cloud controller automatically provisions a public Azure Load Balancer for Services of type `LoadBalancer`. To use an internal load balancer instead (private to your virtual network), add the following annotation:

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

```yaml
connectwareIngress:
  service:
    annotations:
      service.beta.kubernetes.io/azure-load-balancer-internal: 'true'
```

{% endcode %}

Refer to the [AKS internal load balancer documentation](https://learn.microsoft.com/en-us/azure/aks/internal-lb) for additional configuration options.

## Configuring Exposed Ports

The `connectwareIngress.service.ports` list controls which ports are exposed on the load balancer. The following ports are enabled by default:

| Port   | Purpose                                         |
| ------ | ----------------------------------------------- |
| `80`   | Admin UI and REST API (HTTP)                    |
| `443`  | Admin UI and REST API (HTTPS)                   |
| `1883` | MQTT (unencrypted)                              |
| `4222` | NATS                                            |
| `4223` | NATS over WebSocket (secure)                    |
| `4841` | OPC UA Server                                   |
| `8443` | Admin UI and REST API (HTTPS, alternative port) |
| `8883` | MQTT over TLS (MQTTS)                           |

To remove a port, delete its entry from `connectwareIngress.service.ports`. To expose an additional port, add a new entry to the list. A common case is to make a `Cybus::IngressRoute` reachable from outside the cluster: `Cybus::IngressRoute` forwards traffic from the load balancer to a container running inside Connectware, and only ports in the `40000`–`40100` range can be used as the `connectwarePort`.

The following example removes the unencrypted MQTT port `1883` so that external clients can only connect over TLS on port `8883`, and adds port `40000` to match the `connectwarePort` of a `Cybus::IngressRoute` resource:

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

```yaml
connectwareIngress:
  service:
    ports:
      - name: 'nats-wss'
        port: 4223
        targetPort: 4223
      - name: 'nats'
        port: 4222
        targetPort: 4222
      - name: '8883'
        port: 8883
        targetPort: 8883
      - name: '443'
        port: 443
        targetPort: 8443
      - name: '80'
        port: 80
        targetPort: 8081
      - name: '8443'
        port: 8443
        targetPort: 8443
      - name: '4841'
        port: 4841
        targetPort: 4841
      - name: 'ingressroute-40000'
        port: 40000
        targetPort: 40000
```

{% endcode %}

{% hint style="info" %}
When you override `connectwareIngress.service.ports`, you must list every port you want to expose. The override replaces the entire default list.
{% endhint %}

For more information on TCP ingress routes, see [Cybus::IngressRoute](/2-4-1/documentation/services/service-commissioning-files/resources/cybus-ingressroute.md).

## Applying Configuration Changes

After editing your `values.yaml` file, apply the changes by running the `helm upgrade` command. For details, see [Applying Helm Configuration Changes](/2-4-1/cybus-helm-charts/working-with-cybus-helm-charts.md#applying-helm-configuration-changes).


---

# 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/2-4-1/cybus-helm-charts/connectware-helm-chart/load-balancer.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.