External backups your attacker can’t reach.
A new way to keep backups secure and stable - protection from ransomware, malicious insiders, and human error. A worker runs inside your own server, so credentials and data can stay in your environment, and every backup is sealed in cold storage your attacker can’t reach.
Your backups live inside the blast radius.
Almost every backup tool runs inside the same environment it protects. So the moment someone gets in - or someone on the inside turns - your backups fall with everything else. That’s not a backup. That’s a second copy in the same fire.
Ransomware
Modern ransomware hunts for backup volumes and snapshots first, then encrypts or deletes them before touching production - so you can’t recover.
Compromised credentials
One leaked key or over-scoped role and an attacker has the same reach as your platform team - including every backup bucket and snapshot policy.
Insider & human error
A disgruntled engineer with prod access - or an accidental terraform destroy - can wipe services and their backups in the same breath.
Internal backups
- Same credentials, same network, same blast radius
- Deletable by anyone with production access
- Encrypted together with prod during an attack
saved.sh - external by design
- Stored outside your accounts & provider
- Out of reach of your prod credentials
- Verified, encrypted and sealed in immutable cold storage
External by architecture. Verified end to end.
Three ways to back up a source - a local worker, a cloud worker, or a manual push. Whichever you choose, every backup runs the same verified pipeline - scoped credentials, integrity checks, encryption, and retention-locked cold storage.
Local worker backup
A lightweight worker runs inside your own infrastructure. Your credentials stay local, there’s no need to expose your services to us, and every backup is encrypted internally with your own key before it ever leaves.
- Credentials stay local - nothing sensitive is sent to us
- No need to expose your services - no incoming ports
- Encrypted internally with your own key
30 predefined integrations. One backup model.
Databases, caches, queues and object storage - each with native, consistent dumps and restores out of the box.
A CLI, an SDK and a REST API - same guarantees.
Wire backups into CI, your control plane, or a cron in minutes. Credentials stay sealed in an encrypted secret store - the CLI, SDK and API only ever orchestrate the workers.
CLI
Single binary. Script backups, schedules and restores from anywhere you have a shell.
SDK
Typed clients for TypeScript, Go and Python to embed backups into your own platform.
REST API
Everything the CLI does, over plain HTTPS with scoped bearer tokens and webhooks.
# install the single-binary agent + CLI
curl -fsSL https://saved.sh/install | sh
# authenticate with a scoped, least-privilege token
saved auth login
# register a source - creds come from your secret store
saved source add postgres \
--name billing-db \
--from-secret secret/data/prod/postgres
# run a backup now
saved backup run billing-db
# schedule + retention
saved schedule create billing-db \
--cron "0 */6 * * *" --retain 30dSee why teams choose saved.sh.
How external, usage-based backups stack up against traditional tools and hand-rolled scripts.
| Feature | saved.sh | Traditional tools | Manual scripts |
|---|---|---|---|
| Automated scheduling | ✓ | ✓ | ✕ |
| Encryption at rest | ✓ | ✓ | ✕ |
| Client-side encryption | ✓ | ✕ | ✕ |
| Point-in-time recovery | ✓ | ✓ | ✕ |
| API & SDK access | ✓ | ✕ | ✕ |
| Pay-per-use pricing | ✓ | ✕ | ✓ |
| Multi-region support | ✓ | ✕ | ✕ |
| Automatic verification | ✓ | ✕ | ✕ |
| CI/CD integration | ✓ | ✕ | ✓ |
| Zero-knowledge security | ✓ | ✕ | ✕ |
Zero-knowledge: end-to-end encryption with no incoming ports required.
Pay for resources used - not a plan you outgrow.
No seats, no tiers, no “contact sales to unlock Postgres.” You’re billed only for the compute, storage and network a backup actually uses - metered per second. Every feature is available from your first byte.
Compute time
Charged for backup workflow execution timeBilled per second with a 1-second minimum. A typical 100 GB PostgreSQL backup takes ~30 seconds on 1 vCPU.
Storage
Hot storage for active backup dataNetwork transfer
Data transfer during backup & restoreArchive storage
Cold storage for long-term retentionHow we calculate
Billed per second with a 1-second minimum, based on $0.00001347 per millisecond of compute. A typical 100 GB PostgreSQL backup runs in about 30 seconds on 1 vCPU - so a full backup costs well under a dollar.
No surprises
- Per-second metering, billed monthly
- Budget alerts & hard caps
- No egress lock-in - restore anywhere
Security & support, built in.
Audited security & compliance
Credits for any downtime
Full refund on unused credits
AES-256 encryption standard
EU data residency available
Email & chat for all plans
Questions, answered.
Put your backups out of reach.
Join the waitlist for early access. We’re onboarding self-hosted and cloud teams in batches.