Skip Navigation
Show nav
Heroku Dev Center
  • Get Started
  • Documentation
  • Changelog
  • Search
  • Get Started
    • Node.js
    • Ruby on Rails
    • Ruby
    • Python
    • Java
    • PHP
    • Go
    • Scala
    • Clojure
  • Documentation
  • Changelog
  • More
    Additional Resources
    • Home
    • Elements
    • Products
    • Pricing
    • Careers
    • Help
    • Status
    • Events
    • Podcasts
    • Compliance Center
    Heroku Blog

    Heroku Blog

    Find out what's new with Heroku on our blog.

    Visit Blog
  • Log inorSign up
View categories

Categories

  • Heroku Architecture
    • Dynos (app containers)
    • Stacks (operating system images)
    • Networking & DNS
    • Platform Policies
    • Platform Principles
  • Command Line
  • Deployment
    • Deploying with Git
    • Deploying with Docker
    • Deployment Integrations
  • Continuous Delivery
    • Continuous Integration
  • Language Support
    • Node.js
    • Ruby
      • Working with Bundler
      • Rails Support
    • Python
      • Background Jobs in Python
      • Working with Django
    • Java
      • Working with Maven
      • Java Database Operations
      • Working with the Play Framework
      • Working with Spring Boot
      • Java Advanced Topics
    • PHP
    • Go
      • Go Dependency Management
    • Scala
    • Clojure
  • Databases & Data Management
    • Heroku Postgres
      • Postgres Basics
      • Postgres Getting Started
      • Postgres Performance
      • Postgres Data Transfer & Preservation
      • Postgres Availability
      • Postgres Special Topics
    • Heroku Data For Redis
    • Apache Kafka on Heroku
    • Other Data Stores
  • Monitoring & Metrics
    • Logging
  • App Performance
  • Add-ons
    • All Add-ons
  • Collaboration
  • Security
    • App Security
    • Identities & Authentication
    • Compliance
  • Heroku Enterprise
    • Private Spaces
      • Infrastructure Networking
    • Enterprise Accounts
    • Enterprise Teams
    • Heroku Connect (Salesforce sync)
      • Heroku Connect Administration
      • Heroku Connect Reference
      • Heroku Connect Troubleshooting
    • Single Sign-on (SSO)
  • Patterns & Best Practices
  • Extending Heroku
    • Platform API
    • App Webhooks
    • Heroku Labs
    • Building Add-ons
      • Add-on Development Tasks
      • Add-on APIs
      • Add-on Guidelines & Requirements
    • Building CLI Plugins
    • Developing Buildpacks
    • Dev Center
  • Accounts & Billing
  • Troubleshooting & Support
  • Integrating with Salesforce
  • Language Support
  • Ruby
  • Rails Support
  • Deploying to a Custom Rails Environment

Deploying to a Custom Rails Environment

English — 日本語に切り替える

Last updated May 27, 2021

Table of Contents

  • Dev/prod parity
  • Explicit behavior
  • Setting staging behavior
  • Locally
  • Summary

Heroku recommends you configure your application using environment variables instead of using encrypted files that you check into your git repository. Environment variable based configurations can be changed without requiring a git check-in and a new deploy.

Rails has the concept of different environments. By default there is “test”, “development” and “production”. Each environment has its own configuration file in config/environments folder allowing you to specify custom behavior. Rails also exposes Rails.env allowing you to write custom logic inside of your code:

if Rails.env.production?
  # ...
else
  # ...
end

Bundler is environment aware and will allow you to only load certain gems in certain environments:

gem 'rails_12factor', group: "production"

It may be tempting to create another custom environment such as “staging” and create a config/environments/staging.rb and deploy to a Heroku app with RAILS_ENV=staging.

This is not a good practice. Instead we recommend always running in production mode and modifying any behavior by setting your config vars.

Dev/prod parity

Heroku highly recommends keeping your development and production environments as close together as possible. This is called dev/prod parity. We also recommend keeping your staging as close to production as possible. If they are too different, deploying and testing on a staging app does not verify your production instance will work.

Explicit behavior

It is best practice while writing logic involving environment to declare behavior based on only one environment. For example instead of writing:

if !Rails.env.development? && !Rails.env.test?
  # ...

It would be better to write

if Rails.env.production?
  # ...

The behavior difference is subtle yet important. If you introduce a staging environment any custom logic in the Rails.env.production? will not be executed.

In addition to environment-specific code, bundler will not load gems targeted to :production when run in the RAILS_ENV=staging environment.

Setting staging behavior

Code is often written to change configuration based on the environment. For example, you don’t want your staging apps sending out real emails, or using your production S3 bucket. So instead of using Rails.env and a custom staging environment like this:

if Rails.env.staging?
  S3_BUCKET = "my_staging_bucket_name"
end

It would be better to set this through an environment variable:

S3_BUCKET = ENV['MY_BUCKET_NAME']

Doing this avoids the need of a custom environment, and you can still fully control behavior by having a different set of config vars for each app.

The email example mentioned above can be avoided by changing email provider credentials provided they are in environment variables, or even setting your provider to use a “test” mode, for example, you can tell mailgun to not send out emails.

Any configuration you wish to change in config/environments/production.rb can be set from environment variables instead of hardcoded and checked into git.

Locally

Locally you can set these environment variables with a .env file.

Summary

Your “staging” app or any other custom environments should be run with RAILS_ENV=production to minimize differences in behavior. Environment variables should be used to configure your application to achieve different behavior when desired instead of a custom environment.

Keep reading

  • Rails Support

Feedback

Log in to submit feedback.

Using Rack::Cache with Memcached in Rails 3.1+ (Including Rails 4) Direct to S3 Image Uploads in Rails

Information & Support

  • Getting Started
  • Documentation
  • Changelog
  • Compliance Center
  • Training & Education
  • Blog
  • Podcasts
  • Support Channels
  • Status

Language Reference

  • Node.js
  • Ruby
  • Java
  • PHP
  • Python
  • Go
  • Scala
  • Clojure

Other Resources

  • Careers
  • Elements
  • Products
  • Pricing

Subscribe to our monthly newsletter

Your email address:

  • RSS
    • Dev Center Articles
    • Dev Center Changelog
    • Heroku Blog
    • Heroku News Blog
    • Heroku Engineering Blog
  • Heroku Podcasts
  • Twitter
    • Dev Center Articles
    • Dev Center Changelog
    • Heroku
    • Heroku Status
  • Facebook
  • Instagram
  • Github
  • LinkedIn
  • YouTube
Heroku is acompany

 © Salesforce.com

  • heroku.com
  • Terms of Service
  • Privacy
  • Cookies
  • Cookie Preferences