to navigateEnterto select Escto close

    Deploying the application on Heroku

    Once you finish this chapter, you will get an idea of all the steps that we need to take to deploy to Heroku.

    But to make your application work in Heroku, you would have to complete the upcoming chapter "Configure Sidekiq in Heroku" and execute the steps mentioned there to make our Sidekiq workers run as intended.

    PostgreSQL database setup

    We at BigBinary use PostgreSQL database on Heroku.

    When our application is deployed to Heroku, it will be running in production mode.

    Go through the next section to understand how to use PostgreSQL.

    Install PostgreSQL in the system

    There are two ways to install PostgreSQL in Mac:

    • Using

    If you are using a Mac, is an easy way to install PostgreSQL.

    The config/database.yml file should look like this.

    • Using Homebrew
    1brew install postgresql

    After installing PostgreSQL, you can check the version you are running by executing:

    1postgres -V

    Once the installation is complete we need to start PostgreSQL service to use postgresql in our project:

    1brew services start postgresql

    You can check if the PostgreSQL is working properly and accepting responses by running the following command:


    This should return an output similar to:

    1/tmp:5432 - accepting connections

    Please note that the config/database.yml file to be added after brew install will be defined in the upcoming chapters and it is different from the one defined for the installation.

    Given that currently, we are using PostgreSQL only in the production environment, we don't need to make any modifications to the config/database.yml file. The config/database.yml file is anyways ignored by Git. The use case of that file is only in local environments. We will learn more about the same in the upcoming chapters.

    Update Gemfile to use PostgreSQL

    Installing and configuring "PostgreSQL" on a personal laptop can be tricky. So here is what we are going to do.

    We will use the sqlite3 gem for both the development and test environments.

    We will use the pg gem only in the production environment. In this way, we do not have to install PostgreSQL on our laptop.

    Modify Gemfile to use sqlite3 only in the development and test environment.

    Note that in the following code, we have added group. It allows us to specify the environment in which we want to use a particular gem:

    1gem 'sqlite3', '~> 1.4', :group => [:development, :test]

    Now let's add the pg gem for production:

    1gem 'pg', :group => [:production]

    The => representation is called the hash-rocket representation and this is an older way of writing the newer JSON-style representation, which is group: [:production].

    Install the gems:

    1bundle install

    Creating a Heroku application

    The first step in setting up Heroku is to Sign Up for Heroku.

    Then, install the Heroku CLI.

    If you are using macOS, then run the following:

    1brew tap heroku/brew && brew install heroku

    For Ubuntu/Debian based distros, the installation command is:

    1sudo snap install --classic heroku

    After installation, run:

    1heroku --version

    Now you should be seeing the current version number if the Heroku command-line interface (CLI) installation was successful.

    Once we’ve verified that the Heroku command-line interface is installed, we need to use the following Heroku command to log in:

    1heroku login

    We will be redirected to authorize our account via browser.

    Note: All the commands given below should be run from the root of the granite project.

    Finally, we need to create an application in Heroku. In this case, Heroku will choose a random name for our application:

    1heroku create

    We will see the output something similar to this:

    1Creating app... done, ⬢ agile-everglades-72910
    2 |

    You can use the git remote command to confirm that a remote named heroku has been set up for your app:

    1git remote -v

    The output will contain the initialized heroku remote, and would look something like so:

    1heroku (fetch)
    2heroku (push)

    The name of the application will be different for everyone. We will refer to it as <heroku_application_name> here on.

    Setting up buildpacks

    Heroku Buildpacks are sets of open source scripts that are used for compiling apps on Heroku. They determine the build process for an app, and which assets and runtimes should be made available to your code at runtime.

    We will configure the following two buildpacks for our granite project.

    Run the following commands from the root of your granite project:

    1heroku buildpacks:set heroku/nodejs --index 1
    2heroku buildpacks:set heroku/ruby --index 2

    Let's see the list of buildpacks we have:

    1$ heroku buildpacks
    31. heroku/nodejs
    42. heroku/ruby

    Ensure that both nodejs and ruby are in the list of buildpacks.

    The order of the buildpacks matter. So please ensure that the order is as shown in the above output.

    This is because the last buildpack in the list will be used to determine the process types for the application. Any process types defined from earlier buildpacks will be ignored.

    We will learn more about process types in the upcoming Procfile section.

    After the buildpacks are set we also need to update our lockfile yarn.lock. We can do so by running:

    1yarn install

    This will make sure yarn.lock is up to date before we deploy our application.

    Setting up Heroku for deployment

    Before we can deploy our branch to Heroku, we need to make sure to add platform x86_64-linux to our Gemfile.lock file, otherwise we will receive an error saying:

    1Your bundle only supports platforms ["x86_64-darwin-20"] but your local platform is x86_64-linux.
    2Add the current platform to the lockfile with bundle lock --add-platform x86_64-linux and try again.

    We also have to push our code to Heroku. To do that we also have to commit our code till now. We can add this new platform and commit the code by running the following commands from the terminal:

    1bundle lock --add-platform x86_64-linux
    2git add -A
    3git commit -m "Added linux platform to lockfile"

    Now let's deploy the application to Heroku. Let's execute the following command to deploy our application to Heroku:

    1git push heroku <master or main>

    We need to manually migrate the database. This is important as we have to apply all the migrations in the production database. Therefore, don't forget to run the following command:

    1heroku run rails db:migrate -a <heroku_application_name>

    To view the newly deployed application on the browser, execute the following command:

    1heroku open

    Note: The app may not be fully operational as we haven't set up Sidekiq in Heroku. We will set it up in the upcoming chapter.

    Setting up auto deployment

    • Log into Heroku and go to the overview page of the deployed application.
    • Click on the Deploy tab.
    • In the deployment method section, select GitHub and provide the GitHub details.
    • Scroll to the Automatic deploys section and select the branch to be deployed. Let's keep it master for now.
    • Click on the Enable Automatic Deploys button.
    • Then, Heroku will display the message "Automatic deploys from <branch_name> is enabled".

    The <branch_name> will be master by default.

    Now anytime code is pushed to that branch, Heroku will automatically deploy the latest code from that branch.

    Heroku commands

    The following are some useful commands that will help you debug Heroku application from your terminal itself.

    To get into the Rails console of the deployed application, run the following command:

    1heroku run rails console -a <heroku_application_name>

    To check the logs of the application:

    1heroku logs -t -a <heroku_application_name>

    To migrate the database:

    1heroku run rails db:migrate -a <heroku_application_name>

    Renaming the application

    The auto-generated Heroku application names always look pretty weird.

    We can rename the deployed application to <new_application_name> from the initial <heroku_application_name> by executing:

    1heroku apps:rename <new_application_name> --app <heroku_application_name>

    The <new_application_name> can be of the form granite-[github_username]-production. You can replace the [github_username] with your GitHub username so that the application name is unique.

    Strictly use your GitHub username in your Heroku app name. Unique identification of your Heroku app is important.

    The -production suffix signifies that it is the production version of the app and we can easily differentiate it from the other review apps. We will learn about review apps in the next section.

    An example app name for the GitHub user named yedhink:


    Setting up the Heroku pipeline

    Heroku pipelines allow us to have a review app for each pull request. This is immensely useful in testing. We no longer need to pull down all the changes and run the application locally to see the application in action.

    Here are the instructions to set up review apps for PRs:

    • Log in at

    • Visit

    • Click on the "New" pull-down menu and then select "Create new pipeline".

      Create new pipeline

    • Enter the name of the pipeline as "granite-pipeline".

    • Select your granite repository and then click on "Connect".

    • Then click on "Create pipeline".

    • Now click on "Enable Review Apps".

      Enable review apps

    • Check "Create new review apps for pull requests automatically".

    • Choose a region - "United States".

    • Click on "Enable Review Apps".

    • Now when we send a pull request, Heroku will create a new review app for the corresponding PR.

      Review app deployment

    • When you click on "View Deployment", the review app will open up in a new tab.

    This saves us a lot of time. This is especially useful while reviewing a PR.

    The upcoming chapter is a continuation of this chapter. Please go through the next chapter too, to make the app working in Heroku.

    There is nothing to commit in this chapter since all we had done was deploying application on Heroku.