Heroku

Example follows the syntax for Heroku CLI v9.0.0 or later. If you’re on v8.11.5 or earlier, use the command:$ heroku addons:create heroku-postgresql:standard-0 --fork HEROKU_POSTGRESQL_CHARCOAL_URL --app example-app$ heroku addons:create heroku-postgresql:standard-0 --app example-app -- --fork HEROKU_POSTGRESQL_CHARCOAL_URLAdding heroku-postgresql:standard-0 on example-app... done, v71 ($50/mo)Attached as HEROKU_POSTGRESQL_SILVER_URLDatabase will become available after it completes forkingUse `heroku pg:wait` to track statusThe heroku pg:wait command outputs the provisioning status of any new databases. Use it to determine when the fork is up to date.$ heroku pg:wait --app example-appWaiting for database HEROKU_POSTGRESQL_SILVER_URL... availableCreate Using the Heroku Data DashboardYou can also create forks through the web dashboard:Go to data.heroku.com.Use the search and select the database you want to create a fork from.Click the Settings tab.Click Fork Database....Choose the plan for the fork. Review the Create a Fork section for notes on selecting a plan size.Click Fork Database.The dashboard shows the status of the forked database and updates when the provisioning is complete.Fork Fast OptionFast forks can be up to 30 hours out-of-date.You can create forks faster via the CLI with the --fast flag. This option is useful if no major changes, such as schema migrations or large data imports, occurred in your database in the last 30 hours.The addons:create example follows the syntax for Heroku CLI v9.0.0 or later. If you’re on v8.11.5 or earlier, use the command:$ heroku addons:create heroku-postgresql:standard-4 --fork HEROKU_POSTGRESQL_CHARCOAL --fast --app example-app$ heroku addons:create heroku-postgresql:standard-4 --app example-app -- --fork HEROKU_POSTGRESQL_CHARCOAL --fastAdding heroku-postgresql:standard-4 on dashboard... done, v1022 ($1200/mo)Attached as HEROKU_POSTGRESQL_BLUE_URLFork will contain data from 5/26/2021 at 13:56 UTC (about 16 hours old)To create a fork with up-to-date data, exclude the `--fast` flag.Database will become available after it completes forkingUse `heroku pg:wait` to track status.Use `heroku addons:docs heroku-postgresql` to view documentationDelete a ForkDelete Using the CLIDeprovision a fork using heroku addons:destroy:Be sure to remove the _URL suffix from the database name in this command.$ heroku addons:destroy HEROKU_POSTGRESQL_SILVER --app example-app! WARNING: Destructive Action! This command will affect the app: example-app! To proceed, type "example-app" or re-run this command with --confirm example-appDelete Using the Heroku Data DashboardGo to data.heroku.com.Use the search and select the fork database you want to delete.Click

Heroku ArchitectureStacks (operating system images)Heroku-24 Stack Last updated February 21, 2025 Table of ContentsWhat’s newAvailable softwareSupport periodUsing Heroku-24Upgrading to Heroku-24Heroku-24 Docker images This article describes the Heroku-24 stack, based on Ubuntu 24.04. What is a stack?What’s newThis stack is now based on Ubuntu 24.04, compared to Ubuntu 22.04 used in theHeroku-22 stack.The most important changes compared to Heroku-22 are:We adjusted the Ubuntu packages installed on the stack to reduce thesize of the base images:We removed some less frequently used packages (such as Bazaar and Mercurial).We made some tools that are typically only required during the build (such as GCC, Make, Gitand system Python) available only at build time, rather than at app run time too.We made several changes to the Heroku-24 Docker images:We now publish them as multi-architecture images, that support both the amd64 andarm64 architectures instead of only amd64.We now set the default image Linux user to heroku instead of root.See the upgrade notes for more detailed change information.Available softwareEvery stack on Heroku supports different operating system packages and language runtime versions.This support is typically confined to software that was still actively developed by the respectivemaintainers at the time the stack was first released.Language runtimesFor the most accurate information on supported language runtime versions, please check theindividual language pages: Buildpack Shorthand Runtime versions Ruby heroku/ruby Runtime versions Node.js heroku/nodejs Runtime versions Python heroku/python Runtime versions Java heroku/java Runtime versions PHP heroku/php Runtime versions Go heroku/go Runtime versions Operating system packagesFor a full list of operating system packages available on

