Skip to content

fix: serve static files in production via deploy.sh#48

Merged
emidiovaleretto merged 1 commit into
mainfrom
fix/serve-static-files
Jun 14, 2026
Merged

fix: serve static files in production via deploy.sh#48
emidiovaleretto merged 1 commit into
mainfrom
fix/serve-static-files

Conversation

@emidiovaleretto

Copy link
Copy Markdown
Owner

Context

In production (DEBUG=False) Django doesn't serve static files automatically.
The DRF browsable API and admin were rendering without CSS. WhiteNoise was
already configured (middleware + storage), but collectstatic was never run.

What

  • Add a deploy.sh script that runs collectstatic before starting gunicorn
  • Point the Dockerfile's CMD to the script
  • Use ${PORT} so the bind works both on Railway (injected PORT) and locally
  • Ignore the generated staticfiles/ directory in git

Why

Static collection must happen at container start, not build time, because the
production settings require environment variables that only exist at runtime.
Running it in deploy.sh (with set -e to fail fast, and exec for proper
signal handling) keeps the startup sequence explicit and easy to extend.

How it works

  • deploy.sh: set -ecollectstatic --noinputexec gunicorn
  • WhiteNoise serves the collected files (already configured via
    CompressedManifestStaticFilesStorage)

How to verify

Tested locally simulating production (DEBUG=False, gunicorn via the script):
the DRF browsable API renders with CSS. After merge, confirm the same at
api.simlog.app.br/api/auth/register/.

@emidiovaleretto emidiovaleretto self-assigned this Jun 14, 2026
@emidiovaleretto emidiovaleretto merged commit b7640a7 into main Jun 14, 2026
2 checks passed
@emidiovaleretto emidiovaleretto deleted the fix/serve-static-files branch June 14, 2026 15:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant