Best examples of Django static files example: practical guide for 2025

If you build web apps with Django, you live with static files every day: CSS, JavaScript, images, fonts, and now even front-end build artifacts. Yet many tutorials stay abstract and skip over real-world patterns. This guide fixes that by walking through concrete, working examples of Django static files example: practical guide scenarios you actually hit in production. We’ll look at examples of how to wire up `STATIC_URL`, organize static directories for multiple apps, integrate modern build tools, and serve assets efficiently in development and production. Along the way, you’ll see examples include versioned filenames, per-tenant branding, and CDN integration that reflect how Django projects are built in 2024–2025, not 2012. If you’ve ever fought with missing CSS in production or broken paths after a deploy, this guide is for you. The goal: give you practical, copy-paste ready patterns for Django static files that are easy to understand, easy to debug, and don’t collapse the moment you add a second app or a front-end pipeline.
Written by
Jamie
Published

Before any theory, let’s walk through real examples of Django static files example: practical guide setups you’re likely to use in a 2024–2025 codebase. Think of these as patterns you can mix and match.

Example of a minimal but production-ready static files setup

Start with a small project that has one app (blog) and a global stylesheet.

Directory layout:

yourproject/
  manage.py
  yourproject/
    settings.py
    urls.py
    wsgi.py
  blog/
    templates/
      blog/
        post_list.html
    static/
      blog/
        css/
          blog.css

settings.py:

from pathlib import Path

BASE_DIR = Path(__file__).resolve().parent.parent

STATIC_URL = "/static/"

STATICFILES_DIRS = [
    BASE_DIR / "static",  # optional global static dir
]

STATIC_ROOT = BASE_DIR / "staticfiles"  # where collectstatic will dump files

INSTALLED_APPS = [
    "django.contrib.staticfiles",
    "blog",
#    # ...
]

Template usage (blog/templates/blog/post_list.html):

{% load static %}
<!doctype html>
<html>
  <head>
    <link rel="stylesheet" href="{% static 'blog/css/blog.css' %}">
  </head>
  <body>
    <h1>My Blog</h1>
  </body>
</html>

This is one of the best examples of a simple config that still works in production: STATIC_ROOT is defined for collectstatic, the app has its own static/blog/ directory, and the template uses {% static %} instead of hardcoding paths.

Examples include app-specific vs global static directories

Real projects rarely have just one app. You might have accounts, dashboard, and marketing all shipping their own CSS and JS. Here are two patterns.

App-specific static files (recommended for most code):

accounts/
  static/
    accounts/
      css/
        login.css
      js/
        login.js

Template:

{% load static %}
<link rel="stylesheet" href="{% static 'accounts/css/login.css' %}">
<script src="{% static 'accounts/js/login.js' %}"></script>

This pattern keeps assets close to the code that uses them. It’s one of the best examples of maintainable organization when your team grows.

Global static directory for shared assets:

yourproject/
  static/
    css/
      base.css
    js/
      analytics.js

Add in settings.py:

STATICFILES_DIRS = [
    BASE_DIR / "static",
]

Template usage:

{% load static %}
<link rel="stylesheet" href="{% static 'css/base.css' %}">
<script src="{% static 'js/analytics.js' %}"></script>

In many examples of Django static files example: practical guide setups, teams combine both approaches: app-specific for feature code, global for site-wide layout and analytics.

Examples of Django static files example: practical guide for development vs production

Static files behave very differently in development and production. Understanding that split is one of the best examples of how to avoid “works on my machine” bugs.

Development: using runserver and DEBUG=True

In development, with DEBUG = True and django.contrib.staticfiles installed, runserver automatically serves static files.

Example dev settings:

DEBUG = True
STATIC_URL = "/static/"
STATICFILES_DIRS = [BASE_DIR / "static"]
STATIC_ROOT = BASE_DIR / "staticfiles"  # still define this for collectstatic

You don’t need a separate web server for static files in this mode. You can run:

python manage.py runserver

