Preparing a Heroku Application for Production

So you’ve been tinkering away at your side project web app and are now ready to launch it to the world. You fire up a Heroku account, push up the source code et voilà, you’re on the internet.

The thing is now you’re running in “production” mode, so you’re going to want to set up some infrastructure for your application. I’m going to be using Ruby on Rails here but the general ideas will be the same for virtually any web application on any framework.

Domain Name and Email

I won’t dig into the details much here as they are more detailed guides out there but you’ll probably want to buy a custom domain name and hook it up to your Heroku account. You may also want to add an email provider so you can receive email at an address like support@myapp.com.

Secure HTTP (https)

If you’re using paid dynos on Heroku you’ll get this for free, you’ll also want to force https in your app configuration so that any requests to http://www.yourapp.com are automatically redirected to https://www.yourapp.com.

In Ruby on Rails this is a simple line in your production.rb file:

  config.force_ssl = true

Heroku Dyno Options

Free dynos spin down when not used which results in slow response times (you can get around this using a service that pings your domain periodically but I wouldn’t recommend it).

The answer is to use paid dynos, the base $7/month version is fine when you’re getting started.

You’ll also want to consider your database provider. For postgres Heroku offers a free level but its performance is not guaranteed. I have an earlier post with a more in-depth test of Heroku’s “Hobby” postgres performance and some alternatives.

Error Tracking

You’ll want to log any errors that occur on your production environment. I use Honeybadger.io which has a free plan for solo developers, but there are numerous others including Bugsnag, Rollbar, Airbrake, etc.

Logging

Another valuable thing is a logdrain, that is, a service to store all the log information produced by your application. I’m using Logentries which gives you 5gb/month of log retention on the free tier.

The main thing I look for is retention (since it may be a few days before you can diagnose an error) and live tail (when you are actively testing the site) - not just what is offered, but what the UI is like to view and use these features.

As a bonus, Logentries also monitors your response time and will email you an alert when a response goes over a threshold.

Uptime Checks

Beyond error tracking, it’s good to have a service hit your main page to confirm the server is actually up and running correctly. Honeybadger.io also provides this service along with error tracking, another option is Pingdom.

Cron Monitor

An uptime check makes sure your web server is operating, but you’ll also want something similar for your background jobs. For GitArborist this is a scheduled ActiveJob job that uses Honeybadger’s check-in feature.

This has the nice effect that not only do I validate that my worker dyno is running, I also confirm that Sidekiq is configured currently and running scheduled jobs.

The job itself is dead simple:

class HoneybadgerCheckInJob < ApplicationJob
  def perform
    Honeybadger.check_in(ENV["HONEYBADGER_CHECK_IN_ID"])
  end
end

I then schedule this to run periodically using the sidekiq-cron gem.

Performance Monitoring

Last but not least, it’s good to have some monitoring of application performance. I’m using Skylight.io which gives me a breakdown of response times for each endpoint. Skylight is targeted specifically at Ruby on Rails but there are other services - Scout, Raygun, and New Relic to name a few.