Heroku

Hello Heroku

Heroku has historically been the go-to platform for 12-factor deployment. Originally founded in 2007, this platform was the primary choice for Ruby and Ruby on Rails apps “back in the day.” Heroku was acquired by SalesForce in 2011 and today is part of the SalesForce company but still does business as its own brand, Heroku.com.

About the Price

$7/month for services + databases; in practice, to run an app with a DB, Redis, + web server means you have to pay for all 3 which comes up as more expensive for demo & test apps.

Ease Of Setup: Creating a new app on Heroku is as easy as clicking a button. As well, Heroku has a built-in “Heroku pipeline” system for running your CI/CD, code checks, and

IMPORTANT: This article cover the basics of using the Heroku web interface. All of the settings can also be changed on the command line, which involves typing commands into a terminal editor using the heroku command. This article assumes you are not a developer and so introduces you to the web interface only. For non-developers, I recommend you familiarize yourself with Heroku’s major parts but do not attempt to make significant changes in the dashboard without assistance.

Getting Started

To get started with Heroku, you’ll want to take the following steps:
1. Sign up on their website

2. Verify your email by clicking the link they send you

3. Install the Heroku CLI (command-line interface)

You will use the CLI (which you do through a terminal application, like Terminal or any unix shell prompt).

Your First App

After you log in, in the upper-right of your screen you will see:

Click “new” and then from the drop-down choose “Create new App”

On the next screen you will need to choose a name that is unique across all of Heroku customers’ apps. If you enter a name here that is already taken, you will receive a red message and can’t continue. (Once an app is deleted, that name becomes available again for another Heroku customer to take)

Here, I’ve chosen jfbcodes-test-app

For now, do not click Add to Pipeline… I will cover Pipelines below.

Meet the Heroku Dashboard. Here you are already defaulted to the Deploy tab of your new app, with helpful instructions for how to deploy your app. (Deploying your app is highly dependent on many factors— whether it is Ruby or Node, what special binaries may need to run, etc. These factors are beyond the scope of this article, but I encourage you to reach out to my company Verso Commerce for help with your Ruby or Node Heroku install today.)

This article serves as a high-level overview of the Heroku Dashboard, so I will skip deployment and introduce you to the dashboard of a more live app.

I’m going to introduce you to the Heroku Dashboard from right-to-left, starting with the Settings tab.

This is what it looks like when it is freshly created:

App Information

Here we see the stack, framework, slugsize, and Heroku Git URL.

Stack — this is the automatically assigned Heroku Stack which comes in generations of even-year numbers. Before heroku-20, the heroku-18 stack was the default and before that heroku-16. Heroku rotates their stack every two years, providing a full rebuild of the essential parts of the Linux system running your app on its cloud. These improvements are complicated and involve swapping out the entire architecture. But your app doesn’t automatically change stacks when they make this change. Instead, your app is “locked into” the version it was first created with. You aren’t supposed to stay on that version forever— the old stacks will stay supported for only a period of time. (For example, heroku-18 will loose suppose in February 2023 so any apps deployed on heroku-18 must upgrade to the heroku-20 or later stack by that date to continue to be supported).

Framework— This will show as Ruby or Node, but will show as “No framework detected” before you install anything into your Heroku app.

Slug Size — This is the size of your “slug,” which is a compiled virtual server (in Heroku’s terms, “a dyno”)

Heroku Git URL — Here we have the Heroku git endpoint. That is the git repository we will push to to deploy our app. To do this, we will push to the main branch of this repository. (For legacy apps, Heroku will also respond to pushes to the master branch.)

This should not be confused the Git repository where you house your code (typically Github) and from where your developers make their daily commits & pull requests.

After I push a Ruby on Rails app to Heroku, my Settings tab now looks like this:

Reveal Config Vars

Click the Reveal Config Vars button to see and edit your app’s config vars.

Everything here was created by the default Rails installation, but your app might need special configuration of these ENV variables.

In Rails, these are available to your entire app in ENV variables.

In Create React App, these config vars are available if and only if they begin with the characters REACT_APP_

Buildpacks

This would, if it were needed your app, display additional parts of your stack that need to be installed along with the default Heroku build. They are called “buildpacks” and they are beyond the scope of this introduction. If your app needs them, they will be handled for you during your Heroku deployment setup. Here you can simply view them.

Domains

In the Heroku interface you will find Domains below SSL Certificates, but you will need to add a domain before you can configure the SSL. Adding a domain is easy— just click Add Domain and follow the prompts.

Before you assign it to a domain, it will be available at a special Heroku subdomain. Do not use this URL for your own purposes— that’s not a good idea.

https://jfbcodes-test-app.herokuapp.com/

This subdomain will always be the name of your app (which is global to all Heroku customers as explained above). It will be a subdomain of the domain herokuapp.com

This is only the starting point for you to test your configuration. When you have your own domain or subdomain to connect, you will want to do so by clicking “Add Domain.” As soon as you add it, you app will be available at the http (port 80) endpoint only, which is insecure and not recommended. It is recommended you redirect all traffic from port 80 to port 443 (for an https connection), which you must write into the code of your application.

