How access works
Verestore restores the newest object under a bucket prefix, for example s3://acme-backups/orders/ (or an Azure Blob container prefix). Your backup job keeps writing pg_dump files there (custom format -Fc or plain SQL, optionally gzipped). We never write, delete or list anything else.
The key you give us needs exactly two permissions on that prefix:
| Action | Why |
|---|---|
ListBucket (ListObjectsV2) limited to the prefix |
find the newest backup |
GetObject on prefix/* |
download it into the isolated run |
When you add the key, we run a permission check: we list the prefix and read the first bytes of the newest object, and tell you what we found. The key is then encrypted so that only our orchestrator, the service that starts runs, can open it, and it can never be read back (see Security).
Pick your platform:
- AWS (RDS and S3)
- Scaleway
- S3-compatible stores: Cloudflare R2, Backblaze B2, Wasabi, OVHcloud, DigitalOcean Spaces
- Google Cloud Storage, and Cloud SQL scheduled exports to Cloud Storage
- Azure Blob Storage, and Azure Backup for PostgreSQL Flexible Server
- Neon
- Supabase
- Self-hosted PostgreSQL with MinIO or any S3-compatible store
Why off-site: provider snapshots and managed backups live inside the provider account they protect, and go with it if the account is closed, compromised or deleted. A dump in storage you control (another account, another provider) is the copy that survives; Verestore proves it restores.
For S3-compatible stores the signing region follows from the endpoint, so the region field can stay empty. Azure Blob uses its native API, with a read + list SAS token or a service principal holding Storage Blob Data Reader on the container.
Automation: API tokens for CI and compliance tools, and webhooks, Teams, PagerDuty and Opsgenie for alerts.
Recommendation: use a dedicated prefix (or bucket) per database, and a dedicated key per Verestore target, so revoking one doesn't affect anything else.