saved.sh
DocsPricingDownloadBlog

By source

  • Database backupsPostgres today, on any of the three paths.
  • Files and foldersDirectories on your own hardware. Local path only.
  • Anything you can scriptThe escape hatch, with no reduced guarantees.

By how it runs

  • Backups you driveCLI or API, driven by whatever you already run.
  • Backups on your infrastructureOur worker, your hardware. We never hold the credential.
  • Fully managed backupsWe execute and orchestrate. Nothing to host.
  • Compliance and custodyYour bucket, your account, our orchestration.

Understand it

  • How it worksThree paths, one artifact lifecycle
  • SecurityWhat we can and cannot see
  • CompareAgainst snapshots, cloud-native and scripts
Get started
saved.sh

External backups for the systems a business actually runs on.

A product of reops.

Product

  • Documentation
  • Solutions
  • Compare
  • How it works
  • Security
  • Pricing
  • Download

Developers

  • CLI
  • REST API
  • Recover

Company

  • Blog
  • Privacy
  • Terms

© 2026 saved.sh

Your data survives what holds it.

All postsEngineering

You already have the automation. You are missing the vault

Every backup product starts by asking you to adopt its scheduler. That is the wrong first ask, and it is why most teams still have a cron job nobody has looked at since March.

4 August 2026·saved.shView as Markdown

Every backup product opens with the same request: install our agent, adopt our scheduler, let us reach into your network. It is a large ask for something you have not evaluated yet, and it is almost always the wrong first step.

You already have automation. You have CI, you have a deploy pipeline, you have a cron entry somewhere that has been quietly running since before the last two people joined. What you are missing is not a scheduler. It is somewhere safe for the output to land.

The actual gap

A backup has two halves: producing the bytes, and keeping them somewhere the thing that produced them cannot reach. Almost every team has solved the first half already. Almost none have solved the second.

The first half is the easy half

Here is a complete backup, and it probably looks like something already in your repository:

pg_dump "$DATABASE_URL" | gzip > backup.sql.gz

That line is fine. It is not the part that fails. What fails is everything after it: where the file goes, who can delete it, whether anyone notices when it stops running, and whether the copy is reachable by whatever just compromised the database.

1line

to produce a backup

6problems

between that line and a backup you can rely on

0of them

solved by adding a scheduler

The second half is where products should start

So start there instead. Produce the file however you already do, and push it:

pg_dump "$DATABASE_URL" | sctl backup submit prod-db -

No agent. No inbound port. No new scheduler to learn, and nothing to reason about when it fails, because the thing that runs it is the thing you already trust to run everything else.

What you get on the other side is the half you were missing. The bytes are encrypted with your key before they leave the machine, checksummed and recorded, written under a retention lock, and kept somewhere a compromise of your cloud account does not reach.

YOUR CLOUD ACCOUNTproductionsnapshotreplicaONE CREDENTIAL REACHES ALL OF ITENCRYPTEDsaved.shyour storage,your keysAND STOPS HERE
Terracotta is the reach of one compromised credential. Green is the copy it does not touch. Producing the file was never the hard part.

Adopt the scheduler later, or never

There is a real argument for handing over the schedule eventually. A durable engine survives a worker restart and resumes from where it stopped, which a cron entry cannot do and will not tell you about.

A CRON JOBworker restartsthe run is gone, and nothing says soA DURABLE RUNresumes from the step it reachedcompletes
The same interrupted run, twice. One of these tells you it failed.

But that is a second decision, and it should be a second decision. Take it when handing over the schedule buys you something, not as the price of admission.

What we would rather you did

Do not migrate anything. Add one line to a pipeline you already run, and see whether the copy shows up somewhere you like. If it does, the rest of the product is there when you want it. If it does not, you have lost a line of YAML.

Three levels, and you pick

01

Your CI/CD

cron, pipeline, script

02

Your worker

your hardware

03

Our worker

our infrastructure

One vault

same encryption,
same retention,
same artifact

More handed over as you go down. The right-hand side never changes.

Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.
Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.
More handed over as you go down. The right-hand side never changes.

Every layer produces the same artifact under the same encryption and the same retention policy. The only thing that varies is how much of the work you want to keep doing yourself, and you can change your mind in either direction without rewriting anything.

Start as a vault. That is the part you are missing.

Read next

Your backup vendor should be optional

We publish the procedure for opening a saved.sh artifact without saved.sh, with no account, no CLI, and no us.

Backups that survive the thing that took out production.

How it worksStart free