# django-storages: Cloud and Remote Storage Backends for Django

> django-storages is a library that replaces Django's default file storage with backends for S3, Azure Blob Storage, Google Cloud Storage, Dropbox, SFTP, and Apache Libcloud. It installs through pip and integrates with Django's DEFAULT_FILE_STORAGE setting without requiring changes to model code.

**jschneier/django-storages** — https://django-storages.readthedocs.io/

- Repository: https://github.com/jschneier/django-storages
- Stars: 2,960 · Forks: 896
- Language: Python
- License: BSD-3-Clause
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/jschneier-django-storages

## What django-storages Does and Who It Is For

Django's default file storage writes uploaded files to the local filesystem. For production deployments that run on ephemeral infrastructure, use multiple application instances, or need files accessible through a CDN, local storage is inadequate. django-storages solves this by providing Django-compatible storage backend classes for the most common remote storage services.

The library is intended for Django developers who need to swap out the local filesystem backend for cloud storage without rewriting model code. Because it implements Django's storage API, any model that uses FileField or ImageField continues to work without changes once the backend is configured. The work is in configuring credentials and settings for the chosen backend.

The project began as a fork of django-storages-redux and became the official package on PyPI in February 2016. It currently supports Django 4.2, 5.2, and 6.0 according to the Trove classifiers in pyproject.toml, and requires Python 3.10 through 3.14.

## Supported Backends and Their Dependencies

Each backend is an optional extra in pyproject.toml, meaning only the dependencies for the backend you actually use need to be installed. The available backends and their pip extras are:

- S3 or boto3: `boto3>=1.4.4` for Amazon S3 and S3-compatible services
- azure: `azure-core>=1.13` and `azure-storage-blob>=12` for Azure Blob Storage
- google: `google-cloud-storage>=1.36.1` for Google Cloud Storage
- dropbox: `dropbox>=7.2.1` for Dropbox
- sftp: `paramiko>=1.15` for SFTP
- libcloud: `apache-libcloud` for any service that Apache Libcloud supports

Installing a backend extra pulls in only the packages that backend needs. The s3 and boto3 extras both resolve to boto3. The libcloud extra is the most permissive, covering any service Apache Libcloud supports, at the cost of a more generic feature set.

The core library itself depends only on Django. No extra packages are pulled in unless you specify one of the backend extras. This keeps the install small when only one backend is needed.

The documentation at django-storages.readthedocs.io covers the settings required for each backend, including credential configuration, bucket or container names, access control settings, and options for generating signed URLs for private files.

## Installing django-storages

Installing from PyPI:

```bash
pip install django-storages
```

Installing from the master branch for unreleased bugfixes:

```bash
pip install -e 'git+https://github.com/jschneier/django-storages.git#egg=django-storages'
```

After installation, add the chosen backend class to DEFAULT_FILE_STORAGE (Django 4.x) or STORAGES (Django 5.x and later) in your settings file. The exact setting name and the class path depend on the backend; the documentation provides the correct value for each one.

Security vulnerabilities should not be reported as public GitHub issues. The README directs security reports to the Tidelift security contact, which coordinates disclosure and fixes. Tidelift also provides commercial support subscriptions for enterprise users who need service level agreements and long-term maintenance guarantees for the library.

## How django-storages Integrates with Django

Django's storage system is built around a pluggable backend API defined in django.core.files.storage. Any class that implements this API can be used as the file storage backend. django-storages provides implementations of that API for each remote service it supports.

Once the backend is configured, Django's file handling works without changes. FileField.url returns the correct URL for the configured storage service. FileField.save writes to the remote backend. FileField.delete removes the file from the remote service. The storage system handles chunked uploads, URL generation, and the abstraction between local and remote paths transparently.

For S3, the boto3 backend supports private file access through signed URLs, custom domain names, query string authentication, and public-read ACLs. The Azure backend supports similar options for Azure CDN integration. The exact options per backend are documented in the project's ReadTheDocs pages rather than in the README, which is intentionally brief.

The project's setup.py calls setup() without arguments, with all configuration living in pyproject.toml. The storages package contains a backends/ subdirectory with a separate Python module for each supported service.

## Where django-storages Falls Short

django-storages handles file upload and retrieval. It does not handle image resizing, video transcoding, CDN cache invalidation, or media pipeline management. Teams who need those features typically add a separate library alongside django-storages, or use a service like Cloudinary that provides its own Django storage backend outside this library.

The libcloud backend covers a wide range of services through Apache Libcloud's provider list, but it is a general-purpose layer that may not support service-specific features available through the dedicated backends. For S3, the boto3 backend directly exposes S3-specific settings like ACLs, encryption, and storage class. The libcloud backend does not have equivalent service-specific tuning.

MinIO is a popular self-hosted S3-compatible object store. The S3 backend in django-storages works with MinIO through endpoint URL configuration, but the README does not document MinIO explicitly. The django-storages.readthedocs.io documentation covers this use case.

The last push to the repository was on 2026-08-02. The repository is not archived and has no GitHub releases; version history is tracked in CHANGELOG.rst.

## Alternatives: django-storages Against Vendor-Native Solutions

Every major cloud provider publishes its own Python SDK with Django integration examples. AWS publishes boto3, which can be used directly with Django without django-storages by writing a custom storage class against the S3 API. The same is true for the Azure SDK and the Google Cloud Storage client library.

The difference is that writing and maintaining a custom storage backend class requires understanding Django's storage API, handling edge cases like missing files and permission errors, and keeping the implementation compatible as Django's storage API evolves. django-storages absorbs that maintenance cost for the backends it covers.

For teams using only a single cloud provider and needing features that go beyond what django-storages exposes, the vendor SDK approach gives more direct access to provider-specific functionality. For teams that want a maintained, documented, BSD-licensed implementation that covers multiple backends under one install, django-storages is the practical choice.

## Conclusion

django-storages is the standard choice when a Django application needs to store user-uploaded files on S3, Azure Blob Storage, Google Cloud Storage, or another remote backend. It has been the official successor on PyPI since February 2016 and covers the backends that the majority of Django deployments need. It is not a general-purpose cloud SDK, a media transformation service, or a CDN integration layer. Before adding it, confirm that the backend you need is listed in pyproject.toml, since backends outside that set (such as MinIO with S3-compatible paths or on-premises storage) may need additional configuration that the documentation covers at django-storages.readthedocs.io.

## FAQ

### How do I use django-storages with S3?

Install with `pip install django-storages[s3]` to include boto3, then set DEFAULT_FILE_STORAGE or STORAGES in your Django settings to the S3Boto3Storage class and configure your AWS credentials and bucket name. The full settings reference is at django-storages.readthedocs.io.

### What is django-storages?

django-storages is a library that provides Django-compatible storage backend classes for remote storage services including Amazon S3, Azure Blob Storage, Google Cloud Storage, Dropbox, and SFTP. It replaces Django's default local filesystem storage without requiring changes to model code.

### What is a django-storages alternative?

Vendor-native Python SDKs (boto3 for AWS, the Azure SDK, the Google Cloud Storage client) can be wrapped in a custom Django storage class. That approach requires maintaining the implementation yourself; django-storages provides a maintained, documented alternative for the most common backends.

## Sources

- [Issues](https://github.com/jschneier/django-storages/issues)
- [jschneier/django-storages on GitHub](https://github.com/jschneier/django-storages)
- [License: BSD-3-Clause](https://github.com/jschneier/django-storages/blob/master/LICENSE)
- [README](https://github.com/jschneier/django-storages/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/jschneier-django-storages