Scale up as you grow — whether you're running one virtual machine or ten thousand.

From GPU-powered inference and Kubernetes to managed databases and storage, get everything you need to build, scale, and deploy intelligent applications.

This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.
Accepted Answer
You could also choose to have two apps on the same branch, one for staging and one for release. The staging one could be set with Autodeploy (Settings tab) enabled and the release one could be set with Autodeploy disabled. If needed, these could also have different environment variables. Then you can have Staging always up to date with your branch and Release only updated when you manually push the Deploy button. But technically, this will still rebuild the slug when going to production.
The staging area contains the “next” version of the application and is used for final stress testing and client/manager approvals before going live.
Just curious, are there any updates as the answer is now two years old? I mean considering Heroku pipeline replacement using an app platform here.