Set WEB_CONCURRENCY_SET_BY=heroku/ruby if WEB_CONCURRENCY gets auto-set #1700
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The Ruby buildpack sets the `WEB_CONCURRENCY` env var at app boot based on the current dyno size if the (deprecated) `SENSIBLE_DEFAULTS` mode is enabled, so long as the user hasn't specified a custom value via the app's config vars. Now, in addition to setting the `WEB_CONCURRENCY` env var, the buildpack will also set `WEB_CONCURRENCY_SET_BY=heroku/ruby` to allow the app, other boot time scripts, or humans more easily differentiate between a user and a buildpack provided `WEB_CONCURRENCY` (and determine which buildpack actually set it). In addition to assisting with debugging, this allows for UX improvements in other buildpacks such as the PHP buildpack, which can now check for `WEB_CONCURRENCY_SET_BY` in its boot time Apache/Nginx `heroku-php-...` scripts to ignore `WEB_CONCURRENCY` in cases where users have ordered the buildpacks on their app in the wrong order (the "primary" language is supposed to be listed last, otherwise the wrong concurrency value will be used). See also: heroku/heroku-buildpack-nodejs#932 heroku/heroku-buildpack-python#2015 GUS-W-20882005
Contributor
|
Thanks! I can approve and merge this around the 24th. I think we should track usage and deprecate/remove instead of continuing to add fetures here. This feature was never promoted and I doubt it's highly used. Other libraries like puma have their own |
edmorley
added a commit
to heroku/heroku-buildpack-python
that referenced
this pull request
Jan 13, 2026
The Python buildpack sets the `WEB_CONCURRENCY` env var at app boot based on the current dyno size, so long as the user hasn't specified a custom value via the app's config vars. Now, in addition to setting the `WEB_CONCURRENCY` env var, the buildpack will also set `WEB_CONCURRENCY_SET_BY=heroku/python` to allow the app, other boot time scripts, or humans more easily differentiate between user and buildpack provided `WEB_CONCURRENCY` values (plus determine which buildpack actually set it). In addition to assisting with debugging, this allows for UX improvements in other buildpacks such as the PHP buildpack, which can now check for `WEB_CONCURRENCY_SET_BY` in its boot time Apache/Nginx `heroku-php-...` scripts - helping detect the case where users have ordered the buildpacks on their app in the wrong order. (The "primary" language is supposed to be listed last, otherwise the wrong concurrency value will be used.) See also: - heroku/heroku-buildpack-php#883 - heroku/heroku-buildpack-nodejs#932 - heroku/heroku-buildpack-ruby#1700 GUS-W-20866598.
Contributor
Author
|
Yeah, totally realize it's a deprecated feature for the Ruby buildpack, I just figured we'd still want parity across buildpacks for this case, at least until |
Signed-off-by: Richard Schneeman <[email protected]>
This feature is deprecated, let's see how many people still rely on it.
schneems
force-pushed
the
web-concurrency-set-by
branch
from
736566b to
8114279
Compare
schneems
approved these changes
Jan 26, 2026
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The Ruby buildpack sets the
WEB_CONCURRENCYenv var at app boot based on the current dyno size if the (deprecated)SENSIBLE_DEFAULTSmode is enabled, so long as the user hasn't specified a custom value via the app's config vars.Now, in addition to setting the
WEB_CONCURRENCYenv var, the buildpack will also setWEB_CONCURRENCY_SET_BY=heroku/rubyto allow the app, other boot time scripts, or humans more easily differentiate between a user and a buildpack providedWEB_CONCURRENCY(and determine which buildpack actually set it).In addition to assisting with debugging, this allows for UX improvements in other buildpacks such as the PHP buildpack, which can now check for
WEB_CONCURRENCY_SET_BYin its boot time Apache/Nginxheroku-php-...scripts to ignoreWEB_CONCURRENCYin cases where users have ordered the buildpacks on their app in the wrong order (the "primary" language is supposed to be listed last, otherwise the wrong concurrency value will be used).See also:
heroku/heroku-buildpack-nodejs#932
heroku/heroku-buildpack-php#883
heroku/heroku-buildpack-python#2015
GUS-W-20882005