Django and Node together on Heroku

Summary

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.

Takeaways

1. 1

   Heroku permits only one dyno type to serve an app’s traffic, creating a choice between separate apps or co-locating Node.js and Django.

2. 2

   With node-http-proxy, Node.js binds to PORT and forwards normal web traffic to Django bound by Gunicorn at 127.0.0.1:$DJANGO_PORT.

3. 3

   Co-locating processes increases shared resource contention and complicates log attribution, but production ran without issue for a few months and proxy overhead was minimal.