django-vite-rolling
A lean Django + Vite integration with rolling-deploy-safe manifest caching.
Roughly 100 lines of code. No React Refresh, no polyfills, no legacy bundle handling — just {% vite_scripts %}, {% vite_styles %}, and a management command that keeps Vite manifest caches consistent across rolling deploys.
Why this exists
Most Django + Vite integrations cache one manifest globally. On a rolling deploy, both the old and new app versions can serve requests simultaneously, each needing their own manifest. This package caches manifests under versioned Redis keys (vite_manifest:<RELEASE_VERSION>) and provides a management command to prune stale versions during deploys.
If you don't need versioned/rolling-deploy support, you probably want django-vite instead.
Install
pip install django-vite-rolling
Add to INSTALLED_APPS:
INSTALLED_APPS = [
# ...
"django_vite_rolling",
]
Requires django-redis configured as your default cache backend.
Configure
VITE = {
"manifest_path": BASE_DIR / "static" / ".vite" / "manifest.json",
"cache": not DEBUG,
}
All settings
| Key | Default | Description |
|---|---|---|
manifest_path |
(required) | Path to Vite's manifest.json |
cache |
True |
Whether to cache the loaded manifest in Redis (set False in dev) |
cache_key_prefix |
"vite_manifest" |
Redis key prefix; full key is <prefix>:<RELEASE_VERSION> |
dev_server_host |
None |
Dev server host. None → derive from request Host header (fallback localhost) |
dev_server_port |
3001 |
Dev server port |
dev_server_static_path |
"/static" |
Path prefix Vite serves from |
versions_to_keep |
5 |
How many recent release versions to retain manifests for |
version_setting |
"RELEASE_VERSION" |
Name of the Django setting holding the current release identifier |
versions_redis_key |
"recent-manifest-versions" |
Redis list key tracking recent versions |
redis_alias |
"default" |
django-redis alias to use |
Usage
In your base template:
{% load vite %}
<!DOCTYPE html>
<html>
<head>
{% vite_styles "src/main.ts" %}
</head>
<body>
{% vite_scripts "src/main.ts" %}
</body>
</html>
In DEBUG mode the tags inject Vite's HMR client and module URLs pointing at the dev server. In production they resolve the named entries through the manifest, including recursively-imported chunks and their CSS.
Post-deploy
Run after each deploy (e.g., in a release-phase / post-deploy hook):
python manage.py refresh_vite_manifest
This:
- Records
RELEASE_VERSIONin a Redis list of recent versions (truncated toversions_to_keep). - Scans for
vite_manifest:*keys whose suffix is not in the recent list and deletes them. - Loads the current manifest and caches it under
vite_manifest:<RELEASE_VERSION>.
If RELEASE_VERSION is empty, the command caches the manifest under the bare prefix and skips cleanup.
Development
pip install -e ".[test]"
pytest
License
MIT
1 maintainer
Release files for django-vite-rolling 0.1.1
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| django_vite_rolling-0.1.1.tar.gz | 11.7 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| django_vite_rolling-0.1.1-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 19.9 kB
Release files / django_vite_rolling-0.1.1.tar.gz
| Download URL | django_vite_rolling-0.1.1.tar.gz |
|---|---|
| Size | 11.7 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
3bcb55c030d300ac6d535526b85330a37457e9b20f0042a43fa8321899c111fc
|
|
BLAKE2b-256 checksum How to use checksums |
a0f29a3e070db49a899b3d7dcf24edf0adbdf6766c5236aa24d7ceb655ea63cf
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.12
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on May 26, 2026.
Transparency logRelease files / django_vite_rolling-0.1.1-py3-none-any.whl
| Download URL | django_vite_rolling-0.1.1-py3-none-any.whl |
|---|---|
| Size | 8.2 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
01ea1ebedf4f9f50b7c0deb80342171727af062abdcd4a91b350922f85830439
|
|
BLAKE2b-256 checksum How to use checksums |
61abfaf4c54855b7b1d7b3cc71ad37f09cb40c72748fc577c8050cb68f67a48e
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/6.1.0 CPython/3.13.12
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on May 26, 2026.
Transparency log
