Workers
Provisioning, rotating and retiring worker credentials.
View as MarkdownA worker is a credential, not a machine. These commands manage the credential; installing and running the process is separate.
Provisioning
sctl worker provision prod-worker-1Provisioned worker "prod-worker-1" (0f2c9a1e-...).
Key (copy now, not shown again):
sk_live_...The key is shown once and is not recoverable. It goes into that machine's config.yaml
as token. If you lose it, rotate rather than deleting the worker.
Names are 1 to 100 characters and are for you. The ID is what backups reference.
Listing
sctl worker listNAME ID CREATED UPDATED
prod-worker-1 0f2c9a1e-... 2026-08-08T09:14:02Z 2026-08-08T09:14:02ZThis is where you get the worker ID that sctl backup configure --worker needs.
WORKER_ID=$(sctl worker list | awk '$1 == "prod-worker-1" { print $2 }')
sctl backup configure "$BACKUP_ID" --worker "$WORKER_ID"The dashboard additionally shows how many processes are polling and when each was last seen. Read those as "connected is trustworthy, disconnected lags by minutes": poller records expire on a TTL, so a worker that died thirty seconds ago can still look present.
Rotating
sctl worker rotate <worker-id>Rotated worker "prod-worker-1" (0f2c9a1e-...).
New key (copy now, not shown again):
sk_live_...Rotation keeps the worker ID, so every backup assigned to it keeps working once the new key is deployed. This is the answer to almost everything: a leaked key, a decommissioned host, an employee who had access to the config file, or ordinary hygiene.
The order that minimises the gap:
sctl worker rotate <worker-id>- Write the new key into that machine's
config.yaml - Restart the worker
The old key is revoked the moment the new one is issued. Any process still holding it stops being able to poll, so expect a short gap. A run already in flight is retried when the worker returns, because the run belongs to the queue rather than to the connection.
Deleting
sctl worker delete <worker-id>Deletion revokes the key permanently and removes the worker. Backups assigned to it are left with nowhere to run: their scheduled runs queue on a task queue nothing polls.
rotate | delete | |
|---|---|---|
| Worker ID | Unchanged | Gone |
| Old key | Revoked | Revoked |
| New key | Printed once | There is none |
| Assigned backups | Keep working | Have nowhere to run |
Reassign or pause those backups before deleting the worker they point at.
What the key can do
Two permissions: artifacts:upload and artifacts:confirm. It cannot read backup definitions,
list artifacts, download anything, or manage workers, including itself.
That narrowness is why a worker is safe to run on a machine you would not trust with an API key. The real risk on that host is the config file, which holds your source credentials. Protect the file, not just the key.
Limits
| Plan | Workers per workspace |
|---|---|
| Trial | 1 |
| Paid | 10 |