Azure Storage for TYPO3

Organizations on a Microsoft stack need Azure Storage, not local file systems

When your IT landscape runs on Azure, Active Directory manages your users and SharePoint holds your documents, the TYPO3 file system belongs in the Azure cloud as well. EXT:azurestorage connects Azure Blob Storage to TYPO3 as a FAL driver (File Abstraction Layer). Editors notice no difference, but the files no longer sit on the web server. They live in Microsoft’s cloud infrastructure, with CDN delivery, geo-redundancy and practically unlimited storage.

This extension is the Azure counterpart to EXT:aus_driver_amazon_s3. The choice between the two is rarely a technical one; it follows your existing cloud strategy. If you already run on Azure, staying within the Microsoft ecosystem saves complexity, contracts and network costs.

Typical use cases

Enterprise websites with a multi-server setup. Large TYPO3 installations run on several web servers behind a load balancer. Without cloud storage, files have to be synchronized between the servers via rsync, NFS or GlusterFS, and each of these approaches brings its own problems. Azure Blob Storage as a FAL driver makes file synchronization unnecessary: all servers access the same blob container. For one client with 4 web servers and 180,000 files, the migration to Azure eliminated the entire NFS infrastructure.

Media-heavy portals with a global audience. Companies with customers in Europe, Asia and North America need fast load times worldwide. Azure CDN delivers images and downloads from edge servers in more than 130 cities. The integration is set up through the CDN endpoint configuration in the Azure portal, and TYPO3 automatically generates the matching CDN URLs.

Compliance requirements for data residency. Some industries require files to be stored in a specific country. Azure runs data centers across Europe, including Frankfurt, Zurich and Vienna. The storage account configuration lets you define exactly where the data physically resides. That is an advantage over generic S3-compatible providers, where the geographic configuration is often opaque.

Technical architecture

EXT:azurestorage implements the TYPO3 FAL driver interface. In other words, the extension registers itself as a driver in the File Abstraction Layer and replaces the standard file system operations (read, write, delete, list) with Azure Blob Storage API calls.

Configuration happens in the backend, in the TYPO3 file storage settings. You create a new storage record there and select the “Azure Blob Storage” driver. The credentials (storage account name, access key or SAS token) are stored in the storage configuration. Our recommendation: use a SAS token with limited validity and read/write permissions instead of the master access key.

TYPO3 and Azure communicate through the Azure Storage REST API. Uploads are stored as block blobs, and large files (over 256 MB) are automatically split into blocks. On the PHP side, the extension uses the Azure SDK for PHP or a lightweight REST client implementation.

When needed, images are processed by TYPO3’s image processing (GraphicsMagick/ImageMagick). The processed variants are stored in Azure as well, typically in a separate container (_processed_). Caching these processed files shortens processing time for repeat requests.

Common problems and solutions

Slow backend performance when browsing large directories. Azure Blob Storage has no real directory structure; it emulates one through path prefixes. Listing 10,000 files in a “folder” requires API pagination and takes noticeably longer than on a local file system. The fix: configure TYPO3’s FAL indexer properly and refresh the index regularly, instead of checking live against Azure on every backend request.

Image processing fails. To process an image, TYPO3 has to download it, process it and upload it again. With an unstable connection or large images (200 MB TIFF files), the process aborts. The fix: run the processing on the server in a local temp directory and upload only the result. The processingFolder setting should point to a local path.

Costs explode due to unnecessary API calls. Every file access is an API call, and Azure bills per 10,000 transactions. A poorly configured TYPO3 indexer can generate thousands of calls per minute. Set up monitoring in Azure Cost Management and switch the FAL indexer to scheduler-based intervals instead of real time.

Migration and version compatibility

EXT:azurestorage is a niche product with a limited community. The versions available in the TER and on Packagist support TYPO3 v10 and v11. For v12, forks of varying maturity exist on GitHub. For TYPO3 v13, there is currently no ready-made solution.

There is no shortcut through EXT:aus_driver_amazon_s3 for Azure: Azure Blob Storage has no S3-compatible interface, only its own REST API plus SFTP and NFS 3.0. The S3 extension’s “Custom host name” setting only reaches S3-compatible storage such as MinIO, so it is only an option if you switch storage.

If you are moving from a local file system to Azure, plan the migration in three phases: first, upload the existing files to the blob container using AzCopy or Storage Explorer; second, switch over the TYPO3 file storage configuration; third, rebuild the FAL index. For 50,000 files, the whole process typically takes one working day. Gosign has carried out Azure migrations for TYPO3 projects with up to 400,000 files and advises on the native extension as well as on S3-compatible storage as an alternative to Azure.