Where documents are stored: Local, Azure Blob, and S3 providers
This article explains where MobilityManager keeps the actual file content you upload, and how the three storage providers — Local, Azure Blob, and S3 — differ.
Metadata and file content are stored separately
Every document has two parts. The metadata (file name, content type, size, category, uploader, versions) lives in your company's database. The file content is written to a storage provider chosen by your administrator. A version record links the two by keeping the storage path where the content was written.
Regardless of provider, files are saved under server-generated names — a random identifier plus the original extension — not their original file names. The friendly file name is preserved in the metadata and reapplied when you download.
The three providers
| Provider | Where files go | Best for |
|---|---|---|
| Local | A directory on the server's file system (the configured base path). | On-premises installs or evaluation, where files stay on your own server. |
| Azure Blob | A container in an Azure Storage account. | Deployments on Microsoft Azure. |
| S3 | An Amazon S3 bucket (or an S3-compatible store). | Deployments on AWS or S3-compatible object storage such as MinIO. |
Local provider
The Local provider writes each file into a configured base folder on the server. If the folder is missing it is created, and the platform verifies the folder is writable before accepting it. Reads are guarded against path traversal, so only files inside the configured storage root can be served.
Azure Blob provider
The Azure Blob provider uploads each file as a blob in a named container. If the container does not exist yet, it is created with no public access, so blobs are never anonymously reachable. The connection to Azure is resolved from a secret reference rather than a value typed into the app.
S3 provider
The S3 provider stores each file as an object in a bucket, in a specified region. It also supports a custom service URL, which enables path-style addressing for S3-compatible stores like MinIO. Access and secret keys are resolved from secret references, not stored in plain text.
Note: There is one active storage configuration for the whole platform at a time. The active provider is where new files are written and where downloads are read from.
Encryption is independent of the provider
When encryption at rest is enabled, files are encrypted before they are handed to whichever provider is active. That means Local, Azure, and S3 all receive already-encrypted content, and the underlying folder, container, or bucket never holds a readable copy. Decryption happens only when you download.
Tip: Choosing a provider is a platform-level decision made by an administrator with settings:manage. As an everyday user you do not pick where files go — you just upload, and the active provider handles the rest.
Related
- Configuring the document storage provider
- Encryption at rest and the encryption key
- How documents work across the platform
- Tenant scoping and document isolation
