console1984: a Rails console that asks why before it decrypts

A console session starts with a question

console1984 is a Rails console extension that protects sensitive accesses and makes them auditable. Its name comes from the George Orwell quotation it opens with: if you want to keep a secret, you must also hide it from yourself.

The mechanism is simple enough to describe in one line and worth understanding in detail. When a console session starts, the extension asks for a reason, and it uses that reason to document the session and to record all the commands executed in it. The prompt it shows the developer is deliberately pointed:

$ rails c

You have access to production data here. That's a big deal. As part of our promise to keep customer data safe and private, we audit the commands you type here. Let's get started!

Below that, the session lists the available commands, and on a fresh install there is exactly one, decrypt!, which is described as entering unprotected mode with access to encrypted information. Then the question is asked: Unnamed, why are you using this console today?

The phrase Unnamed is not decoration. It comes from the absence of a user identity, and the same wording appears in the consent prompt later, where the developer is asked where the consent for reading personal information can be found, with a URL suggested. The design assumes the console may be opened by someone whose name the application does not know, and asks them to state their purpose in their own words instead.

The tool is MIT licensed, written in Ruby, and the last push to the repository was on 2026-09-25, with released versions v0.2.4 in May 2026, v0.2.3 in February 2026 and v0.2.2 in January 2025.

Installation depends on Rails 7 encryption

The dependency on Active Record encryption is stated as important rather than optional, because it is what makes the rest of the design coherent. The gem goes into the Gemfile:

gem 'console1984'

Then the tables that store console activity are created with a rake task and migrated:

rails console1984:install:migrations
rails db:migrate

The library stores the tracked console commands encrypted, which is why the project documentation also requires configuring Active Record encryption in the application. That is a second setup step people often miss, and it means the gem cannot be dropped into a project that has not already adopted encrypted attributes.

By default the extension is only enabled in production. The target environments are configurable in application.rb:

config.console1984.protected_environments = %i[ production staging ]

The configuration options are all namespaced under config.console1984, and the documented list starts with protected_environments, whose default is %i[ production ], and protected_urls, which is the list of external systems to guard. The repository includes a docker-compose.yml with MySQL 8.0.31 and PostgreSQL 13.4 services on non-default host ports, which suggests the test suite runs against both databases.

Protected mode shows ciphertext, and decrypt! costs a justification

By default console1984 does not decrypt data encrypted with Active Record encryption, so a developer in the console simply sees ciphertexts. The example in the documentation shows a Topic record whose name comes back as an encrypted payload rather than a string.

Typing decrypt! asks for a justification, and the accesses are flagged internally as sensitive. The prompt makes the expectation explicit: before you can access personal information, you need to ask for and get explicit consent from the users, and it asks where that consent can be found. On confirmation the developer is told they have access to encrypted information now, that the team pays extra close attention to any commands entered while the access is open, and that encrypt! returns to protected mode.

The response to the same query then changes, and the documentation shows it changing from an encrypted payload to a readable string. That before and after pair is the clearest possible illustration of what the extension does.

Two rules come with the unprotected mode. You are warned not to save objects that were loaded while in protected mode, because doing so can result in saving the encrypted texts, and while in protected mode you cannot modify encrypted data but can save unencrypted attributes normally, with an attempt to modify an encrypted column raising an error. Running encrypt! returns to protected mode, and the session then asks whether you solved the problem without accessing personal data.

Guarding Elasticsearch and Redis, not just the database

The extension reaches beyond the database, and this is the part that makes it more than a wrapper around decrypt!. Active Record encryption protects personal information stored in the database, but other systems hold sensitive information too, and the documentation names Elasticsearch indexing user information and Redis caching template fragments as examples.

Those systems are registered by adding their URLs to protected_urls in the environment config file:

config.console1984.protected_urls = [ "https://my-app-us-east-1-whatever.us-east-1.es.amazonaws.com", "redis://my-app-cache-1.whatever.cache.amazonaws.com:6379" ]

In the default protected mode, trying to read from a protected system is aborted with an error, and the documented case is Rails.cache.read raising Console1984::Errors::ProtectedConnection. Running decrypt! switches to unprotected mode and allows those systems to be accessed normally, with the justification asked for and the accesses flagged as sensitive.

There is a documented limit on the mechanism. This works for systems that use Ruby sockets as the underlying communication mechanism. Anything that reaches a protected system through a different transport is not covered by this check, which is the boundary to keep in mind when you add URLs to the list and assume it covers every path.

Session trails are incinerated on a schedule

Sessions are destroyed automatically. By default a session is incinerated with a job 30 days after it is created, and the period is configurable:

config.console1984.incinerate_after = 1.year

Incineration can also be turned off entirely:

config.console1984.incinerate = false

This is the one setting with a genuine tension in it, and it is worth deciding deliberately rather than leaving at the default. A trail that is deleted after 30 days protects the people whose commands are in it, which matters when the trail records production queries against personal data. A trail that is kept for a year is what you need to investigate an incident six months later. Neither answer is obviously right, and the default errs towards deletion.

The extension also eager loads all the application classes when a console session starts if necessary. The documentation notes that in practice production environments already load classes eagerly, so this represents no change there.

For the review side of the story, the documentation points to audits1984, a companion auditing tool prepared to work with the console1984 database session trails. The README is clear that if you are looking for the auditing tool, that is the other project, so the two pieces are deliberately separated: this one creates and protects the trail, the other one reads it.

Where console1984 is the wrong choice

The strongest objection is that the protection is a speed bump for a determined developer. The flow requires typing decrypt! and answering a question, and the answers are stored. Nothing stops someone who has decided to read the data from doing exactly that and writing a justification. What the extension actually delivers is accountability, not prevention, and a team hoping it will stop a curious or careless developer from looking at production records should be clear about which of the two they are getting.

The second limitation is the Rails 7 requirement. Active Record encryption is not optional, so an application that stores personal data in plain columns, or that encrypted data in another system such as an external KMS-managed store, gets nothing from this gem. The extension also assumes the model layer, and it protects what it can reach through Ruby sockets, which leaves other transports uncovered.

The third is the cost of the session trail itself. Every command in every protected session is recorded and encrypted, which means a write path on the production database for developer activity. On a busy team that is a steady stream of rows, and the 30 day incineration job is work the application now owns.

The alternative to weigh is operational rather than technical. Some teams solve the same problem by not giving developers production credentials at all, and instead running ad hoc queries through a read replica or a job runner that logs in its own way. console1984 is the better fit when you genuinely need interactive console access to production, because it keeps that access while making it attributable. If you can remove the access instead, the trail is redundant.

Editorial conclusion

console1984 fits a Rails team running a production console against real customer data, where the standard Rails console would hand anyone with a shell the decrypted records. It does not fit a project that does not use Active Record encryption, since that dependency is not optional, and it does not protect against a developer who simply types decrypt! and then changes the data. Before adopting it, confirm your Rails version supports Active Record encryption, set the protected environments explicitly rather than relying on the production default, and decide how long you want session trails to survive, since the default incineration happens 30 days after creation and is reversible through configuration.

Frequently asked questions

Official sources

1. basecamp/console1984 on GitHub
2. Issues
3. License: MIT
4. README
5. Releases