and access http://127.0.0.1:8000/static/css/base.css if the file exists. This is one example of Django static files example: practical guide behavior that “just works” for local development.

Production: collectstatic, hashed filenames, and a front-end server

In production, Django expects a different story.

Example production settings:

DEBUG = False

STATIC_URL = "/static/"
STATIC_ROOT = BASE_DIR / "staticfiles"

STATICFILES_STORAGE = (
    "django.contrib.staticfiles.storage.ManifestStaticFilesStorage"
)

When you run:

python manage.py collectstatic

Django copies all discovered static files into STATIC_ROOT, renaming them with hashes (for example, base.css becomes base.4c3e2a1.css). This is one of the best examples of cache-busting in practice: browsers can cache aggressively without you worrying about stale files.

Then you configure your front-end server (Nginx, Apache, or a CDN) to serve STATIC_ROOT. The official Django docs show production patterns here:

  • Django static files how-to: https://docs.djangoproject.com/en/stable/howto/static-files/

Those docs are not a step-by-step cookbook, so pairing them with the examples of Django static files example: practical guide patterns in this article gives you a more practical path.

Example of integrating modern front-end tooling (Vite, Webpack, or esbuild)

By 2025, many Django teams use a build tool like Vite or Webpack. Here’s a realistic pattern.

Directory layout:

yourproject/
  frontend/
    package.json
    vite.config.js
    src/
      main.js
      styles/
        main.css
  static/
    build/  # output of your bundler

Vite config example:

// vite.config.js
import { defineConfig } from 'vite';
import { resolve } from 'path';

export default defineConfig({
  build: {
    outDir: resolve(__dirname, '../static/build'),
    rollupOptions: {
      input: {
        main: resolve(__dirname, 'src/main.js'),
      },
    },
  },
});

Django settings:

STATIC_URL = "/static/"
STATICFILES_DIRS = [BASE_DIR / "static"]
STATIC_ROOT = BASE_DIR / "staticfiles"

Template usage:

{% load static %}
<script type="module" src="{% static 'build/assets/main.js' %}"></script>
<link rel="stylesheet" href="{% static 'build/assets/main.css' %}">

This is one of the best examples of Django static files example: practical guide integration with a modern bundler: the bundler writes into static/build, Django treats those as any other static files, and collectstatic pulls them into STATIC_ROOT for production.

Real examples of per-tenant or per-brand static files

Multi-tenant SaaS apps often need different logos, colors, or fonts per customer. You can do this without getting lost in a mess of directories.

Directory layout:

static/
  themes/
    default/
      css/theme.css
      img/logo.png
    acme/
      css/theme.css
      img/logo.png
    beta_inc/
      css/theme.css
      img/logo.png

settings.py:

STATICFILES_DIRS = [BASE_DIR / "static"]

Context processor example:

## yourproject/context_processors.py

def theme_static_prefix(request):
    tenant = getattr(request, "tenant", None)
    slug = getattr(tenant, "slug", "default")
    return {"THEME_PREFIX": f"themes/{slug}"}

Add the context processor:

TEMPLATES[0]["OPTIONS"]["context_processors"].append(
    "yourproject.context_processors.theme_static_prefix"
)

Template usage:

{% load static %}
<link rel="stylesheet" href="{% static THEME_PREFIX|add:'/css/theme.css' %}">
<img src="{% static THEME_PREFIX|add:'/img/logo.png' %}" alt="Logo">

This is a clean example of Django static files example: practical guide for multi-tenant branding without branching logic in every template.

Examples include CDN integration and performance patterns

If you care about performance (and you should), a CDN is often worth it. The pattern is simple: keep STATIC_ROOT local, but point STATIC_URL to your CDN domain.

Example production settings with CDN:

STATIC_URL = "https://cdn.example.com/static/"
STATIC_ROOT = BASE_DIR / "staticfiles"

Your deployment flow:

  • Run python manage.py collectstatic on your build server.
  • Sync STATIC_ROOT to your CDN origin (for example, AWS S3 or another storage bucket).
  • Let the CDN serve /static/ paths globally.

