Production environment configuration in Ruby on Rails - Step-by-Step Execution

Concept Flow - Production environment configuration

Start: Rails app deployed

↓

Load config/environments/production.rb

↓

Set production-specific settings

↓

Initialize middleware and caching

↓

Connect to production database

↓

Serve assets precompiled

↓

App ready to handle live user requests

↓

Log errors and monitor performance

↓

End: Stable production environment

Rails loads the production config file, applies settings like caching and asset serving, connects to the production database, and prepares the app to serve live users.

Execution Sample

Ruby on Rails

Rails.application.configure do
  config.cache_classes = true
  config.eager_load = true
  config.consider_all_requests_local = false
  config.public_file_server.enabled = ENV['RAILS_SERVE_STATIC_FILES'].present?
end

This code sets key production settings: caching classes, eager loading code, hiding detailed errors, and serving static files if environment variable is set.

Execution Table

Step	Config Setting	Value Set	Effect on App	Notes
1	cache_classes	true	Classes loaded once, improves speed	Prevents code reload on each request
2	eager_load	true	Loads all code on boot	Improves performance in threaded servers
3	consider_all_requests_local	false	Hides detailed error pages	Shows user-friendly error pages
4	public_file_server.enabled	Depends on ENV variable	Serves static assets if true	Usually true if web server doesn't handle assets
5	database connection	production DB config	Connects to production database	Uses credentials from config/database.yml
6	assets.compile	false	Precompiled assets served	Prevents on-the-fly asset compilation
7	log_level	:info	Logs important info only	Reduces log noise in production
8	exit	-	Configuration loaded, app ready	Production environment fully configured

💡 All production settings loaded; app ready to serve live traffic

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	Final
cache_classes	nil	true	true	true	true	true
eager_load	nil	nil	true	true	true	true
consider_all_requests_local	nil	nil	nil	false	false	false
public_file_server.enabled	nil	nil	nil	nil	ENV['RAILS_SERVE_STATIC_FILES'].present?	true or false
database_connection	nil	nil	nil	nil	nil	connected to production DB

Key Moments - 3 Insights

Why is cache_classes set to true in production?

Setting cache_classes to true loads classes once and prevents reloading on each request, improving speed as shown in step 1 of the execution_table.

What happens if consider_all_requests_local is true in production?

If consider_all_requests_local is true, detailed error pages show to users, which is unsafe. Step 3 shows it is set to false to hide errors.

How does public_file_server.enabled depend on environment variables?

Step 4 shows this setting depends on ENV['RAILS_SERVE_STATIC_FILES']. If present, Rails serves static files; otherwise, a web server should handle them.

Visual Quiz - 3 Questions

Look at the execution_table, what is the value of cache_classes after step 1?

A true

B false

C nil

D undefined

💡 Hint

Check the 'cache_classes' row and 'After Step 1' column in variable_tracker

At which step does Rails configure to hide detailed error pages?

A Step 1

B Step 5

C Step 3

D Step 7

💡 Hint

Look at 'consider_all_requests_local' setting in execution_table

If ENV['RAILS_SERVE_STATIC_FILES'] is not set, what happens to public_file_server.enabled?

A It becomes true

B It becomes false

C It remains nil

D It causes an error

💡 Hint

Refer to step 4 in execution_table and variable_tracker for public_file_server.enabled

Concept Snapshot

Production environment config in Rails:
- cache_classes = true (load once for speed)
- eager_load = true (load all code on boot)
- consider_all_requests_local = false (hide detailed errors)
- public_file_server.enabled depends on ENV variable
- Connects to production DB
- Serve precompiled assets only
- Logs at info level
These settings optimize app for live users.

Full Transcript

In Rails, the production environment configuration is loaded from config/environments/production.rb when the app starts. Key settings include cache_classes set to true to load classes once and improve speed, eager_load true to load all code on boot, and consider_all_requests_local false to hide detailed error pages from users. The public_file_server.enabled setting depends on an environment variable to decide if Rails serves static files or if a web server handles them. The app connects to the production database using credentials from config/database.yml. Assets are served precompiled to avoid runtime compilation. Logging is set to info level to reduce noise. These settings prepare the app to serve live user traffic efficiently and securely.

Practice

1. What is the main purpose of the production.rb file in a Rails application?

easy

A. To define routes for the application

B. To enable detailed error messages for debugging

C. To configure settings that optimize the app for real users, like caching and security

D. To set up the database schema

Solution

