When we built Uplint, one principle was non-negotiable: your files land in your cloud storage, under your credentials. Uplint is the trust layer that verifies, classifies, and audits everything coming in - but the bytes end up in a bucket you own and control, not in some vault we operate. For the regulated teams we work with, that's the whole point.
There was an unspoken word in that promise, though. "Your cloud" quietly meant AWS. If your infrastructure ran on Azure, Bring Your Own Bucket wasn't really yours to bring.
Today that changes. Uplint now supports Azure Blob Storage as a first-class storage provider, alongside Amazon S3.
Not every team lives on AWS
We heard the same thing from enough teams that it stopped being an edge case. Hospitals standardized on Azure because the rest of their Microsoft estate already was. Fintechs picked Azure for a specific region's compliance posture. Enterprises running Entra ID, Azure SQL, and Functions didn't want their file intake to be the one workload that dragged a second cloud into the account.
For those teams, "just use S3" isn't a small ask. It means a new vendor relationship, a separate billing and security review, another set of credentials to rotate, and data sitting outside the compliance boundary they already argued for. The trust layer was a fit; the storage assumption wasn't.
Storage should follow your infrastructure, not fight it. So we made the provider a choice.
What shipped
A storage bucket in Uplint - the configuration that tells us where and how to read and write your files - now carries a provider. It's either aws_s3 or azure_blob, and it decides which backend the bucket talks to.
- Amazon S3 stores objects in an S3 bucket, authenticated with an access key ID and secret access key.
- Azure Blob Storage stores blobs in an Azure container, authenticated with a storage account name and account key.
Everything else you already know stays the same: a friendly name, a base path prefix, the default/fallback designation, and per-context routing. And because a tenant can register many buckets, you can mix providers - keep medical claims in an Azure container in your compliance region and nightly exports in an S3 bucket, all behind the same single Uplint API call.
Here's registering an Azure container and pointing a context at it:
# 1. Add an Azure Blob bucket
curl -X POST https://api.uplint.dev/api/v1/tenants/tnt_9f8e7d6c/storage-configs \
-H "Authorization: Bearer ul_live_..." \
-H "Content-Type: application/json" \
-d '{
"name": "Insurance Claims",
"provider": "azure_blob",
"account_name": "acmestorage01",
"account_key": "base64AccountKeyFromThePortal==",
"default_bucket": "acme-insurance-claims",
"base_path": "file-service/"
}'
# 2. Route a context to it
curl -X PATCH https://api.uplint.dev/api/v1/contexts/insurance_claims \
-H "Authorization: Bearer ul_live_..." \
-H "Content-Type: application/json" \
-d '{ "storage_config_id": "cfg_a1b2c3d4e5f6" }'
default_bucket is just the Azure container name - we keep the field name consistent so a bucket is a bucket, whichever cloud it lives in. Prefer clicking to curling? The dashboard's Add Bucket dialog now has a provider selector; pick Azure Blob Storage and fill in the account name, key, and container.
How it works under the hood
The interesting part is that almost nothing above the storage adapter had to know Azure exists. Uplint's storage layer was always an abstraction - upload, download, delete, exists, presign - and S3 was simply the first thing plugged into it. Adding Azure meant writing one more adapter and teaching a single factory to pick it based on the provider. Every upload and download flows through the same code either way.
A few Azure specifics worth knowing:
Downloads use SAS URLs. When Uplint hands your client a download link, on S3 that's a pre-signed URL and on Azure it's a blob SAS URL - the exact same idea, a short-lived signed link that expires. Your download flow doesn't change; the link just points at blob.core.windows.net instead of S3.
Auth is Shared Key. Azure buckets use your storage account name + account key. We chose Shared Key precisely because generating those SAS download links requires the account key - it's what lets Uplint mint expiring links on your behalf. The key is encrypted at rest and never returned by any endpoint, exactly like an S3 secret. When you read a bucket back, the account name comes through (it isn't a secret) and the key is omitted entirely.
One setting to check. Your Azure storage account needs "Allow storage account key access" enabled - it is on by default. If it's off, Azure rejects the key and uploads fail with a clear "Key based authentication is not permitted" error.
The routing model is identical
If you've used Uplint's multi-bucket routing, none of this is new - and that's the point. Provider is orthogonal to routing. Every file context still resolves to a bucket the same way: the context's bound bucket if it's active, otherwise your tenant default.
And the per-file guarantee still holds. Uplint records not just which bucket, but which provider each file was written to. Re-point a context from an S3 bucket to an Azure container tomorrow, and only new uploads follow the change - every existing file keeps resolving to exactly where it landed, on the cloud it landed on. You can run a tenant that's half S3, half Azure, mid-migration, and every file stays readable throughout.
Backward compatible, as always
If you're on S3 today, you don't have to do anything, and nothing changed. A storage configuration with no provider is treated as aws_s3, so your existing buckets, credentials, and files keep working untouched. There's no migration, no flag to flip, no version to bump on your side. You opt into Azure the moment you add an Azure bucket - and not a second before.
Getting started
Open Storage in the dashboard, click Add Bucket, and choose Azure Blob Storage. You'll need three things from the Azure portal: your storage account name, an account key (under Access keys), and a container name. Paste them in and route a context to your new bucket.
Two clouds, one API, the same trust layer in front of every file. Bring whichever bucket you've got.