Project workers

A project worker runs checks in a Kubernetes cluster you control. Its agent creates and supervises temporary restore Jobs; Kubernetes injects the referenced Secrets into the download container. The agent does not fetch Secret values through the Kubernetes API. The Jobs download and validate backups, and the agent reports results to its RestoreTrust project.

One worker belongs to one project. A schedule selects the worker that will run its checks.

Create a worker

1. 1

   Add the worker

   In the active project, open Project workers and choose Create. Enter a recognizable name, optional description, and the country where the worker operates.

2. 2

   Set maximum parallel jobs

   Choose how many checks this worker may run at once. Account for database memory and CPU, scratch storage, source connection limits, and the effect of simultaneous large downloads. This is a capacity ceiling, not a promise that every slot is always available.

3. 3

   Install in Kubernetes

   Review the generated configuration, choose the installation settings, and apply the manifests to the intended cluster. Follow the Kubernetes installation guide for the exact commands and current cluster requirements.

4. 4

   Verify the connection

   Return to the worker page and wait for Online. If it remains offline, verify that the installation succeeded and that the cluster can resolve and establish outbound TLS to the generated worker endpoint.

Prepare the worker for checks

• Create each required Kubernetes Secret in the worker's job namespace, not its agent namespace.
• Repeat the Secret in every worker job namespace that can be selected by a schedule.
• Allow the job environment to reach the source host and port.
• Ensure the storage class and available capacity can hold the decoded artifact and restored database.
• Set each schedule's scratch volume size; it is required and the worker has no default.

Operate safely

Use dedicated worker capacity for important restore validation. Lower the parallel-jobs limit if checks compete for memory, storage, network bandwidth, or connections to the backup source. Paused schedules do not dispatch checks, and a manual run still needs a connected worker with available capacity.

The generated agent has requests and limits chosen from the parallel-jobs value. Restore Jobs have no CPU or memory requests or limits by default; database schedules can add them for the database container. Plan capacity for both the agent and the Jobs, especially when several checks can run together. See CPU and memory for workers and Jobs.

Plan changes can affect worker availability or pause worker-backed schedules. Review the impact shown before confirming a plan change.

The worker list and detail page also show the agent's image digest and whether an update is available or required. Updates are applied manually in your cluster; a required update blocks new checks.