Deploy BindPlane OP Server

Install BindPlane OP server on Kubernetes


Operating BindPlane on Kubernetes is currently a beta feature. Expect configuration syntax to change.


Deployment Types


BindPlane OP can operates as a single pod StatefulSet by default, when using the default bboltstorage backend. In this configuration, a persistent volume claim is utilized to persist data between pod restarts and upgrades.

This architecture is not highly available, meaning there will be brief downtime when the BindPlane OP pod is restarted due to updates. All managed agents will re-connect automatically. Managed agents will continue to function without downtime, while BindPlane OP is unavailable.

BindPlane OP Open Source and Enterprise editions support running as a Statefulset.

Highly Available Deployment (Enterprise)

The Enterprise edition of BindPlane OP supports operating as a highly available deployment with multiple pod replicas. Persistent storage is handled using a shared database and an external event bus such as Google's PubSub.

Official support for high availability deployments is coming soon.


An ingress rule is used to provide external access to the cluster for Web browser interaction and management of external agents running outside of the cluster.

Ingress is optional. Omitting the ingress deployment will impose the following restrictions:

  • Web browser interaction will rely on the kubectl port-forward command, for exposing BindPlane to your workstation.
  • Only agents running within the cluster will be managed.


The following Kubernetes resources are created when installing BindPlane OP using a minimal configuration.

  • Service account: Service account without additional RBAC as BindPlane OP does not require permission to the cluster.
  • Service (clusterIP): For client communication.
  • StatefulSet or Deployment

Advanced configurations may result in additional resources being deployed, such as ingress or horizontal pod autoscaler resources.


Supported Distributions

The following Kubernetes distributions are officially supported:

  • Google Kubernetes Engine (GKE)
  • Amazon Elastic Kubernetes Service (EKS)
  • Azure Kubernetes Service (AKS)
  • OpenShift 4.x

System Requirements

  • Storage class which supports persistent volume claims (When running as a StatefulSet).
  • Sufficient CPU and Memory capacity.
    • 250m CPU and 250Mi Memory are requested by default. It is recommended that these values be increased.
    • See the instance sizing guidelines for recommended CPU and memory capacity.
  • Ingress (optional) if managing agents outside of the cluster.

Install and Upgrade


The BindPlane OP Helm Chart can be used to deploy BindPlane OP to your Kubernetes Cluster.

Add Repository

Add the BindPlane OP chart to your Helm installation with the following commands:

helm repo add "bindplane" \

helm repo update



Create a values.yaml file and add the following options:

  • config.username: The username you would like to use for BindPlane's super user.
  • config.password: The password you would like to use for BindPlane's super user.
  • config.secret_key: A new random UUIDv4 to use for securing communication between BindPlane and managed agents.
  • config.sessions_secret: A new random UUIDv4 to use for generating web interface session cookies.

The values.yaml file should look something like this, with unique values specific to your deployment.

  username: "admin"
  password: "admin"
  secret_key: "13c15d7c-233e-49e3-bef4-f7498f33518f"
  sessions_secret: "a4e5aa85-5df4-4edd-8cfe-d8a7257d09dd"

You can find a full list of supported configuration options in the here .


Deploy BindPlane OP with your values.yaml configuration using the helm upgrade command, which is suitable for installing new deployments and upgrading existing deployments.

helm upgrade --install "bindplane" \
    --values "values.yaml" \
    --namespace bindplane \
    --create-namespace \

Helm will deploy or upgrade BindPlane OP in the namespace bindplane using the configuration specified in your values.yaml file.

Upgrade BindPlane OP

BindPlane OP can be upgraded by updating by updating your local Helm and then re-deploying with the helm upgrade command.

The helm search repo bindplane command can be used to display the chart and application version.

helm repo update
helm upgrade --install"bindplane" \
    --values "values.yaml" \
    --namespace bindplane \
    --create-namespace \

Kubernetes Manifest

Users who wish to avoid deploying BindPlane OP with Helm can do so by generating their manifest with the helm templatecommand.


helm template "bindplane" --values values.yaml bindplane/bindplane > bindplane.yaml
kubectl apply -f bindplane.yaml

The output of helm template can be saved to a file and deployed with kubectl.


BindPlane OP can be upgraded by modifying the image tag and re-deploying with kubectl

  - name: server

Access BindPlane OP

By default, BindPlane OP is deployed without ingress. This means:

  • Port forwarding is used for access
  • BindPlane can only manage agents in the cluster.

To access BindPlane, run the following command.

kubectl -n bindplane port-forward svc bindplane 3001

This command assumes that BindPlane was deployed to the bindplane namespace and the clusterIP service's name is bindplane.

Once port forwarding is running, you can access BindPlane with your browser at http://localhost:3001.


BindPlane OP's Helm chart supports ingress. When ingress is configured, BindPlane can be accessed without port forwarding, and agents from outside of the cluster can be managed.

See the Production Example section of this doc for instructions on configuring ingress.

Production Example

This section provides an example configuration for production grade deployments of BindPlane OP on Kubernetes.

This example deploys BindPlane OP server to Google Kubernetes Engine (GKE) as a StatefulSet with ingress and transport layer security (TLS). The steps shown here can be adapted to work on any Kubernetes cluster.


  • Ingress: Managed agents and web browsers will connect to BindPlane through an ingress service.
    • This example assumes you would like to manage agents which are running outside of the cluster.
    • Ingress is optional if you would like to manage agents which are internal to the cluster.
  • DNS: You must create a DNS record for the ingress hostname
  • Storage class which supports persistent volumes: BindPlane OP relies a volumeClaimTemplate for persistent storage


