use whitenoise or djangos ManifestStaticFilesStorage #2030

New Issue

adam · 2025-12-29T17:21:36+01:00

adam commented

2025-12-29 17:21:36 +01:00

Originally created by @paepke on GitHub (Sep 27, 2018).

Environment

Python version: netbox supported
NetBox version: 2.4.4
(Deployed on Kubernetes)

Proposed Functionality

Static files are handled more effective and compression algorithms of new browser are supported.
There is no additional need for configuring a webserver to serve the static files. See whitenoise documentation for a very detailed explanation why this is useful.
The static files are generated with a hashsum in its filename which makes the netbox version string suffix in templates obsolete. See also Django docs.
Using this feature makes it easier to deploy netbox to kubernetes as we don't need an extra webserver container to deliver the static assets.

Use Case

not applicable

Database Changes

none

External Dependencies

whitenoise

Originally created by @paepke on GitHub (Sep 27, 2018). ### Environment * Python version: netbox supported * NetBox version: 2.4.4 * (Deployed on Kubernetes) ### Proposed Functionality Static files are handled more effective and compression algorithms of new browser are supported. There is no additional need for configuring a webserver to serve the static files. See [whitenoise](http://whitenoise.evans.io/en/stable/) documentation for a very detailed explanation why this is useful. The static files are generated with a hashsum in its filename which makes the netbox version string suffix in templates obsolete. See also [Django docs](https://docs.djangoproject.com/en/2.1/ref/contrib/staticfiles/#manifeststaticfilesstorage). Using this feature makes it easier to deploy netbox to kubernetes as we don't need an extra webserver container to deliver the static assets. ### Use Case not applicable ### Database Changes none ### External Dependencies [whitenoise](http://whitenoise.evans.io/en/stable/)

adam closed this issue

2025-12-29 17:21:36 +01:00

adam commented

2025-12-29 17:21:37 +01:00

@jeremystretch commented on GitHub (Sep 27, 2018):

An httpd like nginx or Apache must be deployed in front of the Django WSGI service regardless. Static files are better served by these front ends directly.

@jeremystretch commented on GitHub (Sep 27, 2018): An httpd like nginx or Apache must be deployed in front of the Django WSGI service regardless. Static files are better served by these front ends directly.

adam commented

2025-12-29 17:21:37 +01:00

@paepke commented on GitHub (Sep 27, 2018):

Sure there is need for a service which terminates the wsgi service. Popular for example is gunicorn or uwsgi which itself exposes an http endpoint. If you already have an reverse proxy like nginx or varnish in front of your deployments there is no need for an additional webserver directly deployed with the application just to serve the static files. Its better to get the caching correct in your front facing infrastructure.
Even for really small deployment you don't have to bother with configuring a webserver with more than the proxy configuration.

@paepke commented on GitHub (Sep 27, 2018): Sure there is need for a service which terminates the wsgi service. Popular for example is gunicorn or uwsgi which itself exposes an http endpoint. If you already have an reverse proxy like nginx or varnish in front of your deployments there is no need for an additional webserver directly deployed with the application just to serve the static files. Its better to get the caching correct in your front facing infrastructure. Even for really small deployment you don't have to bother with configuring a webserver with more than the proxy configuration.

adam commented

2025-12-29 17:21:38 +01:00

@leoluk commented on GitHub (Jan 16, 2019):

+1 we want to deploy Netbox behind an existing frontend load balancer for a low-traffic instance. Using whitenoise would greatly reduce deployment complexity.

@leoluk commented on GitHub (Jan 16, 2019): +1 we want to deploy Netbox behind an existing frontend load balancer for a low-traffic instance. Using whitenoise would greatly reduce deployment complexity.

adam commented

2025-12-29 17:21:38 +01:00

@0x5a17ed commented on GitHub (May 10, 2019):

An httpd like nginx or Apache must be deployed in front of the Django WSGI service regardless. Static files are better served by these front ends directly.

A setup that involves whitenoise usually expects the front end server (in this example nginx or Apache) to cache responses from the application server. Proper caching information should be included in the response anyways to reduce network load anyways. Thus a request for static files should hit the application only once at worst.