App’s architecture.The legacy Google Chrome buildpack is no longer supportedThe heroku-buildpack-google-chromebuildpack is not compatible with Heroku-24. We have sunset it in favour of the newerChrome for Testing buildpack, whichaddresses several limitationsof the old buildpack. Migrate to the new buildpack usingthese instructions.The Redis Stunnel buildpack is no longer supportedThe heroku-buildpack-redis buildpack is notcompatible with Heroku-24. We have sunset it since Redis 6+ supports TLS natively, which makesthe buildpack redundant. Remove the buildpack andswitch to Redis’ native TLS support instead. For more information, seeSecuring Heroku Redis.Heroku-24 Docker imagesHeroku-24 is available as two Docker images:The run time image (heroku/heroku:24), which is recommended over the build image for most workloads.The build image (heroku/heroku:24-build), which is larger as it includes development headers and toolchains. It is only recommended for customers that need to compile source code or dependencies.Use the following command in your Dockerfile to use Heroku-24 as your base image:FROM heroku/heroku:24We publish these images as multi-architecture images, supporting both the amd64 and arm64CPU architectures. By default Docker will use the image architecture that matches the machine onwhich it is being run. To force the use of a different architecture, pass--platform linux/ to docker build or docker run commands, or useFROM --platform=linux/ IMAGE_NAME in your Dockerfile.The default Linux user for these images is heroku, which does not have root permissions. If youneed to modify locations outside of /home/heroku or /tmp you will need to switch back to theroot user. To do this add USER root to your Dockerfile when building images, or pass--user root to

Supported dyno type, except for the Eco dyno type, can power apps owned by Heroku Teams.Transferring AppsThe Settings tab of all apps provides an interface to transfer ownership of the app.Bulk transfer of personal apps into a team can be done from the Team Settings page or the Heroku CLI. To transfer apps using the bulk transfer features, the owner of the personal app must also be an admin of the team.You can transfer Team-owned apps to other teams, to Heroku Enterprise Teams, or to the Personal apps area of a given user.Permissions for all team members and admins on apps transferred to other Teams or to Heroku Enterprise Teams are preserved. Apps transferred to a user’s Personal apps area are stripped of all user and permissions associations.You can also transfer apps to a Heroku Team from another Team, from a Heroku Enterprise Team, or from a user’s Personal apps. See Transferring Apps on how to accomplish these transfers.Heroku CLI SupportSupport for operations around your Heroku Teams is available in the Heroku CLI; usage is parallel to the usage applied to the Organizations available in Heroku Enterprise. For more information, type heroku help teams or heroku help members in the Heroku CLI prompt.New members added to a Heroku Team via the CLI are sent email invitations that the recipient must click to accept. Invited team members who haven’t accepted their invitations and are “removed” via the CLI have the outstanding invitations invalidated and revoked. These operations are reported in detail in the CLI feedback.

Heroku-24, please refer to articleUbuntu Packages on Heroku Stacks.Support periodHeroku-24 is based on Ubuntu 24.04. It will be supported through April 2029. Learn more aboutHeroku’s stack update policy.Using Heroku-24You can specify a stack when creating an app:$ heroku create --stack heroku-24You may change the stack on an existing app; the next build performed will then use the new stack:$ heroku stack:set heroku-24If you are using app.json, you should also specify the stack there toensure that your Review Apps and Heroku CI runs use the same stack:{ "stack": "heroku-24"}An existing app’s stack cannot be changed using app.json. The stack specified is only appliedto newly created apps that are a Review App, aHeroku CI test run app, or an app created using a Heroku Button.Upgrading to Heroku-24Please refer to the stack upgrading guide to understand theprocedures to follow when upgrading to a new stack.We recommend that you monitor your application closely after migrating an app to the new stackto ensure it’s performing correctly.Upgrade notesChanges to GitGit is now only available at build time and not also at app run time.The .git/ metadata directory for an app’s Git repository has never been available during thebuild or at run time, even when using older stacks. As such, if your app invokes Git at run timeto determine the deployed source revision (commit SHA), these calls will have always failed dueto the lack of a valid repository.If you need to determine the currently deployed revision of your app, either use the env varSOURCE_COMMIT during the build,

