Configure a worker
Manage worker capacity, namespaces, scratch limits, local Secrets, and customer-defined egress guardrails.
Loading documentation…
Powered by heyo
Configure the worker in both RestoreTrust and Kubernetes. The worker record controls project assignment and capacity; the generated Deployment carries the cluster-specific settings.
| Setting | Where to manage it | Notes |
|---|---|---|
| Name and description | Worker detail page | Does not restart the agent |
| Max parallel jobs | Worker detail page, then generated Deployment patch | Integer from 1 to 64; the stored and advertised values must match |
| Agent CPU and memory | Generated Deployment profile | Requests and limits follow Max parallel jobs; see CPU and memory |
| Restore Job CPU and memory | Database schedule's Project worker tab | Optional requests and limits for the database container only; blank means BestEffort |
| Agent and job namespaces | Generated install | Must differ and should remain stable for the lifetime of the worker |
| Scratch StorageClass | Generated Deployment | Empty uses the cluster default; each schedule sets the scratch size |
| Source and decryption Secrets | Job namespace | Never create these in the agent namespace |
| Egress CIDR guardrails | Agent Deployment environment | Optional customer policy described below |
The Agent deployment patch on the worker detail page is pre-filled with the namespaces and StorageClass the agent reported at its last connection. If the page says the agent has not reported them (it never connected or runs an older image), enter the values of the running Deployment yourself; the suggested defaults may not match it.
Changing only the worker record or only the Deployment creates a mismatch. Update both.
This capacity setting also selects the agent Pod's resource profile. It does not set requests or limits for the restore Jobs. Configure those on each database schedule if needed; see CPU and memory for workers and Jobs.
Confirm that the cluster can run the new number of restore Jobs and attach the same number of scratch volumes. Update job-namespace quotas first if necessary.
On the worker detail page, edit Max parallel jobs and save the value.
In Agent deployment patch, check the pre-filled agent namespace, job namespace, and StorageClass. Copy the resulting Deployment.
Apply the Deployment. The generated Recreate strategy stops the old Pod before starting the replacement.
In RestoreTrust, verify Online, Accepting jobs: Yes, and the expected advertised and effective capacity.
The worker always refuses source addresses in loopback, link-local, unspecified, and Kubernetes API ranges. Add your own cluster and management ranges to the agent container's environment:
RT_JOB_EGRESS_CLUSTER_CIDRS should contain your Pod and Service networks.RT_JOB_EGRESS_DENY_CIDRS adds ranges a restore must never reach.RT_JOB_EGRESS_ALLOW_CIDRS is optional. When set, every source address outside these ranges is denied.Use comma-separated canonical IPv4 or IPv6 CIDRs. A malformed value prevents the agent from starting. An allowlist cannot override the built-in denied ranges.
A generated Deployment patch contains RestoreTrust-managed settings. Reapply
your approved CIDR environment values when reviewing an upgrade, and use
kubectl diff before applying it.
Create all source credentials and backup-decryption material in the job namespace referenced by RT_K8S_JOB_NAMESPACE. Secret names must match the source and schedule selections in RestoreTrust.
Do not:
restoretrust-worker-identity into the job namespace;restoretrust-job ServiceAccount RBAC or cloud workload identity;If the identity Secret is lost or exposed, create a replacement project worker and move schedules to it.
These commands print configuration names and non-secret values. They do not decode the identity:
Changing namespaces in place is not supported. To move a worker to another namespace pair or cluster, create a replacement worker, install it, reassign schedules, and then uninstall the old worker.