1. Step 1: Understand the role of production.rb

   This file holds configuration settings specifically for the production environment, where the app serves real users.

2. Step 2: Identify key production settings

   It disables detailed error messages and enables caching to improve speed and security.

3. Final Answer:

   To configure settings that optimize the app for real users, like caching and security -> Option C

4. Quick Check:

   Production config = optimize for real users [OK]

Hint: Production config = speed + security settings [OK]

Common Mistakes:

• Confusing production with development environment
• Thinking production shows detailed errors
• Mixing routing or database setup with production config

2. Which line correctly disables full error reports in config/environments/production.rb?

easy

A. config.consider_all_requests_local = false

B. config.show_detailed_errors = true

C. config.consider_all_requests_local = true

D. config.show_detailed_errors = false

Solution

1. Step 1: Identify the setting for error reports

   The setting consider_all_requests_local controls whether detailed error pages show.

2. Step 2: Know production default

   In production, this is set to false to hide detailed errors from users.

3. Final Answer:

   config.consider_all_requests_local = false -> Option A

4. Quick Check:

   Disable detailed errors = false [OK]

Hint: False hides errors in production [OK]

Common Mistakes:

• Setting it to true shows errors in production
• Using wrong config key like show_detailed_errors
• Confusing development and production defaults

3. Given this snippet in production.rb:

config.cache_classes = true
config.action_controller.perform_caching = true
config.assets.compile = false

What happens if you deploy without precompiling assets?

medium

A. The app will crash with a syntax error

B. Rails will compile assets on the fly, slowing down requests

C. Assets will be served normally from the public folder

D. Assets will not be served, causing missing styles and scripts

Solution

1. Step 1: Understand config.assets.compile = false

   This setting disables on-the-fly asset compilation in production.

2. Step 2: Consequence of no precompiled assets

   If assets are not precompiled, Rails cannot serve them, so styles and scripts will be missing.

3. Final Answer:

   Assets will not be served, causing missing styles and scripts -> Option D

4. Quick Check:

   No precompile + compile false = missing assets [OK]

Hint: No precompile + compile false = missing assets [OK]

Common Mistakes:

• Assuming Rails compiles assets automatically in production
• Thinking assets serve normally without precompile
• Confusing compile false with true

4. You see this error in production: ActionController::RoutingError (No route matches [GET] "/assets/application.css"). Which fix is correct?

medium

A. Precompile assets before deploying and keep config.assets.compile = false

B. Set config.assets.compile = true in production.rb

C. Remove caching settings from production.rb

D. Set config.consider_all_requests_local = true

Solution

1. Step 1: Understand the error cause

   The error means the CSS asset is missing in production, likely because assets were not precompiled.

2. Step 2: Correct fix for missing assets

   Best practice is to precompile assets before deployment and keep config.assets.compile = false for performance.

3. Final Answer:

   Precompile assets before deploying and keep config.assets.compile = false -> Option A

4. Quick Check:

   Missing assets fix = precompile + compile false [OK]

Hint: Always precompile assets for production [OK]

Common Mistakes:

• Setting compile true causes slow requests
• Removing caching does not fix missing assets
• Enabling detailed errors leaks info in production

5. You want to securely configure your Rails app for production to use environment variables for secrets and enable caching. Which combination in production.rb is best practice?

hard

A. config.cache_classes = false
config.action_controller.perform_caching = false
config.secret_key_base = ENV['SECRET_KEY_BASE']

B. config.cache_classes = true
config.action_controller.perform_caching = true
config.secret_key_base = ENV['SECRET_KEY_BASE']

C. config.cache_classes = true
config.action_controller.perform_caching = false
config.secret_key_base = 'hardcoded_secret'

D. config.cache_classes = false
config.action_controller.perform_caching = true
config.secret_key_base = 'hardcoded_secret'

Solution

1. Step 1: Identify caching and class loading best practices

   In production, cache_classes and perform_caching should be true for speed and efficiency.

2. Step 2: Use environment variables for secrets

   Secrets like secret_key_base must come from environment variables, not hardcoded strings, for security.

3. Final Answer:

   config.cache_classes = true config.action_controller.perform_caching = true config.secret_key_base = ENV['SECRET_KEY_BASE'] -> Option B

4. Quick Check:

   Caching true + env secrets = secure production [OK]

Hint: Cache true + env secrets = secure production [OK]

Common Mistakes:

• Disabling caching in production
• Hardcoding secret keys in code
• Setting cache_classes false reduces performance