Skip to content
TYPO3 Extension

Amazon S3 for TYPO3

Amazon S3 as FAL driver for TYPO3. Store files in the cloud instead of on the web server.

Book a free initial call

aus_driver_amazon_s3 is the standard answer when TYPO3 assets can no longer live on the web server, bringing S3 buckets into the stack as a full FAL driver

A classic TYPO3 setup stores all media under fileadmin on the web server. That works as long as the project runs on a single machine and storage is sufficient. As soon as multi-server setups, container clusters, auto-scaling or content delivery networks come into play, this model breaks. Every instance would need an identical copy of all files, synchronisation becomes a permanent building site, deployments slow down. aus_driver_amazon_s3 solves this by integrating Amazon S3 as an external FAL storage. Files live in the bucket, TYPO3 reads and writes them via the S3 API, and every server instance accesses the same consistent dataset. For projects with high availability requirements, this is the standard path.

Besides the technical necessity for multi-server setups, there is a second important driver: backup and redundancy. S3 stores every file redundantly across several data centres and achieves a level of durability that a classic web server cannot guarantee. For companies whose media data is business-critical, that alone is a reason to move to S3.

Typical use cases

The first case are cloud-native deployments on AWS, Kubernetes or Docker Swarm. TYPO3 runs in several containers behind a load balancer, and every container is stateless. fileadmin as a local directory would mean that uploads only land on one container and the others do not see them. aus_driver_amazon_s3 keeps the asset base centralised and makes scale-out practical in the first place.

The second case are projects with very large data volumes. A media platform, an image archive or a download portal grows quickly to several hundred gigabytes or terabytes. Local server storage becomes expensive and inflexible, while S3 scales transparently and costs only for what is actually stored. Wiring it in through FAL also allows switching to the new storage without code changes in TYPO3.

Third use: CDN integration. Anyone who wants to deliver images and downloads through CloudFront, Cloudflare or a dedicated CDN uses S3 as the origin. aus_driver_amazon_s3 makes the files directly available in the bucket, TYPO3 generates the correct URLs and the CDN caches them globally. This measurably improves load times for international visitors.

Technical architecture

aus_driver_amazon_s3 implements the FAL driver interface of TYPO3 and uses the official AWS SDK for PHP to talk to S3. Every bucket is set up as its own “file storage” in the TYPO3 backend, with bucket name, region, access key and secret key. Alternatively, IAM roles can be used when TYPO3 runs on an EC2 instance or in an ECS task, which is cleaner because no static credentials sit in configuration.

The extension supports both Amazon S3 and S3-compatible services such as MinIO, Backblaze B2, DigitalOcean Spaces or Scaleway Object Storage. For projects that cannot live at AWS for data protection reasons, this flexibility is important, because a European S3-compatible provider behaves exactly like the AWS service from TYPO3’s perspective.

During operation, TYPO3 reads and writes directly against S3. The processed files, the cropped and optimised image variants, are by default stored in the bucket as well. Alternatively, a local directory for processed files can be configured, which speeds up image processing because GIFBUILDER does not have to pull every source image from S3 first.

Configuration runs through the backend module “file storages” and complementary TypoScript settings for the bucket URL and CDN prefixes. Developers additionally have to install the AWS SDK dependency via Composer and set the right permissions on the bucket.

Common problems and solutions

The first problem is performance with large image lists. When a page has to crop dozens of images simultaneously and pulls the sources from S3, page build takes noticeably longer. The solution is a local cache for processed files, possibly combined with a pre-warming script that pre-generates the most common variants after new uploads.

Second problem: permission errors on upload. When TYPO3 wants to write into the bucket but the IAM policy only allows read access, the upload fails with a cryptic error. The solution is a precise policy with s3:GetObject, s3:PutObject, s3:DeleteObject and s3:ListBucket for exactly the TYPO3 bucket, ideally limited to a prefix so that other applications sharing the same bucket are not affected by accident.

Third problem: data protection and region choice. Projects that need to run GDPR (UK: UK GDPR)-compliant should pick AWS regions in the EU, typically eu-central-1 in Frankfurt or eu-west-1 in Ireland. For higher requirements or customers who rule out AWS entirely, a European S3-compatible provider such as Hetzner, IONOS or Scaleway is the right path. The extension works with all of these providers.

Migration and version compatibility

aus_driver_amazon_s3 is compatible with TYPO3 v11, v12 and v13 and is actively developed. On upgrades, the AWS SDK version matters: newer TYPO3 releases often require current SDK versions that in turn require PHP 8.1 or higher.

A migration from local fileadmin to S3 is a clearly scoped project: copy files initially into the bucket with aws s3 sync, set up a new file storage in the TYPO3 backend, point existing sys_file records at the new storage via a script, and delete local files after a successful test. The extension does not ship a ready-made migration routine, because the exact approach is project-specific.

For existing systems, an inventory is mandatory before migration. How many files are sitting in fileadmin, how large is the dataset, which of them are orphaned and which are actually still linked? Such audits often reveal that a large share of the legacy data is never accessed again and that the migration can be limited to the actively used files. This reduces risk, effort and bucket costs.

Gosign accompanies S3 migrations for TYPO3 projects and designs multi-cloud architectures that meet data protection requirements and performance goals at the same time.

AI-accelerated development: 70% faster

TYPO3 Update & GDPR Audit

We upgrade your TYPO3 installation cost-effectively to the current LTS version - including all extensions, even outdated and unmaintained ones.

All extensions migrated

Including outdated, unmaintained or custom developments.

Fixed-price offer

Transparent costs, no hidden rework.

AI-accelerated

30-50% cheaper than market average thanks to AI-assisted code analysis.

Zero data loss

Complete data migration with rollback safety.

GDPR Audit: We audit your TYPO3 installation for GDPR compliance - cookie consent, tracking, extensions, forms and hosting - and implement all measures cost-effectively.

Gosign is a Hamburg-based digital agency with 25 years of experience in TYPO3 development. We have analysed over 800 TYPO3 extensions and today develop with AI assistance up to 70% faster than with classic methods. Our clients are mid-sized companies, universities and public institutions across Europe.

Last updated: April 2026

Book a free initial call

30 minutes with a TYPO3 specialist, no-obligation.