Create a values.yaml file based on this example:

  username: "admin"
  password: "admin"
  secret_key: "1b66fdab-dc7c-4316-872c-e3556f326103"
  sessions_secret: "1b66fdab-dc7c-4316-872c-e3556f326103"
  server_url: ""
  remote_url: "ws://"

    volumeSize: "120Gi"

    cpu: "500m"
    memory: "1024Mi"
    memory: "1024Mi"

  enable: true
  host: ""
  class: "gce"

Modify this example

  • Set a secure value for config.username
  • Set a secure value for config.password
  • Replace config.secret_key and sessions_secret with new and random UUIDv4 values.
  • Update ingress.hostto your desired hostname.
    • You must have DNS access for this domain
    • Once BindPlane is deployed, you will need to manually create a DNS record if you do not have automatic DNS provided by a service such as External DNS.
  • Set config.server_url and config.remote_url to match your value.
    • Example: If is set to ""
  • Optionally update ingress.class if you wish to use a different ingress class. GKE has the GCE ingress class by default.


Deploy to the namespace bindplane and name the Helm deployment bindplane.

helm upgrade --install "bindplane" \
    --namespace "bindplane" \
    --create-namespace \
    --values "values.gke.yaml" \

Once deployed, the following will be present in the bindplane namespace:

  • StatefulSet named bindplane (One pod)
  • Service named bindplane with port 3001
  • Persistent volume named bindplane-data-bindplane-0
  • Ingress named bindplane


Once BindPlane has been deployed, the GKE cluster will deploy a load balancer for the ingress object. This process will take a few minutes.

DNS must be configured properly for your browser and managed agents to connect to BindPlane using the ingress hostname.

Once the load balancer is deployed, you can check its IP address with kubectl -n bindplane get ingress

NAME        CLASS    HOSTS                       ADDRESS          PORTS   AGE
bindplane   <none>   80      12m

You will need to create a DNS record for your hostname, pointing to the IP address that is bound to the load balancer. You can do this two ways

  1. Using your domain hosting provider's DNS portal
  2. Using automation with tools such as External DNS

Install Agents

After deploying BindPlane and configuring DNS, you can navigate to your ingress hostname and login using the username and password defined in your Helm values file.

Linux / Windows

Linux and Windows agents can be installed using the "Install Agents" option on the Agents page.

Ensure that the agent install command includes the correct hostname. In this example, we expect the install command to use ws:// This is derived from the config.remote_urlHelm option. It is the endpoint used by agents to connect to BindPlane using the OpAMP protocol.

Copy and run the install command on your agent system. Once installed, the agent will become available on the Agents page.


Kubernetes based agents can be installed within the same cluster as BindPlane, or a seperate cluster. In both scenarios, the ingress hostname will be used for connectivity.

Deploy a Kubernetes agent with the following steps:

  1. Create a Kubernetes configuration on the Configs page.
  2. Choose "Install Agents" on the Agents page

The agent install page will present a Kubernetes YAML manifest. Copy this manifest to a file and ensure that the environment variable OPAMP_ENDPOINTvalue is derived from the config.remote_urlvalue set in your Helm values file. Additionally, the OPAMP_SECRET_KEY should match the value used for config.secret_key.

In this example, the environment configuration looks like this:

  - name: "OPAMP_ENDPOINT"
    value: "ws://"
  - name: "OPAMP_SECRET_KEY"
    value: "13c15d7c-233e-49e3-bef4-f7498f33518f"

Apply the manifest to your cluster with kubectl apply -f <file name>.

After a few moments, your agents will appear in on the Agents page.

Ingress Transport Layer Security (TLS)

The BindPlane OP Helm chart supports configuring the ingress rule to use TLS.


Create a secret named "bindplane-tls" and add your TLS certificate to it. This secret must be created in the same namespace that BindPlane is deployed to.

Update your Helm values configuration with the following changes

  • config.server_url should contain https and port 443
  • config.remote_url should contain wss and port 443
  • ingress.tls.enable should be set to true
  • ingress.tls.secret should be set to the name of the TLS secret
+  server_url: ""
+  remote_url: "wss://"
  enable: true
  class: gce
+ tls:
+   enable: true
+   secret: bindplane-tls

You can re-deploy BindPlane using the same Helm command used for initial deployment.

Update Existing Agents

Agents which were previously connected to BindPlane without TLS will need to be updated. This guide assumes that the certificate used for BindPlane's ingress is trusted by all agent systems.

Linux / Windows

Update the agent's manager.yaml. The manager configuration can be found in /opt/observiq-otel-collector on Linux and observIQ OpenTelemetry Collectoron Windows.

Update the endpoint parameter to use wss and port 443.

#endpoint: "ws://"
endpoint: "wss://"
secret_key: "13c15d7c-233e-49e3-bef4-f7498f33518f"
agent_id: "01GYWP11HNTHDQNB2MAM2FH7HW"

Once updated, restart the collector service.


Kubernetes agents can be updated to use TLS with the following steps.

  1. Navigate to the Agents page and select "Install Agents"
  2. Choose the Kubernetes platform and configuration for your agents
  3. Copy the YAML manifest to a file and apply it with kubectl apply.

The YAML manifest generated by the BindPlane web interface will include an updated value fro the OPAMP_ENDPOINT environment variable.

TLS External Documentation