Earlier you learned how to deploy your app to the Heroku platform. In this section you’ll learn how to work with various Heroku features and add-ons.
Setting Configuration Variables
As your app grows it will need various pieces of configuration data to run. Some of this data will be too sensitive or change too frequently for you to be able to store it in source control. Heroku allows you to store configuration variables so that your app can configure itself in production mode.
All apps start out with a default set of variables, which you can view with the command
heroku config. Pay special attention to
RACK_ENV (which determines the environment your app boots into) and
DATABASE_URL which points at your app’s database.
Read more about Heroku configuration variables.
Setting Up Workers
For performance reasons, most web applications end up offloading work to worker processes that operate asynchronously, outside the context of a web request. This usually involves setting up a queueing system such as delayed_job or Resque.
delayed_job is the more documented, simpler approach since you can use your existing relational database. Follow Heroku’s setup instructions to get this running.
Note that if you are creating an app using Heroku’s Cedar stack, you will need to add a worker process to the app’s Procfile, described below.
Heroku’s Celadon Cedar stack affords much more flexibility about what kinds of processes can be run on Heroku. A typical
web app configuration using
thin is below:
Read more about Procfile configuration here.
As your app gets more usage you will need more processes (called dynos) to handle requests.
ps:scale command to increase thenumber of dynos allocated to each of the processes in your Procfile. You can specify absolute numbers like 2 for 2 total dynos, or relative numbers like +1, for one additional dyno:
The names "web" and "worker" in this case refer to the labels in your
Configuring the Rails 3.1 Asset Pipeline
This is the simplest way to get started, but eventually you may want to serve your assets from a separate host such as CloudFront.
Using an asset host frees up your Heroku dynos to handle dynamic requests. You can run the precompile task yourself:
RAILS_ENV=production rake assets:precompile
which will add a
public/assets/manifest.yml file to your app. If Heroku sees this file, it will not bother to compile your assets. You are then free to upload the compiled files to your CDN. You may wish to use the asset_sync gem to automate this process.
You’ll also need to configure the asset host in your
config.action_controller.asset_host = "https://d2mfbgzuncgoal.cloudfront.net"
The simplest way to export your database is the
pgbackups:url command to get a temporarily-accessible download:
You can also transfer data between Heroku databases using the procedure explained at the end of the pgbackups documentation.
pgbackups:restore command will pull data from a URL into your database like so:
Automating Database Backups
The PG Backups add-on will perform automatic daily backups, retaining the last 7 daily backups and 5 weekly backups. Add this to your app via:
If you know you’re about to try something sensitive, you can perform manual backups. Heroku will retain 10 of them with the default plan. Create an immediate backup using this command:
Read more about Heroku backups.
Using a Dedicated Database
Heroku apps start off using a shared database. The performance of a shared database is only acceptable for staging environments or "low-scale production applications". Once you start to see serious usage you’ll want to switch to a dedicated database. This upgrade can only be done from Heroku’s web U/I since a significant cost increase is involved.
Setting Up Custom Domains
You can run your app for free at a custom domain name by running:
Add the domain names like this:
You must configure a CNAME for your domains to point to Heroku in order for this to work, as explained in detail in the Heroku Custom Domains documentation.
Heroku will run short-duration daily and hourly batch jobs for you using the Cron add-on.
You need to add a rake task named "cron" to your app in
1 2 3 4 5 6 7 8 9 10
The most modular, easily-testable way to manage recurring tasks like this is to create a separate Cron task as described by Nick Quaranto in Testing Cron on Heroku.
With this task in place, just setup the add-on:
Setting Up SSL
If your app requires SSL your best option is to use Heroku’s Hostname Based SSL.
Heroku offers other options but that one works for most cases, and is among the easiest to setup. You’ll need to purchase an SSL certificate for your domain. Follow the direction on Heroku’s SSL documentation in order to add the certificate to your account.
If your SSL certificate requires the use of an intermediate certificate, be sure to append that file to your
.pem file as described in the Heroku SSL documentation.
Once the certificate is added, the SSL add-on can be activated like this:
You will receive an email from Heroku containing the hostname of your SSL endpoint. You will need to add a CNAME to your domain’s DNS settings corresponding to this endpoint.
Automating Deployment with Kumade
Although Heroku deployment is as simple as typing
git push heroku, over time you may want more control over the
deployment process. Or you may wish to automate other tasks like running migrations, packaging assets, and preventing deployments when your git repository is not clean.
Thoughtbot has created a gem called kumade which handles this for you. With it installed, instead of
git push heroku you deploy with
bundle exec kumade.
Sending Email with Sendgrid
The Sendgrid add-on gives you the ability to send outbound email from your app, saving you from needing to run your own SMTP server. The free version lets you send 200 emails per day.
Add Sendgrid using this command:
The Sendgrid documentation explains how to configure ActionMailer to use Sendgrid’s SMTP servers, which should be done in your
1 2 3 4 5 6 7 8