The language and creates a default web process type to boot the application server. However, creating an explicit Procfile is recommended for greater control and flexibility over your app.For Heroku to use your Procfile, add the Procfile to the root directory of your application, then push to Heroku:$ git add .$ git commit -m "Procfile"$ git push heroku master...-----> Procfile declares process types: web, worker Compiled slug size is 10.4MB-----> Launching... done deployed to HerokuTo [email protected]:strong-stone-297.git * [new branch] master -> masterUse heroku ps to determine the number of dynos that are executing. The list indicates the process type in the left column, and the command corresponding to that process type in the right column:$ heroku ps=== web: `bundle exec rails server -p $PORT`web.1: up for 2mUse heroku logs to view an aggregated list of log messages from all dynos across all process types.$ heroku logs2011-04-26T01:24:20-07:00 heroku[slugc]: Slug compilation finished2011-04-26T01:24:22+00:00 heroku[web.1]: Running process with command: `bundle exec rails server mongrel -p 46999`2011-04-25T18:24:22-07:00 heroku[web.1]: State changed from created to starting2011-04-25T18:24:29-07:00 heroku[web.1]: State changed from starting to up2011-04-26T01:24:29+00:00 app[web.1]: => Booting Mongrel2011-04-26T01:24:29+00:00 app[web.1]: => Rails 3.0.5 application starting in production on app[web.1]: => Call with -d to detach2011-04-26T01:24:29+00:00 app[web.1]: => Ctrl-C to shutdown serverScaling a process typeHeroku runs one web dyno for you automatically, but other process types don’t start by default. To launch a worker, you need to scale it up to one dyno:$ heroku ps:scale worker=1Scaling worker processes... done, now running 1You can also scale the size of a dyno:$ heroku ps:resize worker=standard-2xResizing dynos and restarting specified processes... doneworker dynos now standard-2xCheck ps to see the new process type running, for example:$ heroku ps=== web: `bundle exec rails server -p $PORT`web.1: up for 2m=== worker: `env QUEUE=* bundle exec rake resque:work`worker.1: up for 5sUse heroku logs --ps worker to view just the messages from the worker process type:$ heroku logs --ps worker2011-04-25T18:33:25-07:00 heroku[worker.1]: State changed from created to starting2011-04-26T01:33:26+00:00 heroku[worker.1]: Running process with command: `env QUEUE=* bundle exec rake resque:work`2011-04-25T18:33:29-07:00 heroku[worker.1]: State changed from starting to up2011-04-26T01:33:29+00:00 app[worker.1]: (in /app)The output we see here matches our local output, interleaved with system messages from Heroku’s system components such as the router and dyno manager.You can scale up higher with the same command. For example, two web dynos and four worker dynos:$ heroku ps:scale web=2 worker=4Scaling web processes... done, now running 2Scaling worker processes... done, now running 4$ heroku ps=== web: `bundle exec rails server -p $PORT`web.1: up for 7mweb.2: up for 2s=== worker: `env QUEUE=* bundle exec rake resque:work`worker.1: up for 7mworker.2: up for 3sworker.3: up for 2sworker.4: up for 3sRead more about scaling.More process type examplesThe Procfile model of running processes types is extremely flexible. You can run any number of dynos with whatever arbitrary commands you want, and scale each independently.For example, using Ruby you could run two types of queue workers, each consuming different queues, as well as a release phase command:release: ./release-tasks.shworker: env QUEUE=* bundle exec rake resque:workurgentworker: env QUEUE=urgent bundle exec rake resque:workThese can then be