SSL Certificates

Provisioning an SSL certificate using the free LetsEncrypt certificates has been made into a ‘one-click’ process. Lets Encrypt certificates are excellent choice for the modern web and are free.

Transfer Ownership

The Heroku “owner” is the person whose credit card it billed. Also, only the Owner can transfer ownership (away) and add paid resources. You will only do this if you are transferring ownership of the app to another entity. Once you do it, there is no “undo” without contacting Heroku support, so be sure to transfer to the correct person.

Maintenance Mode

Your app has a built-in maintenance mode switch.

Switch maintenance mode to on:

Now, all users to go to your app in a browser will see the same thing in their browser:

Delete App

You only ever need this if you want to fully remove your app from Heroku.

Now that we’ve finished with the Settings page let’s move onto the Access tab.

Access Tab

This is where you will assign other people who will have access to your app.

Note that if you give someone access they will have full access— be able to change ENV settings, deploy the app, but they won’t be able to provision new paid resources. (For that you, the owner, must be the one to add the resource in the Heroku UI.)

Click “New Collaborator”

Activity Tab

Here you see only a list of exactly when this app was deployed and any config settings that are changed, in reverse chronological order.

As you can see, I attempted to deploy this app a couple of times. However, even though it says I did a total of 8 activities, many of these were done for me automatically. Even though I didn’t initiate them, they were initiated by an action I did initiate (in this case, deploying a Rails app), so Heroku tells me I am the person who did them.

Notice the setting of the Heroku ENV variables (You saw them above)

Also notice at the top of the list will appear the last deploy for this app, including the Git SHA so you know precisely which SHA was deployed.

Metrics Tab

Metrics is a really important tab that shows you in near realtime the health and state of your app.

Deploy Tab

This screen is where you configure your deployment.

Resources Tab – Example #1
A Heroku resources tab showing web and worker dynos running on Hobby dyno types, three add-ons: Postgres, Redis, and Honeybadger

Here I have an app running 2 workers (one is called web and the other is called worker). The web dyno is booted up using this command:

bundle exec rails server -p $PORT

The worker command is booted with

bundle exec sidekiq

Both of these tell Heroku how to startup two separate parts of my app:

1. the web dynos, which will respond to web requests (these are standard part of Heorku’s design)

2. The worker dynos which in my app will perform background jobs. (these are added by me)

Both kinds of dynos will be running at the same time.

Here, we can use the edit icon to turn the dyno type on or off. (You cannot scale — or change the number of— dynos from the web interface. You must use the command line for that.)

Finally, you will see the Add-ons. This is also where you will add new add-ons from the web UI as well.

Here you will add things like Heroku Data and Redis to your app.

Example #2
A Heroku app showing two dynos (web and worker) running on

In this example, this production app is running two dyno types named web and worker as well. This app is running on Professional Dynos, which cost $25/month each. (You can change the dyno type with the Change Dyno Type button, but note that doing so will cause your app to restart.)

You will notice that the web instead is booted with Puma, like so:

bundle exec puma -C ./config/puma/production.rb

The workers instead of using Sidekiq, use the Rails default:

bin/rake jobs:work

This app is using several more add-ons: Deploy Hooks, Postgres, Scheduler, Honeybadger, Logentries, Mailgun, and Memcachier. For each add-on, you can see the plan level that is attached. You can also remove the add-on or make changes to the plan level.

Running out of your quota? For most add-ons, you can easily fix this if you are the app’s owner by switching the plan level here. However, that’s not true for Postgres databases (“Heroku Postgres” or “Heroku Data”), which require a special migration when moving from a smaller size to a larger one. (For that, please see my company Verso Commerce — we are specialists in Heroku deployment.)

Overview Tab

Here we see a composite of several other screens: Metrics from the Metrics tab, Latest Activity (from Activity tab), Installed Add-ons (from the Resources tab), and some cost information. As its name implies, it is an overview. Functionally, you will not need to visit this tab much to make changes, which is why I have introduced the tabs in reverse order.

More About Heroku

Pipelines

Pipelines are a modern way to work on Heroku. From the Heorku docs:

pipeline is a group of Heroku apps that share the same codebase. Each app in a pipeline represents one of the following stages in a continuous delivery workflow: Development, Review, Staging, Production

Heroku Docs

Using a pipeline allows for a streamlined continuous delivery workflow— or producing software in short, iterative cycles and constantly delivering to production. This benchmark is typically seen as the key to successful software develompent.

Setting up your pipeline is beyond the scope of this article, but if you have a Ruby or Node deployment please reach out to my company Helios Dev Shop and we can gladly help you get your pipeline set up.

Meet “the Dyno”

The 30-Second Timeout and Other Limitations

Prebooting

BYO Data

The Routers & The Mesh Layer

The mesh layer is a special architectural design of Heroku’s. Each web request is routed through one of several high-powered routers, called “the mesh layer,” before it is forwarded down to the “dyno” (virtual server) running your app. For a complicated set of reasons, this means that Heroku enforces a 30-second timeout on all requests. You can’t do anything about this. This means that if you have LRRs (Long Running Requests), you’ve got to eliminate them.