Backups your attacker can’t reach
Push a backup from any automation you already run. It is encrypted with your key before it leaves your machine, so a breach of ours is a pile of ciphertext. Want it scheduled and executed too? Add a worker when you are ready.
No card required. USD 50 credit on every new workspace.
We are designed to be useless to whoever breaks into us
Your data is encrypted with your public key, on the machine that produced it, before a single byte reaches us. We hold public keys only. Take our database, take our buckets, take everything we own, and you have ciphertext and a list of file sizes. This is not a promise about our security practices. It is an arrangement that does not depend on them.
Your key, your side of the line
You upload a public key. The private half never leaves your machine, and there is no recovery path through us, because there is nothing for us to recover with.
Encrypted before it moves
Encryption happens where the data is produced, not on arrival. The bytes are already unreadable when they cross the network, and they stay that way at rest.
Sealed under a retention lock
You set a hold, and from then on nobody can shorten or remove it: not a support request, not an attacker with your saved.sh credentials, and not you. It can only ever be extended.
Start as a vault. Add orchestration when you want it
Most backup products make you adopt their scheduler on day one. This one does not. Push from what you already have, and move up a layer only when handing over the schedule is worth something to you. Every layer produces the same artifact under the same encryption.
01
Bring your own automation
You already have CI/CD, cron, a Makefile, a deploy script. Produce the file however you like and push it through the API or the CLI.
- No worker to install, no agent, no inbound access
- Anything you can dump from a command line is a backup
- Encrypted, checksummed, retained and verified like any other run
We are purely a vault. We never see the source.
02
Let us schedule it
Add a worker on your own hardware and hand us the schedule. The worker connects to the source locally, so the connection string never leaves your network.
- Durable scheduling that survives restarts and redeploys
- Runs retry from where they stopped, not from the beginning
- Credentials stay in your config, never in our database
You execute, we orchestrate.
03
Or let us run it too
Hand over a connection and we execute the backup on our infrastructure. Same artifacts, same encryption, same retention. Nothing to host.
- Managed connectors for common sources
- Credentials held in a secrets manager, released only to the run
- The fastest way to a working backup, when hosting nothing is the point
We execute and orchestrate.
Everyone who has to sign off gets an answer
Platform and DevOps
Will this survive contact with our infrastructure?
- Push from the pipeline you already have, or declare backups in YAML and apply them
- Everything in the dashboard is also in the CLI and the REST API
- Adopt a worker later, or never, without changing anything you already wrote
- Nothing to expose: no inbound access and no agent unless you want one
Security and compliance
Who can read this, and what happens when someone gets in?
- Encrypted with your public key before the bytes leave your machine
- We hold ciphertext and never the private half, so a breach of ours yields nothing
- A retention hold that can be extended but never shortened, by anyone
- Keep the data in your own bucket, in your own account, when that is the requirement
Engineering leadership
What does this cost, and what if you disappear?
- Usage-based pricing across four meters, with no seat count
- Artifacts describe their own format, so recovery never depends on us
- The tools that touch your data are open source and auditable
- Start without a card, on credit, and see real usage before deciding
Anything you can produce a file from
On the push path there is no connector list to check against, because you produce the bytes. A connector only matters when you want us to do the reading, and that catalog is growing. Every one of them lands as the same artifact, restorable without us.
PostgreSQL
Local or cloud
MySQL
Local or cloud
Redis
Local or cloud
S3
Any S3-compatible bucket
HTTP endpoint
Whatever it returns
Script
Your hardware only
File
Your hardware only
Folder
Your hardware only
The code that holds your key is code you can read
The worker and the CLI are open source. They are the only components that see plaintext, touch your key, or talk to your database, so they are the ones worth auditing. The encryption boundary is the whole product, and you should not have to take it on trust. Go and check it.
.github/workflows/backup.yml
- name: Nightly database backup
run: |
pg_dump "$DATABASE_URL" \
| sctl backup submit prod-db -
env:
SAVED_API_KEY: ${{ secrets.SAVED_API_KEY }}Encrypted with your public key on the runner. No worker, no agent, and ciphertext is all we ever receive.