collectstatic para producción

In development Django finds and serves static files for you. In production that auto-serving is off, so you must gather assets into one place first.

The collectstatic command copies every static file from every app into a single output folder, ready for a web server to serve fast.

collectstatic needs a destination. The STATIC_ROOT setting points to the single folder where all collected files will be written.

Never set STATIC_ROOT to a folder you edit by hand. It is a generated output directory, rebuilt on every collectstatic run.

collectstatic pulls from each app's static folder and from STATICFILES_DIRS, merging them all into STATIC_ROOT in one pass.

By default it asks before overwriting. In a deploy script add --noinput so it runs unattended without waiting for you.

Run collectstatic on every deploy, after pulling new code. New or changed CSS and JS only reach users once they are collected.

The ManifestStaticFilesStorage backend adds a content hash to each filename, so browsers always fetch the newest version after a deploy.

Django itself does not serve STATIC_ROOT in production. A web server like Nginx or a tool like WhiteNoise delivers those files instead.

Add --ignore patterns to skip files you do not want copied, like source maps or scratch files left in a static folder.

Since STATIC_ROOT is generated, add it to .gitignore. You commit your source assets, not the collected copies.

Let us confirm the role of collectstatic.

You saw that production needs collectstatic to merge assets into STATIC_ROOT, that you run it each deploy, and that a web server serves the result. 🚀