Heroku Tips and Tricks

On this week's episode, Chris is joined by Boston Development Director and TDD master Josh Clayton to discuss some of the tips we have here at thoughtbot for working with Heroku-deployed applications. The When and Why of Heroku Why Do We Use Her...
This is a companion discussion topic for the original entry at https://thoughtbot.com/upcase/videos/heroku-tips-and-tricks

cool episode! On a similar note I would love to see some content on how thoughtbot works with production applications. Stuff like:

  • What do you use for monitoring performance and errors?
  • Any procedures for optimizing memory usage in rails/ finding and eliminating slow queries/pages?
  • Do you setup etags for caching?
  • Any tips for caching in rails?
  • What about webservers? puma/unicorn/passenger, why?
  • How do you like skylight on upcase, does it make you want to be ember developers? :wink:

@christoomey @joshuaclayton what do you guys recommend in terms of using Heroku and making the DB Hippa Compliant? I didn’t know Heroku’s Postgres wasn’t Hippa Compliant.

Great topic, as a Heroku user myself I think Parity is really useful. Thanks for mentioning!

Regarding caching: I have good experiences with fragment caching and the Memcachier gem. Setup is really easy: https://devcenter.heroku.com/articles/memcachier

1 Like

I don’t think heroku will ever sign a BAA for hipaa.

We handle PHI and looked at catalyze and aptible for compliance + similarity to heroku.

It will be great to see a part II of Heroku tips and tricks on heroku docker, pipeline, and new private spaces.


we’ve been getting some request timeouts in our application and we’re considering using the “rack-timeout” gem. Is it not the case that the consequences of an abandoned request can be much worse that a long running one. Lets say there is a request for the following action:

def some_action
complete Database transaction A
complete Database transaction B

if transaction A is completed and ‘rack-timeout’ raises before transaction B then the application would be in an inconsistent state.

thanks for the very useful tutorials

@jamesjason I think you have a larger problem in the logic of the code. If completing A without B leaves the system in an inconsistent state you probably want both operations (or sets of operations) wrapped in a single transaction.

Even without Rack::Timeout there are many events that could leave you with bad data. For example, there could be a network problem between the two transactions, your cloud provider might have an outage between the two, or the operation(s) in transaction B could fail, causing it to roll back but leaving transaction A committed.

Huge fan of Parity on OSX, but I can’t seem to get it to work on Ubuntu. After gem install I get the following message:


As of version 1.0.0, Parity no longer distributes its executables via Rubygems.

If you use apt or Homebrew to install dependencies, you can install Parity
through those package managers to get the `development`, `staging`, and
`production` executables. Installing the executables via package manager makes
the programs available across Ruby versions.

Users without access to those package managers or who prefer to self-install can
find the executables at our Github repository:


But there doesn’t appear to be any apt repo to speak of. Anyone else succeed in getting the production, staging and development executables to work on Ubuntu?


Having watched this episode, I wanted to try out Suspenders. So I created a Rails app with Suspenders, and now I’m trying to deploy to Heroku with the command:


But I’m getting this error message:

fatal: 'staging' does not appear to be a git repository                                  │
fatal: Could not read from remote repository.

I’ve just created a github repository: https://github.com/acandael/myapp

So I am not sure what’s the problem. I’m not familiar with deploying to staging and production.

Any explanation is most welcome



Hi @acandael!

Heroku uses Git for its deployment mechanism. So when you deploy to Heroku, you are actually pushing your codebase (via Git) to a remote repository on Heroku’s platform.

In order to do this, you need to make sure you’ve (1) created an application on Heroku and (2) added that Heroku app’s repository to your local Git remotes.

Have you tried running the following command:

heroku git:remote -a <APP NAME> -r staging

This will create that staging remote repository and link it up to the Heroku application.

Hi carlosramirezi,

thanks for your help.

my Github repository is at:


when I add this to the command you send me:

heroku git:remote -a https://github.com/acandael/myapp.git -r staging

I’m getting this error:

The requested API endpoint was not found. Are you using the right HTTP verb (i.e. `GET` vs. `POST`), and did you   specify your intended version with the `Accept` header?



Happy to help!

Your GitHub repository is not the same as a Heroku application. GitHub is used to store your application’s source code to allow you to back it up, share and collaborate with others, etc. Your Heroku application is where your application is deployed and run, allowing end users to access your app and use it. While you use Git to push to both GitHub and Heroku, one is completely independent from the other.

You need to make sure you have created a Heroku application before you can deploy it.

If you haven’t already, I recommend working through this tutorial on Heroku before jumping into the tips and tricks presented here. Once you have a good grasp on how it works, you’ll better appreciate how Suspenders and the bin/deploy script work.

Once you have created a Heroku application (either through the command line or from the Heroku web app itself), you’ll need to use the app name in the command above.

For example, if you named your application testapp then the command would read

heroku git:remote -a testapp -r staging

Notice how we are passing the Heroku app name above, not the GitHub repository.

Good luck!

Thanks for the information, I was able now to run bin/deploy

However, something goes wrong when precompiling the assets:

Running: rake assets:precompile
remote:        rake aborted!
remote:        KeyError: key not found: "SMTP_ADDRESS"

I just deployed a vanilla Rails application, I didn’t configure anything, so maybe I should set this SMTP_ADDRESS

I was able to fix the issue by running the command:

heroku config:push

this pushes my local environment variables in the .env file to Heroku

however, when I run


I get this error:

    NameError: uninitialized constant SMTP_SETTINGS

should I add a variable SMTP_SETTINGS to the .env file? And what value is this variable supposed to get?

Any help is appreciated,