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.
The build_command is run once when commits are pushed to your repo, or in some cases when changes (ex. environment variables or changing the build command itself) are made to your apps configuration.
A good option for running migrations is the pre-deploy and post-deploy job types. These are run just before or just after launching your application containers. If the job fails, your app will be rolled back to its previous version. These run in a separate, short-lived container from your application so they have their own resource allocation and won’t steal CPU or memory from your application.
We strongly recommend against running migrations directly in the service container via run_command (ex. npm run migrate && npm run start). Running in the service container means the migration could run several times (potentially concurrently) based on the component’s instance count. Also, this (anti-)pattern slows the start of your application, which could potentially cause it to fail health checks at deploy, or if ever restarted.
See: How-to Manage Jobs for details on creating and configuring jobs.
I’ll file an internal feature request for directly supporting the release procfile option.