Verestore
Launching shortly

Azure Blob Storage

Verified against the provider's documentation, not against a live account.

Verestore reads Azure Blob Storage through the native Blob API, not an S3 gateway. A provider snapshot disappears with the subscription that holds it; a dump in a container you control is the copy that survives, and Verestore proves it restores. For Azure Database for PostgreSQL Flexible Server vaulted backups, see Azure Backup for PostgreSQL Flexible Server.

1. Write dumps to a container

From any host with the Azure CLI and write access to the container:

pg_dump --format=custom --no-owner --file=orders.dump "$DATABASE_URL"
az storage blob upload --auth-mode login --account-name ACCOUNT \
  --container-name acme-backups --file orders.dump \
  --name "orders/orders-$(date -u +%Y-%m-%dT%H-%M).dump"

Verestore accepts pg_dump custom format (-Fc) or plain SQL, optionally gzipped. The format is detected from the content, not the file extension. Folder markers and ADLS Gen2 directory entries under the prefix are ignored.

Verestore needs only to list blobs under the prefix and read them; it pins the download to the listed ETag and never writes or deletes. Choose one of the two read-only credentials below.

2. Option A: a container SAS token (read and list)

The SAS must be for the container, with permissions Read and List only (sp=rl), HTTPS only, and an expiry you will rotate before.

Recommended: a service SAS bound to a stored access policy. It is signed with an account key, but you can revoke it at any time by deleting or changing the policy, without rotating the key:

az storage container policy create --account-name ACCOUNT --account-key "$ACCOUNT_KEY" \
  --container-name acme-backups --name verestore-read \
  --permissions rl --expiry 2027-05-01T00:00Z

az storage container generate-sas --account-name ACCOUNT --account-key "$ACCOUNT_KEY" \
  --name acme-backups --policy-name verestore-read --https-only -o tsv

The permissions and expiry come from the policy. A container holds at most five stored access policies, and a change to a policy can take a short while to take effect. This needs shared key authorisation enabled on the storage account.

Alternative: a user delegation SAS. It is signed with Microsoft Entra credentials instead of an account key:

az storage container generate-sas --account-name ACCOUNT --name acme-backups \
  --permissions rl --expiry 2026-11-12T00:00Z --https-only \
  --auth-mode login --as-user -o tsv

A user delegation SAS is valid for at most 7 days and cannot use a stored access policy, so you would have to paste a new token into Verestore every week. The trade-off: the stored-policy service SAS is long-lived and revocable but depends on an account key; the user delegation SAS avoids the account key but expires too soon for a schedule. If you want neither an account key nor weekly rotation, use option B.

Paste the token (the query string, with or without the leading ?) as the SAS token.

3. Option B: a service principal with Storage Blob Data Reader

Create a Microsoft Entra app registration with a client secret:

az ad sp create-for-rbac --name verestore-reader

The output contains appId (the client ID), password (the client secret) and tenant (the tenant ID). The secret is shown once and expires; note the date and rotate it before then.

Assign the built-in role Storage Blob Data Reader on the container only, not the account or subscription:

az role assignment create --role "Storage Blob Data Reader" --assignee <appId> \
  --scope /subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.Storage/storageAccounts/<account>/blobServices/default/containers/acme-backups

Role assignments can take several minutes to propagate. If the permission check fails straight after, wait and try again.

Role assignments apply to the whole container, not to a prefix: use a dedicated container per database for strict scoping.

4. Network access

Hosted runs reach the storage account over the public internet. Accounts with public network access disabled, or firewall rules that only allow selected networks, are not supported by hosted runs yet; a self-hosted agent is planned.

5. Add the target in Verestore

  • Where your backups are: Azure Blob Storage
  • Storage account URL: https://<account>.blob.core.windows.net
  • Container: acme-backups
  • Prefix: orders/
  • Access with: SAS token (read + list), then paste the token; or Service principal (Storage Blob Data Reader), then enter the tenant ID, client ID and client secret

Both credentials are encrypted for our runners only, like any other key, and no page or API call ever returns them.