Worker

A Worker is an identity in ConfigHub, and optionally a process that runs in your infrastructure and connects to ConfigHub.

Those are two distinct things, and most Workers are only the first.

A Worker as an identity

Every Worker has its own user identity and credentials — a worker ID and a secret, a little like an API key that can be exchanged for a standard authentication token. Anything that needs to talk to ConfigHub without a human logging in uses one: CI jobs, event consumers, scripts, and ordinary API clients using ConfigHub's main HTTP API.

No running process is needed to use a Worker this way. Creating the Worker creates the identity; nothing has to connect.

cub worker create --space platform-dev deploy-bot
cub worker get-envs --space platform-dev deploy-bot

Because a Worker is a first-class entity with its own permissions, you can grant it exactly the access a given automation needs, and see what it did — its actions are attributed to it rather than to whoever set it up.

Workers marked as server workers (ProvidedInfo.IsServerWorker) are hosted inside ConfigHub itself rather than run by you. These are what back Targets with ProviderType OCI, which is how configuration is published to the OCI endpoint. cub cluster up creates one for you.

A Worker as a process

The second sense is a process you run that maintains a connection to ConfigHub. There is now exactly one reason to do this: executing functions that you have written yourself.

Custom functions let you extend ConfigHub with logic that has no limit on programming language, libraries, or computational cost — validating against your own policy engine, deriving values from systems only you can reach, or anything else built-in functions cannot express. The function runs in your environment, with your credentials and your network access. ConfigHub routes the call to the Worker hosting the implementation and receives the result back.

This is optional. If you only use built-in functions, you never need to run a Worker process.

The connection is initiated by the Worker and kept alive via either HTTP long polling or HTTP2, so ConfigHub can reach it even when it sits behind a firewall. See the guide for how to create, run, and manage one, and custom function workers for building your own.

Sunset: Workers as Infrastructure Bridges

Workers used to host bridges — the mechanism by which ConfigHub reached into a Kubernetes cluster or other system to apply, destroy, refresh, and import configuration. That mechanism has been removed.

Configuration now reaches live infrastructure by being published: ConfigHub serves an immutable bundle over OCI, and a GitOps operator running in your cluster pulls it. Nothing is pushed, so no Worker stands between ConfigHub and your infrastructure, and ConfigHub never holds credentials to it.

A legacy name

The API type is still called BridgeWorker, and some CLI help text still says "bridge worker" — for example cub worker explain reports "Explain BridgeWorker fields". These names predate the change and are kept for compatibility; renaming them is a breaking API change. Wherever you see BridgeWorker in the API or CLI, read it as Worker.