Encrypting sensitive data

Some columns hold data you don't want sitting in plaintext in your database — government IDs, tokens, anything regulated or genuinely private. RailsFast wires up Active Record Encryption out of the box so encrypting one is a single line in the model:

class User < ApplicationRecord
  encrypts :tax_id
  encrypts :api_token, deterministic: true # deterministic columns stay queryable
end

Rails transparently encrypts the value before it's written and decrypts it when you read it back. With deterministic: true the same input always produces the same ciphertext, so you can still User.find_by(api_token: ...); the default (non-deterministic) is stronger but not queryable. That's the only decision you usually have to make.

Your keys are already generated

Active Record Encryption needs three secret keys — primary_key, deterministic_key, and key_derivation_salt. The good news: you don't have to generate them. bin/setup created them for you the first time it built your encrypted credentials, so a fresh RailsFast project can call encrypts immediately with nothing to configure.

You'll find them under active_record_encryption: if you ever look:

EDITOR="cursor --wait" bin/rails credentials:edit

See Configure credentials for how the encrypted credentials file works in general.

WARNING

Never rotate the deterministic_key or key_derivation_salt in production once you've encrypted data with them. Deterministic encryption uses them to compute the stored ciphertext, so changing them makes existing rows impossible to find or decrypt. Treat these three keys as permanent. (You can rotate the non-deterministic primary_key later using Rails' key-rotation support, but the deterministic key and salt are forever.)

How it's wired

config/application.rb reads the keys before any encrypted model loads, in this order:

ACTIVE_RECORD_ENCRYPTION_PRIMARY_KEY / _DETERMINISTIC_KEY / _KEY_DERIVATION_SALT environment variables, then
per-environment credentials, then
shared credentials.

If none are set, development and test fall back to keys deterministically derived from your secret_key_base, so local setup stays zero-config. Production is strict: it refuses to boot without real, stable keys (the one exception is the Docker asset-precompile step, which sets SECRET_KEY_BASE_DUMMY and never touches encrypted data). This is deliberate — silently running production on derived keys would mean every secret_key_base rotation quietly orphans your encrypted data.

Adopting RailsFast into an existing project?

If you brought RailsFast into an existing app, bin/setup never built your credentials from scratch, so the keys aren't there yet. Generate them once and paste them in:

bin/rails db:encryption:init        # prints a ready-to-paste active_record_encryption: block
EDITOR="cursor --wait" bin/rails credentials:edit

That's it — encryption works everywhere from then on.