Hello Railway Support Team,

I am experiencing a critical issue where my Django application is not reading environment variables correctly in settings.py during the startup/deployment process, even though the variables are available at runtime.

What I have confirmed:

1. I have created a test view (/products/test-upload/) that uses the cloudinary library to directly upload a file. This view works perfectly, which proves my CLOUDINARY_... secret variables are correct and the server has network access to the Cloudinary API.

2. I have created a diagnostic view (/products/check-storage/) to check the value of DEFAULT_FILE_STORAGE. It consistently shows "FileSystemStorage", meaning my production settings are being ignored.

3. I have tried multiple if/else conditions in settings.py (checking DEBUG, checking a custom DJANGO_ENV variable) to switch between production and development settings, but the else block (development) is always chosen.

4. Most importantly, I even removed all if/else logic and hardcoded DEFAULT_FILE_STORAGE = 'cloudinary_storage.storage.MediaCloudinaryStorage', but my diagnostic view still reports "FileSystemStorage".

This last point proves that the code in my settings.py file is being ignored or overridden during the application startup process on your platform. I have added print() statements to my settings.py file, and the deployment logs confirm that the variables are not being read as expected at that stage.

Could you please investigate why the environment variables might not be available to the Django settings.py module at the exact moment of startup? Is there a caching mechanism or a specific startup procedure I need to be aware of?

Thank you.