Local worker
The process you run so that credentials and plaintext never leave your network.
View as MarkdownThe worker is the half of saved.sh that runs on your hardware. It connects to your sources, produces the artifact, encrypts it, and uploads ciphertext. We schedule it and record what it did; we never see what it saw.
Everything a local backup needs to touch your data lives on your machine: the source credentials, the plaintext dump, and the private half of your encryption key. What crosses the boundary is an encrypted file and a handful of numbers.
What the worker is
A worker is a credential, not a machine. Provisioning one creates an ID and a key. The key is what lets a process claim work in your workspace, and the ID is what a backup points at when you say where it should run.
That has three consequences worth knowing up front:
- Reinstalling the binary, moving it to a new host, or changing its IP does not change the worker. Nothing re-registers.
- Rotating the key does not touch the ID, so backups assigned to that worker keep working once the new key is in place.
- Deleting the worker is not the same as rotating it. Deletion revokes the key permanently and leaves any backup assigned to it with nowhere to run.
Run one process per worker credential. Several processes may share one, and they will all poll the same queue, but a run's steps hand each other a path to a file on local disk. Split those steps across two machines and the second one looks for a file that is not there. If you need more throughput, provision a second worker.
What a run actually does
Every source type runs the same six steps. Only the first one differs.
Dump<Type> → Compress → Encrypt → Checksum → Upload → Discard| Step | What happens | Where the bytes are |
|---|---|---|
| Dump | Shell out to pg_dump, mysqldump or curl, or read your redis, disk or bucket directly | A scratch file on your host |
| Compress | gzip, if this backup asked for it | Still your host |
| Encrypt | OpenPGP to the public key in your config | Another scratch file on your host |
| Checksum | SHA-256 over the uploaded file, plus its size | Still your host |
| Upload | PUT to a presigned URL, then confirm to our API | Ciphertext leaves; nothing else does |
| Discard | Remove every scratch file, even when the run failed | Nothing remains |
Each step retries on its own, so a failed upload retries the transfer rather than re-running a six-hour dump. The steps hand each other a path, never the data, so the bytes never enter our orchestration at all.
What it needs from the host
| Requirement | Detail |
|---|---|
| Outbound network | The worker dials out. Nothing dials in, and no port needs opening |
| Disk | Room for the dump and its encrypted copy at the same time, so budget roughly twice the dump size |
| Tools | pg_dump, mysqldump or curl, but only for the source types you actually use. redis needs none |
| Reachability | A route to the sources themselves, which is the whole reason it runs where it does |
Next
Install
Binary or container, on the host that can reach your sources.
Registration
Provisioning the credential, and what it is allowed to do.
Configuration
The config file, the sources it serves, and every key it accepts.
Lifecycle
How work is claimed, executed and reported.
What stays local
Exactly which bytes leave your network.
Troubleshooting
What to look at when runs stop happening.