Your system is not on anyone’s connector list
Every backup vendor advertises a number. The number is a list of things somebody else decided were important, and the interesting question is what happens to the one you actually need. Here it is a command.
$ your-command | saved backup submit anything -Things people back up that nobody wrote a connector for
A SaaS you rent
vendor CLI, nightly export
vendor-cli export --all --format=json \ | saved backup submit vendor-crm -
A legacy system
the one with only a CLI
erp-tool dump --tables=all --out="$SAVED_OUTPUT"
MySQL, today
before the connector ships
mysqldump --single-transaction "$DB" \ | saved backup submit billing-mysql -
A container volume
whatever is inside it
docker run --rm -v app_data:/d alpine \ tar -cf - /d | saved backup submit app-vol -
A generated report
an hour to produce, worth keeping
./build-quarterly-report.sh > "$SAVED_OUTPUT"
Anything at all
the general case
# if it writes bytes and exits zero, # it is a backup your-command | saved backup submit thing -
A script source is a first-class source
This is the part that usually is not true elsewhere. A custom command is not an escape hatch with fewer features; the artifact it produces is indistinguishable from one a connector produced.
Encrypted
Your key, applied before the bytes leave the machine.
Verified
Checksummed and sized at seal time, recorded on the run.
Retained
Same policy model, including a hold that cannot be shortened.
Restorable by hand
Standard compression and encryption, documented, no vendor needed.
Write to the output path, not to stdout
On the worker path we hand your script a path in $SAVED_OUTPUT and it writes its artifact there. Standard output becomes the run log instead.
That is not a style preference. Tools write progress bars, deprecation warnings and version banners to stdout, and any one of them silently corrupts a stream you were treating as the artifact. Separating them means a chatty tool produces a readable log rather than an unopenable backup.
backup-legacy.sh
#!/usr/bin/env bash set -euo pipefail echo "starting export" # log legacy-tool export --all \ --out "$SAVED_OUTPUT" # artifact echo "done" # log
On the push path there is no such split: you pipe bytes to the CLI and stdout is the artifact, because you chose what to put in it.
The same output, whatever produced it
$ pg_dump $DATABASE_URL | saved backup submit prod-db -reading stdinencrypting to 9F2A…C410 (your key)uploading 4.21 GB ████████████████████ 100%sealing sha256:7c1e…8b03✓ run_01JQ8F3K2M sealed, locked until 2026-11-02$ saved run list --backup prod-db --limit 303:12 ✓ 4.21 GB 00:03:1202:00 ✓ 4.19 GB 00:03:0401:00 ✓ 4.19 GB 00:03:09
No agent. No inbound port. Ten lines of output you can read.
Where this does not fit
Scripts never run on our infrastructure
Sandboxing arbitrary customer code is a class of problem we would rather not own, and saying so is more honest than a restricted runtime that eventually leaks. Script sources are local-only, permanently.
Exit code is the contract
We know a run succeeded because the command said so. A tool that exits zero having written nothing produces an empty artifact. The recorded size makes that visible the next morning; it does not prevent it.
You own the command
If a vendor changes their export format, that is yours to notice. We verify the bytes arrived intact, not that they mean what you expect.
The same as whichever path you run it on
A script on your worker generates no computation on our side, and neither does one in your own CI. There is no premium for using a source we did not write, because from our side it is the same upload.
What you need
- A command that produces a file and exits zero
- A worker on your hardware, or your own automation
- A GPG public key uploaded to the workspace
No approval, no request queue and no waiting for a connector. This is the reason we are relaxed about shipping a short list.