info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
The Rails console interacts directly with GitLab. In many cases,
there are no handrails to prevent you from permanently modifying, corrupting
or destroying production data. If you would like to explore the Rails console
with no consequences, you are strongly advised to do so in a test environment.
The Rails console is for GitLab system administrators who are troubleshooting
a problem or need to retrieve some data that can only be done through direct
access of the GitLab application.
## Starting a Rails console session
**For Omnibus installations**
```shell
sudo gitlab-rails console
```
**For installations from source**
```shell
sudo -u git -H bundle exec rails console -e production
```
**For Kubernetes deployments**
The console is in the task-runner pod. Refer to our [Kubernetes cheat sheet](../troubleshooting/kubernetes_cheat_sheet.md#gitlab-specific-kubernetes-information) for details.
To exit the console, type: `quit`.
## Output Rails console session history
Enter the following command on the rails console to display
your command history.
```ruby
puts Readline::HISTORY.to_a
```
You can then copy it to your clipboard and save for future reference.
## Using the Rails Runner
If you need to run some Ruby code in the context of your GitLab production
environment, you can do so using the [Rails Runner](https://guides.rubyonrails.org/command_line.html#rails-runner).
When executing a script file, the script must be accessible by the `git` user.
When the command or script completes, the Rails Runner process finishes.
It is useful for running within other scripts or cron jobs for example.
You can either move the file to the `/tmp` directory or create a new directory owned by the user `git` and save the script in that directory as illustrated below: