Flux Bridge

ConfigHub bridge to integrate with FluxCD using external artifacts.

Status: no longer functional — retained for reference.

The bridge worker protocol has been removed from ConfigHub. Custom bridges can no longer be built or run, and the cub unit apply step this bridge depends on no longer exists.

Configuration now reaches a cluster by being published as an immutable OCI Release that a GitOps operator pulls directly. For the current Flux integration — an OCIRepository plus a Kustomization pointing at a Space's release URL — see Integrating with GitOps operators.

The walkthrough that used to live at docs.confighub.com/get-started/examples/flux-bridge/ has been removed; its explanatory content is preserved below.

What this was

A Bridge was a piece of software that connected ConfigHub to live resources in Kubernetes, AWS, Azure, GCP, or other systems. Bridges translated ConfigHub operations — Apply, Destroy, Refresh, Import — into the appropriate API calls for the target platform. They ran inside Workers, which handled all communication with ConfigHub.

ConfigHub provided a standard Worker with built-in bridges for common platforms like the Kubernetes API. You could also build custom bridges for specialised integrations — like this one.

Why Flux with ConfigHub

The standard ConfigHub worker applied configuration directly to the Kubernetes API. The Flux Bridge took a different approach: instead of applying resources directly, it created Flux ExternalArtifact resources pointing at ConfigHub units, and let Flux handle the actual reconciliation. That gave you:

• Flux's reconciliation model — Flux continuously reconciles the desired state, automatically correcting drift
• ConfigHub's configuration management — hierarchical config, clone upgrades, bulk operations, and change tracking
• Unified tooling — teams already using Flux could adopt ConfigHub without changing their deployment model

Note that the current OCI Release model achieves the same goal by a simpler route: Flux pulls a published bundle straight from ConfigHub's OCI endpoint, with no bridge and no worker in between.

How it worked

1. You manage configuration in ConfigHub units as usual
2. When you apply a unit, the Flux Bridge creates an ExternalArtifact resource pointing to the unit's configuration
3. The Flux Bridge also creates a Kustomization resource that references the ExternalArtifact
4. Flux's kustomize-controller fetches the configuration from the artifact and applies it to the cluster
5. Flux continuously reconciles, ensuring the cluster matches the desired state

graph LR
    ConfigHub -->|manages| Unit
    Unit -->|apply via| FluxBridge[Flux Bridge]
    FluxBridge -->|creates| EA[ExternalArtifact]
    FluxBridge -->|creates| Kustomization
    Kustomization -->|references| EA
    EA -->|points to| Unit
    Flux[Flux Controller] -->|fetches from| EA
    Flux -->|reconciles| Cluster

Loading

Installation

These instructions used a local kind cluster; they adapt easily to a cluster of your own. The Flux Bridge configuration is hosted in this repository, so there is nothing else to clone.

Create a cluster

kind create cluster --name flux-bridge-dev

Install Flux

Install Flux v2.7.0 or greater:

flux install

Enable the ExternalArtifact feature

The ExternalArtifact source controller is behind a feature flag, so it has to be enabled:

kubectl -n flux-system patch deployment kustomize-controller \
    --type='json' \
    -p='[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", "value": "--feature-gates=ExternalArtifact=true"}]'

Deploy the Flux Bridge configuration

Create the Flux Bridge custom worker config in ConfigHub from the base config in this repository:

cub unit create flux-bridge-config \
    https://raw.githubusercontent.com/confighub/flux-bridge/refs/heads/main/manifests/base.yaml

Then apply it to the cluster:

cub unit data flux-bridge-config | kubectl apply -f -

You could apply the worker manifests directly instead, but storing them in ConfigHub gave you the same benefits as any other configuration: revision history, rollback, cloning and customising per environment, and bulk operations across clusters.

Create the Worker entity

cub worker create flux-bridge

Install the Worker secret

cub worker install flux-bridge --export-secret-only | kubectl apply -f -

The Flux Bridge worker config depends on this secret and will not reconcile until it is applied. Once applied, the worker boots and connects to ConfigHub.

Verify the connection

cub worker list

Expected output:

NAME           CONDITION       SPACE          LAST-SEEN
flux-bridge    Ready           default        2025-10-31 20:37:53

Demo: deploy a Helm chart via Flux Bridge

Using the reloader Helm chart as an example.

Render the Helm chart into ConfigHub

cub helm install reloader stakater/reloader \
    --repo https://stakater.github.io/stakater-charts \
    --namespace reloader

This rendered the chart into the base space reloader-base, one unit per chart file. See Using Helm Charts with ConfigHub for how cub helm install maps a chart to a component. For this demo the base units were deployed directly rather than creating a separate deployment variant.

Set the target to the Flux Bridge

cub unit set-target flux-bridge --space reloader-base --where "Labels.HelmRelease = 'reloader'"

Apply the units

cub unit apply --space reloader-base --where "Labels.HelmRelease = 'reloader'"

Verify

cub unit list --space reloader-base
kubectl get kustomizations -A

Kustomizations appear for the reloader units, and Flux reconciles them to the cluster.

Development

The following dependencies are required to setup the local dev environment.

• cub
• kind
• kubectl
• flux
• docker

Start off with creating a worker for the bridge.

cub worker create flux-bridge

Running dev deploy will create a Kind cluster with Flux installed along with a local build of the flux-bridge. It will also get the worker secret from ConfigHub and create a secret in the cluster.

make dev-deploy

After the setup has run successfully the bridge should be deployed in the confighub namespace.

kubectl -n confighub get pods