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.
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 the 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.
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:
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
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.
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.
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.
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.
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.
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:
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.
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”
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 is a really important tab that shows you in near realtime the health and state of your app.
This screen is where you configure your deployment.
Resources Tab – Example #1
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 Postgres and Redis to your app.
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:
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
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
- The Heroku Pipeline and Asset Compilation
- Heroku Dynos
- The Heroku Pipeline (aka ‘Pipelines’)
- Heroku Routers & Mesh Layer
- Heroku Memory Bloat
- Heroku Release Tasks