Docs / Documentation

Documentation

SafeGrd runs on a host that can already reach what you are protecting. It compresses and encrypts there, writes the encrypted backup to your own bucket or to SafeGrd's hosted storage, locked with S3 Object Lock, and later restores it to check that it works. Your data never passes through SafeGrd's control plane. A surface you set to drill on SafeGrd is restored on a machine started for that drill and destroyed when it ends, and a database with no host is backed up the same way, from a connection string SafeGrd holds sealed.

Quickstart

Three commands take you from nothing to a tested backup. The first installs the CLI and logs you in. It prints a link to open in a browser on any device, so it works the same on a server you reached over SSH.

# 1. install, log in, and enrol this host (generates your keypair)
curl -fsSL https://safegrd.dev/install.sh | sh
# listed under its hostname; add SAFEGRD_NODE_NAME=web-01 before sh to choose the name
# 2. take an encrypted backup
safegrd backup --database-url "$DATABASE_URL" --retention-days 14
# 3. check that it restores
safegrd verify --snapshot snap-1b094c0af8

If you hold your own key, keep a copy of ~/.safegrd/keys/daemon.key.

With a customer-managed key that file decrypts your snapshots, and it stays with you. Store a copy with your most important credentials. With a SafeGrd-managed key, SafeGrd keeps it sealed for you instead.

On a host that cannot reach SafeGrd, or to try it without an account, run safegrd init. It does the local half and nothing else. A node set up that way backs up, restores and verifies standalone.

What the console shows after the first backup

These screenshots come from a demo organization in which the daemon backed up a PostgreSQL database and a directory, then restored both.

The Nodes tab: a host and its two surfaces, with each surface's last backup, recovery point, restore time and schedule. The Nodes tab: a host and its two surfaces, with each surface's last backup, recovery point, restore time and schedule.
The Nodes tab: each host and the databases, directories and mailboxes it backs up. Details opens a row's full record and its actions.
The Snapshots tab: two encrypted snapshots with their contents, sizes and retention. The Snapshots tab: two encrypted snapshots with their contents, sizes and retention.
The Snapshots tab: every encrypted snapshot, what is in it and the date its lock ends.

The Fire Drills tab is shown on the Fire Drills page and the Tokens tab on Account.

Where to go next

01 Install and enrol

Installing, the two ways to set a host up, and who holds the private key.

 02 Command reference

Every command and every flag, with the environment variables that replace them.

 03 Surfaces

PostgreSQL, MySQL, MariaDB, MongoDB and SQLite, file trees and IMAP mailboxes: what each engine captures.

 04 Storage and retention

Bring your own bucket, what Object Lock guarantees, and recovering a deletion.

 05 Threat Shield

Anomaly detection and row-drop alerts, and why the known-good snapshot is still there.

 06 Daemon

Schedules, service installation, locks, backoff and daemon credentials.

 07 Restore and Fire Drills

Restoring for real, and proving a snapshot restores without touching production.

 08 The attestation record

The signed hash chain, and how to verify it offline without trusting us.

 09 Security and key custody

What the control plane can hold, what it never holds, and why the CLI is source-available.

 10 Organizations and billing

Projects, members, tokens, and what lapsing does and does not do.

 11 AI agents (MCP)

Let a coding agent read backups, ask for one and prove it restores. It cannot delete anything.

 12 Troubleshooting

Diagnostics and common issues encountered in real-world deployments.

Deeper

The CLI is source-available

Inspect the client code that holds your key. Under Business Source License 1.1, production use is included with any SafeGrd account, and restoring never needs a subscription: github.com/safegrd/cli.

Start here Next: Install and enrol