Worker

Workers are deprecated

Use a ServiceAccount as the identity for automation, and a Channel to consume events and to receive commands; see command bots. Existing Workers keep working. A Worker is still required to serve external functions until functions move to Channels.

A Worker is an identity in ConfigHub, similar to the concept of service accounts you will find in many platforms, but with some additional capabilities such as being an event consumer and an external function executor.

A Worker as an identity

As an identity, you can use a worker more or less exactly like you might use service accounts and access tokens in other platforms. You use the worker's credentials to authenticate to the API and perform any permitted action. The worker's permissions are controlled like any other user's.

Unlike human users, a worker can authenticate with an asymmetric key pair which enables workers to refresh the short lived access token without human intervention and thus stay connected continuously.

Common use cases for workers as identities are CI jobs and other automations that operate without a human involved. This can include AI agents that operate under their own identities (as opposed to on behalf of a human user).

A Worker as a function executor

Workers are also used for external function execution. You build an external function executor and host it in your infrastructure. You connect to ConfigHub using the worker credentials and register the offered functions under that worker. This allows you to execute those functions with commands like cub function do ... by naming that worker with --worker.

The connection is initiated by your client program over HTTP long polling on the normal API port, so ConfigHub can reach it even when it sits behind a firewall. See external functions for building and running one, and the workers guide for creating and managing the identity.

A Worker as an event consumer

Finally, you can also use workers to consume events. In this case, you write your own code for event consumption, host it in your infrastructure, and then you connect to ConfigHub on the event consumption endpoint using your worker credentials and subscribe to events. Similar to function execution, this is an HTTP long polling protocol, so ConfigHub can route events to you as they occur.

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.