Loading

Azure Blob Storage

Azure Blob Storage is the third storage backend, beside the local web server and Amazon S3. With it, every file the installation stores goes into one container in an Azure storage account. Choose it when your organisation's infrastructure, data residency commitments or contracts already sit in Azure.

Where to find it

Architect Panel → Integration & Connections:

  • Deployments — the File Storage card shows Azure Blob Storage, the Storage Account and the Container in use

Architect Panel → Security:

  • Security Check-up — File storage, and Stored file links for the link mode

Architect Panel → Activity:

  • Error Log — every Azure error, with the HTTP status and Azure's own error code

Everything else is set in the server configuration by your hosting administrator. There is no Azure settings screen.

Before you start

Azure support is new. It has been checked thoroughly by the platform's automated tests, but at the time of writing those tests run without a real storage account, so it has not yet been proven end to end against Azure itself. Trial it on a non-production installation, with the checks below, before you rely on it.

What your hosting administrator sets up

  1. Create the storage account and the container in the Azure portal. The platform never creates a container, so it must exist first.
  2. Decide the container's public access level. Leave it private unless you choose direct links (below).
  3. Give the platform the storage account name, one of its access keys and the container name. These go in the server's private configuration, not in any synced settings file, because the key has full control of everything in the storage account. Sign-in by managed identity or a SAS token as the credential is not supported: only the account key.
  4. Set the storage backend to Azure and choose the link mode.
  5. Move any existing files into the container if the installation already has files on another backend. There is no built-in migration.

Link modes

  • Signed links (the default): each download gets a short-lived, read-only URL for that one file, valid for 60 minutes unless your hosting administrator sets another lifetime. Works with a private container.
  • Direct links: a plain URL to the file. Faster, with less load on the server, but it only works if the container's public access level allows anonymous reads of blobs, which means anybody with a URL can read the file. The Security Check-up marks this as Review.

Permissions are checked before either kind of link is given out. Because public access is set on the container, not per file, a public-or-private choice made for each S3 upload has no equivalent on Azure.

What works, and what does not

  • Works: uploads through File Upload fields and File Stores, private downloads, image thumbnails, deleting files, and eLearning packages.
  • Large files: the browser still sends large files to the server in chunks, so the browser side can resume. The server then sends the file to Azure in one piece, or in 64 MB blocks above that size. That server-to-Azure step does not resume; if it fails, the upload fails and is logged.
  • Not available on Azure: direct uploads from the browser to storage (an S3-only feature), and the Web Video field type, which stores the file as an ordinary file instead. Image moderation checks only images up to 5 MB, against 15 MB on S3.

Checking it works

  1. Open Deployments and confirm Storage Mode reads Azure Blob Storage, with the right Storage Account and Container.
  2. Upload a small file to a private File Upload field, then download it while signed in.
  3. Upload an image to a field with thumbnails, and check the thumbnail displays.
  4. Upload a file larger than 64 MB, if your upload limits allow it, to exercise the block path.
  5. Open Error Log and confirm nothing was logged from Azure.

What goes wrong

  • "no Azure storage account is configured", "no Azure blob container is configured" or "the Azure storage account key is not valid base64" in the Error Log. A configuration value is missing or mistyped.
  • An Error Log entry naming a request, a status and an Azure error code, for example a 403 with an authentication failure. Usually the wrong key, or a key that has been rotated in the portal.
  • A block was refused during a large upload. The log says the staged blocks are billable until Azure removes them, which it does after seven days.
  • Direct links return an error. The container is private. Either set its public access level or go back to signed links.

Worked example

An NHS supplier must keep data in its own Azure tenancy. The hosting administrator creates a private container, configures the account key and switches the installation to Azure with signed links. On the test installation the administrator uploads a PDF, an image and a 120 MB video file as an ordinary attachment, downloads each, and checks the Error Log is clean before repeating the change on production.

Recommendations

  • Trial it on a test installation first, while Azure support is new.
  • Keep the container private and use signed links.
  • Rotate the account key with your hosting administrator, not alone; the platform stops storing files the moment its key is wrong.
  • Use S3 if you need direct browser uploads or Web Video fields.