This is a real example of Django static files example: practical guide in a performance-focused stack: Django never touches static files in production, the CDN does all the heavy lifting.

If you want to go deeper on web performance theory (not Django-specific), Google’s Web Fundamentals and related education content from universities like Harvard offer good background:

  • Web performance guidance: https://web.dev/fast/
  • Harvard CS50 Web notes: https://cs50.harvard.edu/web/2020/notes/0/

Example of testing static files in CI

Static files break silently more often than you’d like. A simple CI step can catch missing files before deploy.

Example GitHub Actions snippet:

name: Django CI

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:

      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.12'

      - run: pip install -r requirements.txt
      - run: python manage.py collectstatic --noinput --dry-run
      - run: python manage.py test

Using --dry-run still forces Django to discover static files and will error out on some misconfigurations. This is a small but effective example of Django static files example: practical guide for CI that saves you from broken production CSS.

Security and static files: real-world considerations

Static files themselves are usually not where your biggest security risks live, but configuration mistakes can leak more than you intended.

Some practical patterns:

  • Keep MEDIA_ROOT (user uploads) separate from STATIC_ROOT. Do not mix them.
  • Never place private configuration files anywhere under a directory that your web server exposes.
  • Use hashed filenames (via ManifestStaticFilesStorage) to avoid serving mixed versions of JS and CSS that might break CSRF or other protection mechanisms.

For general web security guidance, resources from bodies like NIST are helpful context:

  • NIST application security overview: https://csrc.nist.gov/projects/application-security

These aren’t Django-specific, but they frame why you should treat static configuration with care.

FAQ: short, practical answers

What are some real examples of Django static files in a typical project?

Real examples include global stylesheets (static/css/base.css), app-specific JS (blog/static/blog/js/post_list.js), logos and icons (static/img/logo.svg), fonts (static/fonts/), and build artifacts from tools like Vite (static/build/main.js). All of them are collected into STATIC_ROOT via collectstatic for production.

Can you give an example of configuring Django static files for production?

Yes. A common example of production config is:

DEBUG = False
STATIC_URL = "/static/"
STATIC_ROOT = BASE_DIR / "staticfiles"
STATICFILES_STORAGE = (
    "django.contrib.staticfiles.storage.ManifestStaticFilesStorage"
)

Then you run python manage.py collectstatic during deployment and point Nginx or your CDN to serve files from STATIC_ROOT.

How do I organize static files across multiple Django apps?

A practical approach is: each app owns its own static/<app_label>/ directory for feature-specific files, and you keep shared assets in a project-level static/ directory added through STATICFILES_DIRS. This gives you clear ownership while still supporting shared layouts and branding.

Why do my static files work in development but not in production?

Classic reasons include: DEBUG set to False without a proper web server or CDN serving STATIC_ROOT, missing collectstatic in your deploy script, or misconfigured STATIC_URL that doesn’t match your front-end server. Comparing your setup to the examples of Django static files example: practical guide patterns above usually reveals what’s missing.

Do I need a CDN for Django static files?

You don’t need one for every project, but once you care about global performance, cache control, and offloading bandwidth from your app servers, a CDN becomes attractive. The example with STATIC_URL = "https://cdn.example.com/static/" is a realistic starting point for most teams.

If you take nothing else from these examples of Django static files example: practical guide patterns, remember this: keep assets close to the code that uses them, always define STATIC_ROOT, use {% static %} in templates, and let a front-end server or CDN do the heavy lifting in production. The rest is just picking the patterns that match your stack and your team.

Related Topics

Best examples of Django template rendering examples in real projects

Read more

Best examples of Django static files example: practical guide for 2025

Read more

Best examples of examples of Django model relationships example in real projects

Read more

Real-World Examples of Django REST Framework Examples for 2025

Read more

Real-world examples of examples of Django middleware example patterns

Read more

Practical examples of Django authentication examples for beginners

Read more

Explore More Django Code Snippets

Discover more examples and insights in this category.

View All Django Code Snippets