Topic

Django

2 posts about Django. Every summary links to the original.

Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.

Newest first

Posts

Heroku
From Project to Productionized with Python
The post presents a hands-on tutorial for Python developers moving a local Django application into production on Heroku. It frames the work around 12-factor practices and covers repository hygiene, modular settings, continuous delivery stages, static-asset middleware, environment configuration, database provisioning, deployment, scaling, and troubleshooting. The configuration changes include excluding virtual environments, caches, SQLite data, and generated static files; moving settings.py to settings/base.py; updating DJANGO_SETTINGS_MODULE; adding Whitenoise; and supplying SECRET_KEY and a Heroku Postgres add-on. The deployment uses Git, the Heroku CLI, git push heroku main, and heroku ps:scale web=1, with heroku logs --tail and heroku run bash for diagnosis. The walkthrough concludes with the app deployed and accessible through heroku open.

Heroku
Django and Node together on Heroku
Django-based Heroku Connect needed realtime dashboard support through socket.io and Node.js, but Heroku apps could route traffic through only one dyno type. The team chose to run both stacks in one dyno using a runit buildpack and its sub-Procfile format: Node binds to PORT, while node-http-proxy forwards normal web requests to Gunicorn-hosted Django on 127.0.0.1:$DJANGO_PORT. This arrangement increases contention because processes share memory, CPU, and a filesystem, and it makes dyno logs less directly attributable; the team also flattened Procfiles into Procfile.local for Foreman-based local development. After running the architecture in production for a few months without issue, the team reported minimal proxy overhead and retained single-git-push deployment while establishing a path for websocket communication.

The best engineering reads, once a week.

Topic

2 posts about Django. Every summary links to the original.

Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.

Newest first

Heroku
From Project to Productionized with Python
The post presents a hands-on tutorial for Python developers moving a local Django application into production on Heroku. It frames the work around 12-factor practices and covers repository hygiene, modular settings, continuous delivery stages, static-asset middleware, environment configuration, database provisioning, deployment, scaling, and troubleshooting. The configuration changes include excluding virtual environments, caches, SQLite data, and generated static files; moving settings.py to settings/base.py; updating DJANGO_SETTINGS_MODULE; adding Whitenoise; and supplying SECRET_KEY and a Heroku Postgres add-on. The deployment uses Git, the Heroku CLI, git push heroku main, and heroku ps:scale web=1, with heroku logs --tail and heroku run bash for diagnosis. The walkthrough concludes with the app deployed and accessible through heroku open.

Heroku
Django and Node together on Heroku
Django-based Heroku Connect needed realtime dashboard support through socket.io and Node.js, but Heroku apps could route traffic through only one dyno type. The team chose to run both stacks in one dyno using a runit buildpack and its sub-Procfile format: Node binds to PORT, while node-http-proxy forwards normal web requests to Gunicorn-hosted Django on 127.0.0.1:$DJANGO_PORT. This arrangement increases contention because processes share memory, CPU, and a filesystem, and it makes dyno logs less directly attributable; the team also flattened Procfiles into Procfile.local for Foreman-based local development. After running the architecture in production for a few months without issue, the team reported minimal proxy overhead and retained single-git-push deployment while establishing a path for websocket communication.

The best engineering reads, once a week.