django-storages

django-storages is a collection of custom storage backends that plug into Django’s Storage API, letting a Django project swap its default local-filesystem file storage for a cloud or remote target without changing application code. It ships backends for Amazon S3, Google Cloud Storage, Azure Blob Storage, Dropbox, SFTP, FTP, and Apache Libcloud, each implementing the same save/open/url/delete interface Django expects from DEFAULT_FILE_STORAGE.

Because every backend conforms to Django’s existing storage abstraction, model FileField/ImageField uploads, the admin, and any third-party app that reads/writes through django.core.files.storage work unmodified once a backend is configured — only settings change, not application code. The project began as a fork (django-storages-redux) and became the official successor on PyPI in 2016; it remains the de facto standard for object storage in Django projects.

What You Get

• An S3 backend (storages.backends.s3.S3Storage) built on boto3, supporting custom domains, signed URLs, and object ACLs
• Backends for Google Cloud Storage and Azure Blob Storage with the same Django Storage interface
• SFTP and FTP backends for storing files on a remote server without a cloud provider
• A Dropbox backend and an Apache Libcloud backend covering additional providers through libcloud’s abstraction
• Drop-in compatibility with Django’s FileField/ImageField, admin file uploads, and django.core.files.storage APIs

Common Use Cases

• Serving user-uploaded media (avatars, documents, attachments) from S3 or GCS instead of the app server’s local disk
• Running Django on ephemeral/container infrastructure (Heroku, Kubernetes) where local filesystem storage doesn’t persist across deploys
• Storing static or media files on Azure Blob Storage for projects hosted on Azure App Service
• Deploying to a target without cloud storage by writing uploads to a remote server over SFTP/FTP

Under The Hood

Architecture - Each backend in storages/backends/ (s3.py, gcloud.py, azure_storage.py, dropbox.py, sftpstorage.py, ftp.py, apache_libcloud.py) subclasses Django’s Storage base class and implements the required primitives (_open, _save, exists, url, delete, size) against the corresponding provider SDK; storages/base.py and storages/utils.py hold shared setting-resolution and compression helpers used across backends. storages/compress.py provides optional gzip compression for static assets uploaded to S3/GCS. Tech Stack - Pure Python, targeting Django 4.2 through 5.2, with each backend importing its provider’s official SDK as an optional dependency (boto3 for S3, google-cloud-storage for GCS, azure-storage-blob for Azure, paramiko for SFTP, dropbox for Dropbox), so a project only needs to install the SDK for the backend it actually uses. Packaging uses setuptools with dynamic version/readme resolution. Code Quality - The tests/ directory (10 test modules) covers each backend independently, mocking the underlying provider SDK to test URL generation, ACL handling, and file operations without live cloud credentials; the S3 backend in particular (717 lines) has the deepest test coverage given its popularity. The project has had a slowdown in commit activity and open PRs in recent periods, which the health score reflects. API Design - Because every backend exposes the exact same Storage interface Django already defines, adopting django-storages typically requires only a settings-file change (DEFAULT_FILE_STORAGE or the newer STORAGES dict) and provider credentials — no changes to models, views, or templates that already use FileField/ImageField.