Encrypted backups

The encrypted backup vault lets you store database dumps and file archives on your Quiet Guard server as opaque, encrypted blobs the server can never read. It builds on the same per-team key pair as encrypted storage.

Paid feature. Backups are gated by the backups plan feature and a per-plan storage allowance: Indie includes 5 GB and Studio 20 GB; Free and Solo include none. See Billing and plans.

Zero-knowledge by design

The server stores only ciphertext and metadata (type, name, size, checksum, timestamps). It never holds the encryption key and cannot decrypt your backups. The flow is:

1. The client encrypts the archive locally with a random data key, then seals that key to your team's public key.
2. The sealed blob is uploaded to the server.
3. To restore, the client downloads the blob, unwraps your private key locally from the team passphrase, and decrypts.

At no point does the server see your passphrase or the unwrapped key.

Storage quota

Each plan grants a backup allowance in gigabytes. The server tracks total bytes stored across all your projects' backups. When an upload would exceed the allowance, it is rejected with 413 Request Entity Too Large:

{
  "message": "Backup storage quota exceeded.",
  "used_bytes": 5012345678,
  "limit_bytes": 5000000000
}

Delete old backups to free space.

Managing backups in the UI

When your plan allows backups, the project shows a Backups tab in the /app panel. The list carries metadata only: date, type, name, size, checksum, and the identifier, copyable, which is what monitor:restore takes as its argument. The content stays sealed.

Two buttons per row, and the difference between them is the whole point.

Decrypt downloads the blob and decrypts it in your browser, with your team's private key unwrapped from your passphrase. What you save is the archive in the clear, ready to use. The server takes no part in it: it sends the ciphertext it held, and the key that opens it has never existed on its side. Unlock this browser first on the Encryption page: that is the only place the passphrase is typed, and the Argon2id derivation happens there once for the tab's session.

Download hands you the sealed blob as it is, a .enc file nothing opens without your key. That is the escape hatch: archive the ciphertext elsewhere, or decrypt it from the command line with monitor:restore --file=<file> on the machine where the SDK is installed.

Server endpoints

The vault is driven by a project-token API (full details in the Ingestion API reference):

• GET /api/v1/encryption-key: serves the public key + wrapped private key + salt to the authenticated client.
• GET /api/v1/backups: list backups.
• POST /api/v1/backups: upload an encrypted blob (multipart/form-data with type, optional name, and file). type is database or files.
• GET /api/v1/backups/{uuid}: download the encrypted blob.
• DELETE /api/v1/backups/{uuid}: delete a backup.

Client commands

You will not call these endpoints by hand. The Laravel client ships three commands:

• monitor:backup: builds an archive (SQLite copy, mysqldump / pg_dump, or a tar of a folder), encrypts it with the team public key, and uploads it. --keep=N deletes all but the N newest backups of the same type once the upload has succeeded, which is what keeps a nightly schedule from filling the allowance.
• monitor:backups: lists what the vault holds for the project, newest first, with the id monitor:restore needs.
• monitor:restore: fetches the key material, unwraps the private key locally from your passphrase, downloads the blob, checks it against the checksum the list publishes, and decrypts it. A blob that does not match is refused with a message of its own, so a damaged download is no longer indistinguishable from a wrong passphrase. --file=<file> decrypts a blob you already downloaded from the dashboard, without asking the server for it again.

See the Laravel SDK documentation for command flags and examples, start from the Laravel SDK docs.