
SafeGrd
dev.safegrdv0.0.29Updated Oct 5, 2026
Read backups and Fire Drills, and ask for a backup or a drill. No tool deletes a backup.
Overview
Lets an assistant read backup and restore-test status across hosts and request a backup or Fire Drill, without any tool that deletes backups.
- What it does
- SafeGrd exposes two MCP servers. The local one runs over stdio on a host and offers status, list, doctor, backup, verify, restore and export, each running the matching CLI command. The remote one reads every host's backups and Fire Drills and can ask for a backup or a drill now. Neither server has a tool that deletes a backup, changes where backups go, or takes a private key.
- When to use it
- Use it when an assistant should check whether backups and restore tests are healthy, or trigger a backup or Fire Drill before a risky change. The local server suits a machine that already runs the SafeGrd daemon; the remote server suits reading status across several hosts.
- Requirements
- The remote server is a hosted endpoint and needs a personal access token from the console's Tokens page, sent as the Authorization header in the form Bearer sg_pat_...; it is included on paid plans. The local server runs the safegrd binary or the container image on a host that has been enrolled and has its config and key.
Installation
In SourceWeft
- Open SafeGrd in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Web executable via Streamable HTTP. Remote servers run from the web runtime once configured in a workspace.
Other MCP clients
Add this to your client's mcpServers config.
{
"mcpServers": {
"safegrd": {
"type": "http",
"url": "https://safegrd.dev/mcp"
}
}
}README
SafeGrd CLI (safegrd)
[CI] [Go Version] [License: BSL 1.1]
safegrd backs up PostgreSQL, MySQL, MariaDB, MongoDB and SQLite databases, directory trees
and IMAP mailboxes. Each backup is compressed with zstd and encrypted with age on the host that
takes it, written to S3-compatible storage under Object Lock, and restored on a schedule to
check that every table, row and file came back.
It is the CLI and daemon of SafeGrd. Documentation is at safegrd.dev/docs, and every command and flag is in the command reference.
- Backups go from your host straight to storage. The remote server receives a record of each backup (when it ran, its size, its digest and the date its lock ends) and the signed result of each restore test. The data never passes through it.
- You choose who holds the key. By default the remote server keeps your key sealed and
releases it only to your enrolled hosts, so you can restore even after losing a host. With
enroll --key-custody local, only you can decrypt these backups. - Restores are tested. A Fire Drill restores the newest backup into a throwaway database or directory, compares its tables, rows and digests with what was backed up, and signs the result.
- An agent cannot remove a backup.
safegrd guardtakes a locked snapshot before a destructive command runs, and a personal access token cannot delete a backup or shorten its lock.
Installation
Install script (Linux and macOS)
It detects your OS and architecture, downloads the matching release archive, checks
it against the release's checksums.txt, and installs safegrd to /usr/local/bin
(or ~/.local/bin when it cannot use sudo). The script is install.sh
in this repository; https://raw.githubusercontent.com/safegrd/cli/main/install.sh
serves the same file.
When it runs in a terminal, it then offers to connect the machine to a remote server:
a browser login, a question about who holds the encryption key, then safegrd enroll.
The login prints a URL and a code that you can open in a browser on any device, so
it works the same on a server you reached over SSH or PuTTY. Without a terminal (CI,
cloud-init, cron) it installs and stops.
Options are environment variables, and they go on the sh after the pipe. Written
before curl they apply to curl, and the script never sees them:
Homebrew (macOS and Linux)
The formula installs the same release archives as the script.
Go
Container image
ghcr.io/safegrd/cli runs on linux/amd64 and linux/arm64 and carries pg_dump, mysqldump
and mongodump, and a PostgreSQL 18 server so a drill can restore a database into a
throwaway cluster on the volume. The tag names the Postgres client: <version>-pg18 reads
Postgres 18 and every older server. Releases are signed with cosign (keyless, from this repository's release
workflow):
packaging/compose runs the daemon beside a database,
packaging/kubernetes runs daemon run --once as a
CronJob, and packaging/helm/safegrd runs the daemon as a
Deployment.
Each names the release it was cut with, such as ghcr.io/safegrd/cli:0.0.10; change
the tag to upgrade.
Release archives, or from source
Static binaries for Linux and macOS (amd64, arm64) and their SHA-256 checksums are
on the releases page. To build:
Quickstart
1. Create a config and a key
Skip this if you let the install script connect the machine: it already wrote the
keypair and ~/.safegrd/config.yaml, and init refuses to overwrite them.
2. Connect to a remote server (optional)
3. Back up
4. Run a Fire Drill
5. Restore
6. Protect several things on one host, unattended
Each entry under surfaces: in ~/.safegrd/config.yaml is one protected thing, and
safegrd daemon install runs them on their schedules. A surface's credential block says
where its secret comes from; the config never holds it:
safegrd.example.yaml is the annotated version. The daemon reads its
config when it starts, so run safegrd daemon restart after changing it.
7. Take a locked snapshot before a destructive command
safegrd guard backs up one surface, waits until the snapshot is uploaded and locked, and
then runs the command. If the backup fails or the snapshot is not locked, the command does
not run and guard exits 3.
Storage on the host's own disk, or a bucket with worm_mode: NONE, cannot lock a snapshot,
so guard refuses there unless you pass --allow-unlocked.
A locked snapshot of the surface younger than --max-age stands in for a new backup, so an
agent running several destructive commands in a row backs up once. --check-only takes no
backup at all and refuses the command unless such a snapshot exists:
safegrd list --json prints every snapshot with its lock date, for scripts.
8. Back up a directory tree, and get one file back
File backups are incremental: the first run of each month uploads every file, and every run after it uploads only the chunks that changed. Every kept version of every file is searchable, and one file restores on its own.
--format tar keeps one archive per backup instead. What is locked, for how long, and
what a restore brings back: safegrd.dev/docs/surfaces/files.
AI agents (MCP)
safegrd has two MCP servers. Neither has a tool that deletes a backup, changes where
backups go, or takes a private key.
The local server, safegrd mcp, runs on a host over stdio and uses that host's config
and key. Its tools are status, list, doctor, backup, verify, restore and
export, each running the command of the same name. restore writes only into a new or
empty directory or an empty database.
The remote server, https://safegrd.dev/mcp, reads every host's backups and Fire Drills
and asks for a backup or a drill now. It takes a personal access token from the console's
Tokens page as Authorization: Bearer sg_pat_..., and is included on the paid plans.
The Claude Code plugin in safegrd/agent-plugins adds the remote server with skills that back up and run a Fire Drill before a risky change:
Both servers are listed in the MCP Registry
as dev.safegrd/safegrd, and the remote one on Smithery.
Cursor and VS Code configs, and every tool's arguments: safegrd.dev/docs/mcp.
What it backs up
- PostgreSQL, incrementally: the schema comes from
pg_dumpand the rows stream over binaryCOPYfrom the same snapshot, so arrays, enums, foreign keys, views, triggers and sequence positions all come back. Each run uploads only the chunks of each table that changed,restore --tableloads chosen tables into a running database, and--change-logskips reading tables nothing wrote since the last run.--format tarkeeps one archive per backup. Needs apg_dumpat least as new as the server on the host. - SQLite, incrementally: copied through SQLite's online backup in one read transaction, so transactions still in the WAL are in it and writers carry on. The copy keeps the database's pages in place, so each run uploads only the chunks whose pages changed.
--format tarkeeps one archive per backup. Needs nothing installed on the host. - MySQL and MariaDB through
mysqldump --single-transaction, and MongoDB throughmongodump --archive, one archive per backup. - Directory trees, incrementally: each run uploads only the chunks that changed, every object is locked once when it is written, and
safegrd findlists every kept version of a file forrestore --path --version. - IMAP mailboxes, every message as RFC 5322 mail, checked by SHA-256 on every drill.
- Locked storage: S3 Object Lock in compliance mode, or governance mode where a lock may need lifting. Storage on the host's own disk, and a bucket with
worm_mode: NONE, keep backups without a lock. - Fire Drills: restore backups on a schedule, count what came back, and sign a record of each test.
Development
Go 1.25 or newer. make with no target lists everything.
CI runs make ci on every push and pull request, so a green local run means a
green pipeline. Tagging v* runs make dist VERSION=<tag without v> and
publishes the archives and checksums.txt as a GitHub Release.
License
Business Source License 1.1, with an Additional Use Grant. See LICENSE.
In short: read, modify and build it freely, and use it for evaluation anywhere. Production use is included with a SafeGrd account on any plan, the free one too. Listing, verifying, restoring and exporting your backups is always permitted, with or without an account. Each version becomes GPL-3.0-or-later four years after it is published. For a commercial licence, contact [email protected].
Source: README.md at commit 675f055
Tools
0Version history
1- v0.0.29LatestOct 5, 2026


