Researching this more (I'm not a heavy Python or Django user), it looks like this is by design, and that Django only serves static files when running locally in debug/local development mode for ease while developing and for production it expects the web server to serve requests to static files.

Looks like there are packages such as whitenoise however we could add that would serve the files though. I'm not sure what direction is best for the Docker deployment.

@adamlphillips @evnsio thoughts?

@AshleyPoole 👋

From my (fairly limited) experience with Django, production setups tend to use a reverse proxy like NGINX in front of Django/the WSGI server, and use that to serve static files, as it's far more efficient than having Python/Django do it, especially when there's a lot of traffic, as these setups can optimise with things like caching.

I guess serving static content with the built in dev server would be fine for most use cases - once #33 is resolved it'll be up to the user what they want to do, as they'll be maintaining their own Django installation and just importing the response app

Ok - Thanks @milesbxf :-)

We spent yesterday playing around with the project and trying to do this in the "simplest" way. Without a huge modification/setting up a build pipeline.

Our solution currently has included adding this snippet to the startup.sh script.

python manage.py collectstatic

This will then generate the static files inside the root of the application which we can share with a nginx container via a kubernetes emptyDir volume.

https://gist.github.com/BradErz/df1833e1d902633b5c3657046617cceb

Im open to putting this in a PR if you agree on the solution?

With this customization as well it would enable some other basic security features that could be added fairly simply to the nginx config. (SSO etc for the incident page)

What do you think @AshleyPoole / @milesbxf

EDIT: also thinking about this i dont see a reason why it wouldn't also work in the standard docker-compose file either, just an extra nginx container doing the same thing as my kubernetes example.

Hey @BradErz,

That looks like a good solution for now, but could you hold off the PR? We'll be merging a significant change to Response pretty soon (release-0.1 branch) which turns Response into a pip-installable, standalone Django app which you can import into your own Django project:

INSTALLED_APPS = [
    ...
    'response.apps.ResponseConfig',
]

This means it'll be up to people to configure their own Django instance however they want. For example, internally at Monzo we're deploying to Google App Engine and running a python manage.py collectstatic in CI, but other folks might prefer to copy static files to an NGINX container in Kubernetes or even to S3 or something.

This also applies to SSO - once you're configuring your own Django project, it becomes really easy to set things up like python-social-auth, which allows using Google, Twitter, Github etc. for SSO