Whitenoise also offers the functionality to create unique names for individual static assets. This avoids the issue of a stale cache when the original file changes. An extra benefit is reduced CPU load since the asset only needs to be compressed once. The front end server receives the compressed response and can store it in its original compressed state and feed the response to future requests. http://whitenoise.evans.io/en/stable/django.html#add-compression-and-caching-support

Instead of repeating the arguments in favor of whitenoise I'm just going to link to http://whitenoise.evans.io/en/stable/#infrequently-asked-questions.

@jeremystretch Please reevaluate your stance regarding whitenoise and serving static files by the application. I would even offer myself to implement the changes needed to integrate whitenoise since it would also simplify my setup.

@0x5a17ed commented on GitHub (May 10, 2019): > An httpd like nginx or Apache must be deployed in front of the Django WSGI service regardless. Static files are better served by these front ends directly. A setup that involves whitenoise usually expects the front end server (in this example nginx or Apache) to cache responses from the application server. Proper caching information should be included in the response anyways to reduce network load anyways. Thus a request for static files should hit the application only once at worst. Whitenoise also offers the functionality to create unique names for individual static assets. This avoids the issue of a stale cache when the original file changes. An extra benefit is reduced CPU load since the asset only needs to be compressed once. The front end server receives the compressed response and can store it in its original compressed state and feed the response to future requests. <http://whitenoise.evans.io/en/stable/django.html#add-compression-and-caching-support> Instead of repeating the arguments in favor of whitenoise I'm just going to link to <http://whitenoise.evans.io/en/stable/#infrequently-asked-questions>. @jeremystretch Please reevaluate your stance regarding whitenoise and serving static files by the application. I would even offer myself to implement the changes needed to integrate whitenoise since it would also simplify my setup.

adam commented

2025-12-29 17:21:38 +01:00

@paepke commented on GitHub (May 13, 2019):

We are already using django whitenoise in our production netbox setup:
INSTALLED_APPS.append('whitenoise.runserver_nostatic') MIDDLEWARE = ( 'whitenoise.middleware.WhiteNoiseMiddleware', #... )
and of course you need to add "whitenoise" to your requirements.txt

@paepke commented on GitHub (May 13, 2019): We are already using django whitenoise in our production netbox setup: ` INSTALLED_APPS.append('whitenoise.runserver_nostatic') MIDDLEWARE = ( 'whitenoise.middleware.WhiteNoiseMiddleware', #... ) ` and of course you need to add "whitenoise" to your requirements.txt

adam commented

2025-12-29 17:21:38 +01:00

@dgarros commented on GitHub (Jun 21, 2019):

I agree, it would be good if netbox could serve the static files directly and whitenoise looks like a good solution for it
I had to deploy netbox in a container orchestration system and the requirement for nginx was making things more complicated. The platform already had a lb/proxy as a service and it wasn't possible to add a specific configuration to it to support the static files.
Recently I had a similar experience with Heroku.

@dgarros commented on GitHub (Jun 21, 2019): I agree, it would be good if netbox could serve the static files directly and whitenoise looks like a good solution for it I had to deploy netbox in a container orchestration system and the requirement for nginx was making things more complicated. The platform already had a lb/proxy as a service and it wasn't possible to add a specific configuration to it to support the static files. Recently I had a similar experience with Heroku.

Sign in to join this conversation.

Branches Tags

main

update-changelog-comments-docs

feature-removal-issue-type

20911-dropdown

20239-plugin-menu-classes-mutable-state

21097-graphql-id-lookups

feature

fix_module_substitution

20923-dcim-templates

20044-elevation-stuck-lightmode

feature-ip-prefix-link

v4.5-beta1-release

20068-import-moduletype-attrs

20766-fix-german-translation-code-literals

20378-del-script

7604-filter-modifiers-v3

circuit-swap

12318-case-insensitive-uniqueness

20637-improve-device-q-filter

20660-script-load

19724-graphql

20614-update-ruff

14884-script

02496-max-page

19720-macaddress-interface-generic-relation

19408-circuit-terminations-export-templates

20203-openapi-check

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/netbox#2030