Projects can be configured to store and serve files from an Azure Blob Storage container. This allows your organisation's data to remain in your own Azure subscription.
You will need the Configure File Settings permission on the project. See Permissions for details.
Before configuring the project, you will need the following from Azure:
| Field | Description |
|---|---|
| Storage Account | The name of your storage account (e.g. mycompanydata) |
| Blob Container | The container within the account to store files in (e.g. project-data) |
| Key Prefix | Optional path prefix for all files in this project (e.g. project-a/). This allows multiple projects to share a single container by scoping each to a different prefix. Leave empty to use the container root. |
| Account Key | An access key for the storage account |
| Endpoint Suffix | Optional. Leave empty for the global Azure cloud (core.windows.net). Set this only for sovereign clouds (e.g. core.usgovcloudapi.net, core.chinacloudapi.cn). |
| Direct Storage Access | Optional. When enabled, file reads are served directly from Azure instead of streaming through the server (see Direct Storage Access below). Off by default. |
The project will now use the configured Azure container for file storage and access.
By default the server proxies every file read: it fetches the bytes from Azure and relays them to the client. With Direct Storage Access enabled, the server instead hands the client a short-lived SAS URL and the client fetches the bytes straight from Azure — reducing server bandwidth and latency, and letting the SDK stream large models without per-request round-trips to the server.
The trade-off is that the server authorises access when it issues the SAS URL rather than on every byte range, so a SAS URL remains usable until it expires (a few minutes). Leave this off if you require the server to authorise every individual read. Browser downloads with this enabled rely on the CORS configuration below.
When uploading files, the browser uploads directly to Azure using short-lived SAS URLs. For this to work, your storage account must have a CORS (Cross-Origin Resource Sharing) rule that allows requests from the domain where udServer is hosted.
In the Azure Portal, navigate to your storage account > Settings > Resource sharing (CORS) > Blob service, and add a rule:
| Setting | Value |
|---|---|
| Allowed origins | https://your-udserver-domain.com |
| Allowed methods | GET, PUT, HEAD, DELETE |
| Allowed headers | * |
| Exposed headers | * |
| Max age | 3600 |
Replace https://your-udserver-domain.com with the origin your udServer instance is served from. This is typically https://udcloud.nuclideon.com or https://au-udcloud.nuclideon.com. You can list multiple origins if needed.
| Setting | Why it's needed |
|---|---|
| Allowed methods | PUT is required for direct block uploads. GET and HEAD for file downloads and metadata. |
| Max age | Caches the preflight response so the browser doesn't send an OPTIONS request before every chunk. |
Without this configuration, file uploads from the browser will fail with CORS errors.