Per-process config vars
- Dominant language
- No language data
- Stars
- 225
- Forks
- 19
- PR merge metrics
- No merged PRs in 30d
Description
### Required Terms
- [X] I agree to follow this project's [Code of Conduct](https://github.com/heroku/roadmap/blob/main/CODE_OF_CONDUCT.md)
- [X] I have read and accept the [Salesforce Program Agreement](https://www.salesforce.com/company/program-agreement/)
### What service(s) is this request for?
Heroku dynos
### Tell us about what you're trying to solve. What challenges are you facing?
Often times, different processes need different configuration, particularly when it comes to scaling different types of processes independently. Puma and Sidekiq, combined with Rails' threading configuration and DB pools is a good example.
The standard configuration for a Rails app is to drive concurrency based on the `WEB_CONCURRENCY` and `RAILS_MAX_THREADS` environment variables, which are used to control things like Puma workers / threads, Sidekiq concurrency, and DB connection pool size. However, the concurrency someone chooses for each of these will likely vary significantly per-process.
Since each process can run on different dyno types, how you scale a process within a dyno will not be the same across processes. Puma may make sense to configure with `WEB_CONCURRENCY` of `8`, and `RAILS_MAX_THREADS` of `5`, while Sidekiq may make sense to configure with a `RAILS_MAX_THREADS` of `10`.
Currently, we achieve this by explicitly setting `RAILS_MAX_THREADS` in our `Procfile` for certain process types, and leave the Heroku-managed `WEB_CONCURRENCY` and `RAILS_MAX_THREADS` config vars as the ones that control our web process.
It would be preferred to be able to manage these entirely through Heroku config vars, to take advantage of no-build configuration updates across all configurations.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.