I've been working with a fork of heroku-buildpack-nginx with the goal of having an nginx-based buildpack that can be fully enabled with a heroku buidlpack:add command, without requiring any changes in the application config or code. Such a mode turned out to be possible with the following approach:
No Procfile modification
nginx can be started as a background process from a .profile.d script (https://devcenter.heroku.com/articles/buildpack-api#profile-d-scripts). This removes the need to modify the Procfile to launch the start-nginx script (as with the start-nginx script, some care is needed to properly terminate a dyno when either nginx or the web app terminates).
No need to listen on a Unix domain socket
The .profile.d script can remap the $PORT environment variable to any other TCP port and pass the remapped port to the application. nginx can then listen on the original $PORT and proxy the requests to the remapped local port instead of the Unix domain socket. Heroku runtime guarantees that only $PORT is externally accessible, external traffic to any other port is filtered out by a firewall https://devcenter.heroku.com/articles/dynos#common-runtime-networking.
No need to create /tmp/app-initialized when the backend is ready for traffic
All three supported Heroku stacks include the netcat tool that can be used to wait in a loop for the app to start accepting requests on a local TCP port.
I open this issue for a reference if you ever consider supporting such a mode; please feel free to close it. For reference, here is my .profile.d script that implements this mode (it includes code specific to my buildpack, not intended to be generic).
Hi,
I've been working with a fork of heroku-buildpack-nginx with the goal of having an nginx-based buildpack that can be fully enabled with a
heroku buidlpack:add
command, without requiring any changes in the application config or code. Such a mode turned out to be possible with the following approach:No Procfile modification
nginx can be started as a background process from a
.profile.d
script (https://devcenter.heroku.com/articles/buildpack-api#profile-d-scripts). This removes the need to modify theProcfile
to launch thestart-nginx
script (as with thestart-nginx
script, some care is needed to properly terminate a dyno when either nginx or the web app terminates).No need to listen on a Unix domain socket
The
.profile.d
script can remap the$PORT
environment variable to any other TCP port and pass the remapped port to the application. nginx can then listen on the original$PORT
and proxy the requests to the remapped local port instead of the Unix domain socket. Heroku runtime guarantees that only$PORT
is externally accessible, external traffic to any other port is filtered out by a firewall https://devcenter.heroku.com/articles/dynos#common-runtime-networking.No need to create
/tmp/app-initialized
when the backend is ready for trafficAll three supported Heroku stacks include the
netcat
tool that can be used to wait in a loop for the app to start accepting requests on a local TCP port.I open this issue for a reference if you ever consider supporting such a mode; please feel free to close it. For reference, here is my .profile.d script that implements this mode (it includes code specific to my buildpack, not intended to be generic).