Azure Blob Storage

We write each new build of the databases you choose to a container of yours in Azure Blob Storage, with a shared access signature (SAS) you generate for it. What lands there, and when, is on Database Delivery.

Setting it up

Generate a SAS for the container. Here the storage account is acmedata and the container databases:

az storage container generate-sas --account-name acmedata --name databases \
  --permissions racwdl --expiry 2027-12-31 --https-only --auth-mode key -o tsv

racwdl is read, add, create, write, delete and list, which covers everything delivery does in a container: writing and replacing files, and deleting dated folders under Every build. A SAS made this way stays valid until it expires or the account key that signed it is rotated. To be able to revoke it without rotating a key, create a stored access policy on the container and pass --policy-name instead of the permissions and expiry.

The container's SAS URL is its address with the token after a ?:

https://acmedata.blob.core.windows.net/databases?se=2027-12-31&sp=racwdl&spr=https&sv=2022-11-02&sr=c&sig=...

In the console, add an Azure Blob Storage destination, paste the SAS URL, name a folder inside the container if you want one, and save. Test connection writes vpndetection-connection-test.txt and deletes it; Activate opens once it passes.

The destination shows when the SAS expires. Once it has, deliveries fail until you paste a new SAS URL, so replace it before then: we email the people who manage delivery in your organization after a day of failures.