console-safety-production

Console Safety in Production

The production Rails console is a foot-gun. User.update_all(admin: true) runs in 0.2 seconds. There is no undo. This skill encodes the habits, gates, and alternatives that keep production console operations safe.

The opinion

Avoid the production console for routine work — write a rake task or a script-as-PR. When you must use it, default to read-only mode. Use rails console --sandbox for any state-changing exploration. Enable Rails 7.2+ production console warning. Log every session. Never run update_all / delete_all / truncate / raw SQL DML in console.

Why it matters: most "production outage caused by a 1-line typo" incidents trace back to console usage. The console gives you full ActiveRecord power with zero review, zero tests, zero rollback.

Pattern 1: Production console warning (Rails 7.2+)

Rails 7.2 shipped the production console warning by default. IRB renders a prominent prompt with the environment name when launched against production, e.g.:

Loading production environment (Rails 8.0.0)
production> User.first

The prompt label and color are controlled by IRB itself, not by a Rails config flag — there's no config.console_environment_color. Customize via ~/.irbrc if you want a different prompt:

# ~/.irbrc — applies to your shell, not the app
IRB.conf[:PROMPT][:PRODUCTION] = {
  PROMPT_I: "\e[31mproduction>\e[0m ",
  PROMPT_S: "\e[31mproduction*\e[0m ",
  PROMPT_C: "\e[31mproduction?\e[0m ",
  RETURN:   "=> %s\n"
}

Pattern 2: Sandbox mode

bin/rails console --sandbox

Loading production environment in sandbox (Rails 8.0.0)
Any modifications you make will be rolled back on exit

All DB writes wrap in a transaction that rolls back on exit. The default for exploratory work in production.

Gotcha: sandbox does NOT roll back:

• Files written to disk
• API calls
• Email sends
• Background jobs enqueued via Sidekiq (writes to Redis — does NOT roll back). Solid Queue persists to your DB, so NEW enqueues from within the sandbox roll back with the transaction. But jobs already picked up by workers during the sandbox session run normally and are unaffected.
• Cache writes (Redis, MemoryStore)