The Rails Command Line

After reading this guide, you will know how to use the Rails command line:

To create a Rails application.
To generate models, controllers, tests, and database migrations.
To start a development server.
To inspect a Rails application through an interactive shell.
To add and edit credentials.

1. Overview

The Rails command line is a powerful part of the Ruby on Rails framework. It allows you to quickly start a new application by generating boilerplate code (that follows Rails conventions). This guide includes an overview of Rails commands that allow you to manage all aspects of your web application, including the database.

You can get a list of commands available to you, which will often depend on your current directory, by typing bin/rails --help. Each command has a description to help clarify what it does.

$ bin/rails --help
Usage:
  bin/rails COMMAND [options]

You must specify a command. The most common commands are:

  generate     Generate new code (short-cut alias: "g")
  console      Start the Rails console (short-cut alias: "c")
  server       Start the Rails server (short-cut alias: "s")
  test         Run tests except system tests (short-cut alias: "t")
  test:system  Run system tests
  dbconsole    Start a console for the database specified in config/database.yml
               (short-cut alias: "db")
  plugin new   Create a new Rails railtie or engine

All commands can be run with -h (or --help) for more information.

The output of bin/rails --help then proceeds to list all commands in alphabetical order, with a short description of each:

In addition to those commands, there are:
about                              List versions of all Rails frameworks ...
action_mailbox:ingress:exim        Relay an inbound email from Exim to ...
action_mailbox:ingress:postfix     Relay an inbound email from Postfix ...
action_mailbox:ingress:qmail       Relay an inbound email from Qmail to ...
action_mailbox:install             Install Action Mailbox and its ...
...
db:fixtures:load                   Load fixtures into the ...
db:migrate                         Migrate the database ...
db:migrate:status                  Display status of migrations
db:rollback                        Roll the schema back to ...
...
turbo:install                      Install Turbo into the app
turbo:install:bun                  Install Turbo into the app with bun
turbo:install:importmap            Install Turbo into the app with asset ...
turbo:install:node                 Install Turbo into the app with webpacker
turbo:install:redis                Switch on Redis and use it in development
version                            Show the Rails version
yarn:install                       Install all JavaScript dependencies as ...
zeitwerk:check                     Check project structure for Zeitwerk ...

In addition to bin/rails --help, running any command from the list above with the --help flag can also be useful. For example, you can learn about the options that can be used with bin/rails routes:

$ bin/rails routes --help
Usage:
  bin/rails routes

Options:
  -c, [--controller=CONTROLLER]      # Filter by a specific controller, e.g. PostsController or Admin::PostsController.
  -g, [--grep=GREP]                  # Grep routes by a specific pattern.
  -E, [--expanded], [--no-expanded]  # Print routes expanded vertically with parts explained.
  -u, [--unused], [--no-unused]      # Print unused routes.

List all the defined routes

Most Rails command line subcommands can be run with --help (or -h) and the output can be very informative. For example bin/rails generate model --help prints two pages of description, in addition to usage and options:

$ bin/rails generate model --help
Usage:
  bin/rails generate model NAME [field[:type][:index] field[:type][:index]] [options]
Options:
...
Description:
    Generates a new model. Pass the model name, either CamelCased or
    under_scored, and an optional list of attribute pairs as arguments.

    Attribute pairs are field:type arguments specifying the
    model's attributes. Timestamps are added by default, so you don't have to
    specify them by hand as 'created_at:datetime updated_at:datetime'.

    As a special case, specifying 'password:digest' will generate a
    password_digest field of string type, and configure your generated model and
    tests for use with Active Model has_secure_password (assuming the default ORM and test framework are being used).
    ...

Some of the most commonly used commands are:

bin/rails console
bin/rails server
bin/rails test
bin/rails generate
bin/rails db:migrate
bin/rails db:create
bin/rails routes
bin/rails dbconsole
rails new app_name

We'll cover the above commands (and more) in the following sections, starting with the command for creating a new application.

2. Creating a New Rails Application

We can create a brand new Rails application using the rails new command.

You will need the rails gem installed in order to run the rails new command. You can do this by typing gem install rails - for more step-by-step instructions, see the Installing Ruby on Rails guide.

With the new command, Rails will set up the entire default directory structure along with all the code needed to run a sample application right out of the box. The first argument to rails new is the application name:

$ rails new my_app
     create
     create  README.md
     create  Rakefile
     create  config.ru
     create  .gitignore
     create  Gemfile
     create  app
     ...
     create  tmp/cache
     ...
        run  bundle install

You can pass options to the new command to modify its default behavior. You can also create application templates and use them with the new command.

2.1. Configure a Different Database

When creating a new Rails application, you can specify a preferred database for your application by using the --database option. The default database for rails new is SQLite. For example, you can set up a PostgreSQL database like this:

$ rails new booknotes --database=postgresql
      create
      create  app/controllers
      create  app/helpers
...

The main difference is the content of the config/database.yml file. With the PostgreSQL option, it looks like this:

# PostgreSQL. Versions 9.3 and up are supported.
#
# Install the pg driver:
#   gem install pg
# On macOS with Homebrew:
#   gem install pg -- --with-pg-config=/usr/local/bin/pg_config
# On Windows:
#   gem install pg
#       Choose the win32 build.
#       Install PostgreSQL and put its /bin directory on your path.
#
# Configure Using Gemfile
# gem "pg"
#
default: &default
  adapter: postgresql
  encoding: unicode
  # For details on connection pooling, see Rails configuration guide
  # https://guides.rubyonrails.org/configuring.html#database-pooling
  pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 3 } %>


development:
  <<: *default
  database: booknotes_development
  ...

The --database=postgresql option will also modify other files generated for a new Rails app appropriately, such as adding the pg gem to the Gemfile, etc.

2.2. Skipping Defaults

The rails new command by default creates dozens of files. By using the --skip option, you can skip some files from being generated if you don't need them. For example,

$ rails new no_storage --skip-active-storage
Based on the specified options, the following options will also be activated:

  --skip-action-mailbox [due to --skip-active-storage]
  --skip-action-text [due to --skip-active-storage]

      create
      create  README.md
      ...

In the above example, Action Mailbox and Action Text are skipped in addition to Active Storage because they depend on Active Storage functionality.

You can get a full list of what can be skipped in the options section of rails new --help command.

3. Starting a Rails Application Server

We can start a Rails application using the bin/rails server command, which launches the Puma web server that comes bundled with Rails. You'll use this any time you want to access your application through a web browser.

$ cd my_app
$ bin/rails server
=> Booting Puma
=> Rails 8.2.0 application starting in development
=> Run `bin/rails server --help` for more startup options
Puma starting in single mode...
* Puma version: 6.4.0 (ruby 3.1.3-p185) ("The Eagle of Durango")
*  Min threads: 3
*  Max threads: 3
*  Environment: development
*          PID: 5295
* Listening on http://127.0.0.1:3000
* Listening on http://[::1]:3000
Use Ctrl-C to stop

With just two commands we have a Rails application up and running. The server command starts the application listening on port 3000 by default. You can open your browser to http://localhost:3000 to see a basic Rails application running.

Most common commands have a shortcut aliases. To start the server you can use the alias "s": bin/rails s.

You can run the application on a different port using the -p option. You can also change the environment using -e (default is development).

$ bin/rails server -e production -p 4000

The -b option binds Rails to the specified IP address, by default it is localhost. You can run a server as a daemon by passing a -d option.

4. Generating Code

You can use the bin/rails generate command to generate a number of different files and add functionality to your application, such as models, controllers, and full scaffolds.

To see a list of built-in generators, you can run bin/rails generate (or bin/rails g for short) without any arguments. It lists all available generators after the usage. You can also learn more about what a specific generator will do by using the --pretend option.

$ bin/rails generate
Usage:
  bin/rails generate GENERATOR [args] [options]

General options:
  -h, [--help]     # Print generator's options and usage
  -p, [--pretend]  # Run but do not make any changes
  -f, [--force]    # Overwrite files that already exist
  -s, [--skip]     # Skip files that already exist
  -q, [--quiet]    # Suppress status output

Please choose a generator below.
Rails:
  application_record
  benchmark
  channel
  controller
  generator
  helper
...

When you add certain gems to your application, they may install more generators. You can also create your own generators, see the Generators guide for more information.

The purpose of Rails' built-in generators is to save you time by freeing you from having to write repetitive boilerplate code.

Let's add a controller with the controller generator.

4.1. Generating Controllers

We can find out exactly how to use the controller generator with the bin/rails generate controller command (which is the same as using it with --help). There is a "Usage" section and even an example:

$ bin/rails generate controller
Usage:
  bin/rails generate controller NAME [action action] [options]
...
Examples:
    `bin/rails generate controller credit_cards open debit credit close`

    This generates a `CreditCardsController` with routes like /credit_cards/debit.
        Controller: app/controllers/credit_cards_controller.rb
        Test:       test/controllers/credit_cards_controller_test.rb
        Views:      app/views/credit_cards/debit.html.erb [...]
        Helper:     app/helpers/credit_cards_helper.rb

    `bin/rails generate controller users index --skip-routes`

    This generates a `UsersController` with an index action and no routes.

    `bin/rails generate controller admin/dashboard --parent=admin_controller`

    This generates a `Admin::DashboardController` with an `AdminController` parent class.

The controller generator is expecting parameters in the form of generate controller ControllerName action1 action2. Let's make a Greetings controller with an action of hello, which will say something nice to us.

$ bin/rails generate controller Greetings hello
     create  app/controllers/greetings_controller.rb
      route  get 'greetings/hello'
     invoke  erb
     create    app/views/greetings
     create    app/views/greetings/hello.html.erb
     invoke  test_unit
     create    test/controllers/greetings_controller_test.rb
     invoke  helper
     create    app/helpers/greetings_helper.rb
     invoke    test_unit

The above command created various files at specific directories. It created a controller file, a view file, a functional test file, a helper for the view, and added a route.

To test out the new controller, we can modify the hello action and the view to display a message:

class GreetingsController < ApplicationController
  def hello
    @message = "Hello, how are you today?"
  end
end

<h1>A Greeting for You!</h1>
<p><%= @message %></p>

Then, we can start the Rails server, with bin/rails server, and go to the added route http://localhost:3000/greetings/hello to see the message.

Now let's use the generator to add models to our application.

4.2. Generating Models

The Rails model generator command has a very detailed "Description" section that is worth reading. Here is the basic usage:

$ bin/rails generate model
Usage:
  bin/rails generate model NAME [field[:type][:index] field[:type][:index]] [options]
...

As an example, we can generate a post model like this:

$ bin/rails generate model post title:string body:text
    invoke  active_record
    create    db/migrate/20250807202154_create_posts.rb
    create    app/models/post.rb
    invoke    test_unit
    create      test/models/post_test.rb
    create      test/fixtures/posts.yml

The model generator adds test files as well as a migration, which you'll need to run with bin/rails db:migrate.

For a list of available field types for the type parameter, refer to the API documentation. The index parameter generates a corresponding index for the column. If you don't specify a type for a field, Rails will default to type string.

In addition to generating controllers and models separately, Rails also provides generators that add code for both at once as well as other files needed for a standard CRUD resource. There are two generator commands that do this: resource and scaffold. The resource command is more lightweight than scaffold and generates less code.

4.3. Generating Resources

The bin/rails generate resource command generates model, migration, empty controller, routes, and tests. It does not generate views and it does not fill in the controller with CRUD methods.

Here are all the files generated with the resource command for post:

$ bin/rails generate resource post title:string body:text
      invoke  active_record
      create    db/migrate/20250919150856_create_posts.rb
      create    app/models/post.rb
      invoke    test_unit
      create      test/models/post_test.rb
      create      test/fixtures/posts.yml
      invoke  controller
      create    app/controllers/posts_controller.rb
      invoke    erb
      create      app/views/posts
      invoke    test_unit
      create      test/controllers/posts_controller_test.rb
      invoke    helper
      create      app/helpers/posts_helper.rb
      invoke      test_unit
      invoke  resource_route
       route    resources :posts

Use the resource command when you don't need views (e.g. writing an API) or prefer to add controller actions manually.

4.4. Generating Scaffolds

A Rails scaffold generates a full set of files for a resource, including a model, controller, views (HTML and JSON), routes, migration, tests, and helper files. It can be used for quickly prototyping CRUD interfaces or when you want to generate the basic structure of a resource as a starting point that you can customize.

If you scaffold the post resource you can see all of the files mentioned above being generated:

$ bin/rails generate scaffold post title:string body:text
      invoke  active_record
      create    db/migrate/20250919150748_create_posts.rb
      create    app/models/post.rb
      invoke    test_unit
      create      test/models/post_test.rb
      create      test/fixtures/posts.yml
      invoke  resource_route
       route    resources :posts
      invoke  scaffold_controller
      create    app/controllers/posts_controller.rb
      invoke    erb
      create      app/views/posts
      create      app/views/posts/index.html.erb
      create      app/views/posts/edit.html.erb
      create      app/views/posts/show.html.erb
      create      app/views/posts/new.html.erb
      create      app/views/posts/_form.html.erb
      create      app/views/posts/_post.html.erb
      invoke    resource_route
      invoke    test_unit
      create      test/controllers/posts_controller_test.rb
      create      test/system/posts_test.rb
      invoke    helper
      create      app/helpers/posts_helper.rb
      invoke      test_unit
      invoke    jbuilder
      create      app/views/posts/index.json.jbuilder
      create      app/views/posts/show.json.jbuilder
      create      app/views/posts/_post.json.jbuilder

At this point, you can run bin/rails db:migrate to create the post table (see Managing the Database for more on that command). Then, if you start the Rails server with bin/rails server and navigate to http://localhost:3000/posts, you will be able to interact with the post resource - see a list of posts, create new posts, as well as edit and delete them.

The scaffold generates test files, though you will need to modify them and actually add test cases for your code. See the Testing guide for an in-depth look at creating and running tests.

4.5. Undoing Code Generation with `bin/rails destroy`

Imagine you made a typing error when using the generate command for a model (or controller or scaffold or anything), it would be tedious to manually delete each file that was created by the generator. Rails provides a destroy command for that reason. You can think of destroy as the opposite of generate. It'll figure out what generate did, and undo it.

You can also use the alias "d" to invoke the destroy command: bin/rails d.

For example, if you meant to generate an article model but instead typed artcle:

$ bin/rails generate model Artcle title:string body:text
      invoke  active_record
      create    db/migrate/20250808142940_create_artcles.rb
      create    app/models/artcle.rb
      invoke    test_unit
      create      test/models/artcle_test.rb
      create      test/fixtures/artcles.yml

You can undo the generate command with destroy like this:

$ bin/rails destroy model Artcle title:string body:text
      invoke  active_record
      remove    db/migrate/20250808142940_create_artcles.rb
      remove    app/models/artcle.rb
      invoke    test_unit
      remove      test/models/artcle_test.rb
      remove      test/fixtures/artcles.yml

5. Interacting with a Rails Application

5.1. `bin/rails console`

The bin/rails console command loads a full Rails environment (including models, database, etc.) into an interactive IRB style shell. It is a powerful feature of the Ruby on Rails framework as it allows you to interact with, debug and explore your entire application at the command line.

The Rails Console can be useful for testing out ideas by prototyping with code and for creating and updating records in the database without needing to use a browser.

$ bin/rails console
my-app(dev):001:0> Post.create(title: 'First!')

The Rails Console has several useful features. For example, if you wish to test out some code without changing any data, you can use sandbox mode with bin/rails console --sandbox. The sandbox mode wraps all database operations in a transaction that rolls back when you exit:

$ bin/rails console --sandbox
Loading development environment in sandbox (Rails 8.2.0)
Any modifications you make will be rolled back on exit
my-app(dev):001:0>

The sandbox option is great for safely testing destructive changes without affecting your database.

You can also specify the Rails environment for the console command with the -e option:

$ bin/rails console -e test
Loading test environment (Rails 8.1.0)

5.1.1. The `app` Object

Inside the Rails Console you have access to the app and helper instances.

With the app method you can access named route helpers:

my-app(dev)> app.root_path
=> "/"
my-app(dev)> app.edit_user_path
=> "profile/edit"

You can also use the app object to make requests of your application without starting a real server:

my-app(dev)> app.get "/", headers: { "Host" => "localhost" }
Started GET "/" for 127.0.0.1 at 2025-08-11 11:11:34 -0500
...

my-app(dev)> app.response.status
=> 200

You have to pass the "Host" header with the app.get request above, because the Rack client used under-the-hood defaults to "www.example.com" if not "Host" is specified. You can modify your application to always use localhost using a configuration or an initializer.

The reason you can "make requests" like above is because the app object is the same one that Rails uses for integration tests:

my-app(dev)> app.class
=> ActionDispatch::Integration::Session

The app object exposes methods like app.cookies, app.session, app.post, and app.response. This way you can simulate and debug integration tests in the Rails Console.

5.1.2. The `helper` Object

The helper object in the Rails console is your direct portal into Rails’ view layer. It allows you to test out view-related formatting and utility methods in the console, as well as custom helpers defined in your application (i.e. in app/helpers).

my-app(dev)> helper.time_ago_in_words 3.days.ago
=> "3 days"

my-app(dev)> helper.l(Date.today)
=> "2025-08-11"

my-app(dev)> helper.pluralize(3, "child")
=> "3 children"

my-app(dev)> helper.truncate("This is a very long sentence", length: 22)
=> "This is a very long..."

my-app(dev)> helper.link_to("Home", "/")
=> "<a href=\"/\">Home</a>"

Assuming a custom_helper method is defined in a app/helpers/*_helper.rb file:

my-app(dev)> helper.custom_helper
"testing custom_helper"

5.2. `bin/rails dbconsole`

The bin/rails dbconsole command figures out which database you're using and drops you into the command line interface appropriate for that database. It also figures out the command line parameters to start a session based on your config/database.yml file and current Rails environment.

Once you're in a dbconsole session, you can interact with your database directly as you normally would. For example, if you're using PostgreSQL, running bin/rails dbconsole may look like this:

$ bin/rails dbconsole
psql (17.5 (Homebrew))
Type "help" for help.

booknotes_development=# help
You are using psql, the command-line interface to PostgreSQL.
Type:  \copyright for distribution terms
       \h for help with SQL commands
       \? for help with psql commands
       \g or terminate with semicolon to execute query
       \q to quit
booknotes_development=# \dt
                    List of relations
 Schema |              Name              | Type  | Owner
--------+--------------------------------+-------+-------
 public | action_text_rich_texts         | table | bhumi
 ...

The dbconsole command is a very convenient shorthand, it's equivalent to running the psql command (or mysql or sqlite) with the appropriate arguments from your database.yml:

psql -h <host> -p <port> -U <username> <database_name>

So if your database.yml file looks like this:

development:
  adapter: postgresql
  database: myapp_development
  username: myuser
  password:
  host: localhost

Running the bin/rails dbconsole command is the same as:

psql -h localhost -U myuser myapp_development

The dbconsole command supports MySQL (including MariaDB), PostgreSQL, and SQLite3. You can also use the alias "db" to invoke the dbconsole: bin/rails db.

If you are using multiple databases, bin/rails dbconsole will connect to the primary database by default. You can specify which database to connect to using --database or --db:

$ bin/rails dbconsole --database=animals

5.3. `bin/rails runner`

The runner command executes Ruby code in the context of the Rails application without having to open a Rails Console. This can be useful for one-off tasks that do not need the interactivity of the Rails Console. For instance:

$ bin/rails runner "puts User.count"
42

$ bin/rails runner 'MyJob.perform_now'

You can specify the environment in which the runner command should operate using the -e switch.

$ bin/rails runner -e production "puts User.count"

You can also execute code in a Ruby file with the runner command, in the context of your Rails application:

$ bin/rails runner lib/path_to_ruby_script.rb

By default, bin/rails runner scripts are automatically wrapped with the Rails Executor (which is an instance of ActiveSupport::Executor) associated with your Rails application. The Executor creates a “safe zone” to run arbitrary Ruby inside a Rails app so that the autoloader, middleware stack, and Active Support hooks all behave consistently.

Therefore, executing bin/rails runner lib/path_to_ruby_script.rb is functionally equivalent to the following:

Rails.application.executor.wrap do
  # executes code inside lib/path_to_ruby_script.rb
end

If you have a reason to opt of this behavior, there is a --skip-executor option.

$ bin/rails runner --skip-executor lib/long_running_script.rb

5.4. `bin/rails boot`

The bin/rails boot command is a low-level Rails command whose entire job is to boot your Rails application. Specifically it loads config/boot.rb and config/application.rb files so that the application environment is ready to run.

The boot command boots the application and exits — it does nothing else. It can be useful for debugging boot problems. If your app fails to start and you want to isolate the boot phase (without running migrations, starting the server, etc.), bin/rails boot can be a simple test.

It can also be useful for timing application initialization. You can profile how long your application takes to boot by wrapping bin/rails boot in a profiler.

6. Inspecting an Application

6.1. `bin/rails routes`

The bin/rails routes command lists all defined routes in your application, including the URI Pattern and HTTP verb, as well as the Controller Action it maps to.

$ bin/rails routes
  Prefix  Verb  URI Pattern     Controller#Action
  books   GET   /books(:format) books#index
  books   POST  /books(:format) books#create
  ...
  ...

This can be useful for tracking down a routing issue, or simply getting an overview of the resources and routes that are part of a Rails application. You can also narrow down the output of the routes command with options like --controller(-c) or --grep(-g):

# Only show routes where the controller name contains "users"
$ bin/rails routes --controller users

# Show routes handled by namespace Admin::UsersController
$ bin/rails routes -c admin/users

# Search by name, path, or controller/action with -g (or --grep)
$ bin/rails routes -g users

There is also an option, bin/rails routes --expanded, that displays even more information about each route, including the line number in your config/routes.rb where that route is defined:

$ bin/rails routes --expanded
--[ Route 1 ]--------------------------------------------------------------------------------
Prefix            |
Verb              |
URI               | /assets
Controller#Action | Propshaft::Server
Source Location   | propshaft (1.2.1) lib/propshaft/railtie.rb:49
--[ Route 2 ]--------------------------------------------------------------------------------
Prefix            | about
Verb              | GET
URI               | /about(.:format)
Controller#Action | posts#about
Source Location   | /Users/bhumi/Code/try_markdown/config/routes.rb:2
--[ Route 3 ]--------------------------------------------------------------------------------
Prefix            | posts
Verb              | GET
URI               | /posts(.:format)
Controller#Action | posts#index
Source Location   | /Users/bhumi/Code/try_markdown/config/routes.rb:4

In development mode, you can also access the same routes info by going to http://localhost:3000/rails/info/routes

6.2. `bin/rails about`

The bin/rails about command displays information about your Rails application, such as Ruby, RubyGems, and Rails versions, database adapter, schema version, etc. It is useful when you need to ask for help or check if a security patch might affect you.

$ bin/rails about
About your application's environment
Rails version             8.2.0
Ruby version              3.2.0 (x86_64-linux)
RubyGems version          3.3.7
Rack version              3.0.8
JavaScript Runtime        Node.js (V8)
Middleware:               ActionDispatch::HostAuthorization, Rack::Sendfile, ...
Application root          /home/code/my_app
Environment               development
Database adapter          sqlite3
Database schema version   20250205173523

6.3. `bin/rails initializers`

The bin/rails initializers command prints out all defined initializers in the order they are invoked by Rails:

$ bin/rails initializers
ActiveSupport::Railtie.active_support.deprecator
ActionDispatch::Railtie.action_dispatch.deprecator
ActiveModel::Railtie.active_model.deprecator
...
Booknotes::Application.set_routes_reloader_hook
Booknotes::Application.set_clear_dependencies_hook
Booknotes::Application.enable_yjit

This command can be useful when initializers depend on each other and the order in which they are run matters. Using this command, you can see what's run before/after and discover the relationship between initializers. Rails runs framework initializers first and then application ones, defined in config/initializers.

6.4. `bin/rails middleware`

The bin/rails middleware shows you the entire Rack middleware stack for your Rails application, in the exact order the middlewares are run for each request.

$ bin/rails middleware
use ActionDispatch::HostAuthorization
use Rack::Sendfile
use ActionDispatch::Static
use ActionDispatch::Executor
use ActionDispatch::ServerTiming
...

This can be useful to see which middleware Rails includes and which ones are added by gems (Warden::Manager from Devise) as well as for debugging and profiling.

6.5. `bin/rails stats`

The bin/rails stats command shows you things like lines of code (LOC) and the number of classes and methods for various components in your application.

$ bin/rails stats
+----------------------+--------+--------+---------+---------+-----+-------+
| Name                 |  Lines |    LOC | Classes | Methods | M/C | LOC/M |
+----------------------+--------+--------+---------+---------+-----+-------+
| Controllers          |    309 |    247 |       7 |      37 |   5 |     4 |
| Helpers              |     10 |     10 |       0 |       0 |   0 |     0 |
| Jobs                 |      7 |      2 |       1 |       0 |   0 |     0 |
| Models               |     89 |     70 |       6 |       3 |   0 |    21 |
| Mailers              |     10 |     10 |       2 |       1 |   0 |     8 |
| Channels             |     16 |     14 |       1 |       2 |   2 |     5 |
| Views                |    622 |    501 |       0 |       1 |   0 |   499 |
| Stylesheets          |    584 |    495 |       0 |       0 |   0 |     0 |
| JavaScript           |     81 |     62 |       0 |       0 |   0 |     0 |
| Libraries            |      0 |      0 |       0 |       0 |   0 |     0 |
| Controller tests     |    117 |     75 |       4 |       9 |   2 |     6 |
| Helper tests         |      0 |      0 |       0 |       0 |   0 |     0 |
| Model tests          |     21 |      9 |       3 |       0 |   0 |     0 |
| Mailer tests         |      7 |      5 |       1 |       1 |   1 |     3 |
| Integration tests    |      0 |      0 |       0 |       0 |   0 |     0 |
| System tests         |     51 |     41 |       1 |       4 |   4 |     8 |
+----------------------+--------+--------+---------+---------+-----+-------+
| Total                |   1924 |   1541 |      26 |      58 |   2 |    24 |
+----------------------+--------+--------+---------+---------+-----+-------+
  Code LOC: 1411     Test LOC: 130     Code to Test Ratio: 1:0.1

6.6. `bin/rails time:zones:all`

Thebin/rails time:zones:all command prints the complete list of time zones that Active Support knows about, along with their UTC offsets followed by the Rails timezone identifiers.

As an example, you can use bin/rails time:zones:local to see your system's timezone:

$ bin/rails time:zones:local

* UTC -06:00 *
Central America
Central Time (US & Canada)
Chihuahua
Guadalajara
Mexico City
Monterrey
Saskatchewan

This can be useful when setting config.time_zone in config/application.rb, when you need an exact Rails time zone name and spelling (e.g., "Pacific Time (US & Canada)"), to validate user input or when debugging.

7. Managing Assets

The bin/rails assets:* commands allow you to manage assets in the app/assets directory.

You can get a list of all commands in the assets: namespace like this:

$ bin/rails -T assets
bin/rails assets:clean[count]  # Removes old files in config.assets.output_path
bin/rails assets:clobber       # Remove config.assets.output_path
bin/rails assets:precompile    # Compile all the assets from config.assets.paths
bin/rails assets:reveal        # Print all the assets available in config.assets.paths
bin/rails assets:reveal:full   # Print the full path of assets available in config.assets.paths

You can precompile the assets in app/assets using bin/rails assets:precompile. See the Asset Pipeline guide for more on precompiling.

You can remove older compiled assets using bin/rails assets:clean. The assets:clean command allows for rolling deploys that may still be linking to an old asset while the new assets are being built.

If you want to clear public/assets completely, you can use bin/rails assets:clobber. assets:clobber`.

8. Managing the Database

The commands in this section, bin/rails db:*, are all about setting up databases, managing migrations, etc.

You can get a list of all commands in the db: namespace like this:

$ bin/rails -T db
bin/rails db:create              # Create the database from DATABASE_URL or
bin/rails db:drop                # Drop the database from DATABASE_URL or
bin/rails db:encryption:init     # Generate a set of keys for configuring
bin/rails db:environment:set     # Set the environment value for the database
bin/rails db:fixtures:load       # Load fixtures into the current environments
bin/rails db:migrate             # Migrate the database (options: VERSION=x,
bin/rails db:migrate:down        # Run the "down" for a given migration VERSION
bin/rails db:migrate:redo        # Roll back the database one migration and
bin/rails db:migrate:status      # Display status of migrations
bin/rails db:migrate:up          # Run the "up" for a given migration VERSION
bin/rails db:prepare             # Run setup if database does not exist, or run
bin/rails db:reset               # Drop and recreate all databases from their
bin/rails db:rollback            # Roll the schema back to the previous version
bin/rails db:schema:cache:clear  # Clear a db/schema_cache.yml file
bin/rails db:schema:cache:dump   # Create a db/schema_cache.yml file
bin/rails db:schema:dump         # Create a database schema file (either db/
bin/rails db:schema:load         # Load a database schema file (either db/
bin/rails db:seed                # Load the seed data from db/seeds.rb
bin/rails db:seed:replant        # Truncate tables of each database for current
bin/rails db:setup               # Create all databases, load all schemas, and
bin/rails db:version             # Retrieve the current schema version number
bin/rails test:db                # Reset the database and run `bin/rails test`

8.1. Database Setup

The db:create and db:drop commands create or delete the database for the current environment (or all environments with the db:create:all, db:drop:all)

The db:seed command loads sample data from db/seeds.rb and the db:seed:replant command truncates tables of each database for the current environment and then loads the seed data.

The db:setup command creates all databases, loads all schemas, and initializes with the seed data (it does not drop databases first, like the db:reset command below).

The db:reset command drops and recreates all databases from their schema for the current environment and loads the seed data (so it's a combination of the above commands).

For more on seed data, see this section of the Active Record Migrations guide.

8.2. Migrations

The db:migrate command is one of the most frequently run commands in a Rails application; it migrates the database by running all new (not yet run) migrations.

The db:migrate:up command runs the "up" method and the db:migrate:down command runs the "down" method for the migration specified by the VERSION argument.

$ bin/rails db:migrate:down VERSION=20250812120000

The db:rollback command rolls the schema back to the previous version (or you can specify steps with the STEP=n argument).

The db:migrate:redo command rolls back the database one migration and re-migrates up. It is a combination of the above two commands.

There is also a db:migrate:status command, which shows which migrations have been run and which are still pending:

$ bin/rails db:migrate:status
database: db/development.sqlite3

 Status   Migration ID    Migration Name
--------------------------------------------------
   up     20250101010101  Create users
   up     20250102020202  Add email to users
  down    20250812120000  Add age to users

Please see the Migration Guide for an explanation of concepts related to database migrations and other migration commands.

8.3. Schema Management

There are two main commands that help with managing the database schema in your Rails application: db:schema:dump and db:schema:load.

The db:schema:dump command reads your database’s current schema and writes it out to the db/schema.rb file (or db/structure.sql if you’ve configured the schema format to sql). After running migrations, Rails automatically calls schema:dump so your schema file is always up to date (and doesn't need to be modified manually).

The schema file is a blueprint of your database and it is useful for setting up new environments for tests or development. It’s version-controlled, so you can see changes to the schema over time.

The db:schema:load command drops and recreates the database schema from db/schema.rb (or db/structure.sql). It does this directly, without replaying each migration one at a time.

This command is useful for quickly resetting a database to the current schema without running years of migrations one by one. For example, running db:setup also calls db:schema:load after creating the database and before seeding it.

You can think of db:schema:dump as the one that writes the schema.rb file and db:schema:load as the one that reads that file.

8.4. Other Utility Commands

8.4.1. `bin/rails db:version`

The bin/rails db:version command will show you the current version of the database, which can be useful for troubleshooting.

$ bin/rails db:version

database: storage/development.sqlite3
Current version: 20250806173936

8.4.2. `db:fixtures:load`

The db:fixtures:load command loads fixtures into the current environment's database. To load specific fixtures, you can use FIXTURES=x,y. To load from a subdirectory in test/fixtures, use FIXTURES_DIR=z.

$ bin/rails db:fixtures:load
   -> Loading fixtures from test/fixtures/users.yml
   -> Loading fixtures from test/fixtures/books.yml

8.4.3. `db:system:change`

In an existing Rails application, it's possible to switch to a different database. The db:system:change command helps with that by changing the config/database.yml file and your database gem to the target database.

$ bin/rails db:system:change --to=postgresql
    conflict  config/database.yml
Overwrite config/database.yml? (enter "h" for help) [Ynaqdhm] Y
       force  config/database.yml
        gsub  Gemfile
        gsub  Gemfile
...

8.4.4. `db:encryption:init`

The db:encryption:init command generates a set of keys for configuring Active Record encryption in a given environment.

9. Running Tests

The bin/rails test command helps you run the different types of tests in your application. The bin/rails test --help output has good examples of the different options for this command:

You can run a single test by appending a line number to a filename:

  bin/rails test test/models/user_test.rb:27

You can run multiple tests within a line range by appending the line range to a filename:

  bin/rails test test/models/user_test.rb:10-20

You can run multiple files and directories at the same time:

  bin/rails test test/controllers test/integration/login_test.rb

Rails comes with a testing framework called Minitest and there are also Minitest options you can use with the test command:

# Only run tests whose names match the regex /validation/
$ bin/rails test -n /validation/

Please see the Testing Guide for explanations and examples of different types of tests.

10. Other Useful Commands

10.1. `bin/rails notes`

The bin/rails notes command searches through your code for comments beginning with a specific keyword. You can refer to bin/rails notes --help for information about usage.

By default, it will search in app, config, db, lib, and test directories for FIXME, OPTIMIZE, and TODO annotations in files with extension .builder, .rb, .rake, .yml, .yaml, .ruby, .css, .js, and .erb.

$ bin/rails notes
app/controllers/admin/users_controller.rb:
  * [ 20] [TODO] any other way to do this?
  * [132] [FIXME] high priority for next deploy

lib/school.rb:
  * [ 13] [OPTIMIZE] refactor this code to make it faster

10.1.1. Annotations

You can pass specific annotations by using the -a (or --annotations) option. Note that annotations are case sensitive.

$ bin/rails notes --annotations FIXME RELEASE
app/controllers/admin/users_controller.rb:
  * [101] [RELEASE] We need to look at this before next release
  * [132] [FIXME] high priority for next deploy

lib/school.rb:
  * [ 17] [FIXME]

10.1.2. Add Tags

You can add more default tags to search for by using config.annotations.register_tags:

config.annotations.register_tags("DEPRECATEME", "TESTME")

$ bin/rails notes
app/controllers/admin/users_controller.rb:
  * [ 20] [TODO] do A/B testing on this
  * [ 42] [TESTME] this needs more functional tests
  * [132] [DEPRECATEME] ensure this method is deprecated in next release

10.1.3. Add Directories

You can add more default directories to search from by using config.annotations.register_directories:

config.annotations.register_directories("spec", "vendor")

10.1.4. Add File Extensions

You can add more default file extensions by using config.annotations.register_extensions:

config.annotations.register_extensions("scss", "sass") { |annotation| /\/\/\s*(#{annotation}):?\s*(.*)$/ }

10.2. `bin/rails tmp:`

The Rails.root/tmp directory is, like the *nix /tmp directory, the holding place for temporary files like process id files and cached actions.

The tmp: namespaced commands will help you clear and create the Rails.root/tmp directory:

$ bin/rails tmp:cache:clear # clears `tmp/cache`.
$ bin/rails tmp:sockets:clear # clears `tmp/sockets`.
$ bin/rails tmp:screenshots:clear` # clears `tmp/screenshots`.
$ bin/rails tmp:clear # clears all cache, sockets, and screenshot files.
$ bin/rails tmp:create # creates tmp directories for cache, sockets, and pids.

10.3. `bin/rails secret`

The bin/rails secret command generates a cryptographically secure random string for use as a secret key in your Rails application.

$ bin/rails secret
4d39f92a661b5afea8c201b0b5d797cdd3dcf8ae41a875add6ca51489b1fbbf2852a666660d32c0a09f8df863b71073ccbf7f6534162b0a690c45fd278620a63

It can be useful for setting the secret key in your application's config/credentials.yml.enc file.

10.4. `bin/rails credentials`

The credentials commands provide access to encrypted credentials, so you can safely store access tokens, database passwords, and the like inside the app without relying on a bunch of environment variables.

To add values to the encrypted YML file config/credentials.yml.enc, you can use the credentials:edit command:

$ bin/rails credentials:edit

This opens the decrypted credentials in an editor (set by $VISUAL or $EDITOR) for editing. When saved, the content is encrypted automatically.

You can also use the :show command to view the decrypted credential file, which may look something like this (This is from a sample application and not sensitive data):

$ bin/rails credentials:show
# aws:
#   access_key_id: 123
#   secret_access_key: 345
active_record_encryption:
  primary_key: 99eYu7ZO0JEwXUcpxmja5PnoRJMaazVZ
  deterministic_key: lGRKzINTrMTDSuuOIr6r5kdq2sH6S6Ii
  key_derivation_salt: aoOUutSgvw788fvO3z0hSgv0Bwrm76P0

# Used as the base secret for all MessageVerifiers in Rails, including the one protecting cookies.
secret_key_base: 6013280bda2fcbdbeda1732859df557a067ac81c423855aedba057f7a9b14161442d9cadfc7e48109c79143c5948de848ab5909ee54d04c34f572153466fc589

You can learn about credentials in the Rails Security Guide.

Check out the detailed description for this command in the output of bin/rails credentials --help.

11. Custom Rake Tasks

You may want to create custom rake tasks in your application, to delete old records from the database for example. You can do this with the the bin/rails generate task command. Custom rake tasks have a .rake extension and are placed in the lib/tasks folder in your Rails application. For example:

$ bin/rails generate task cool
create  lib/tasks/cool.rake

The cool.rake file can contain this:

desc "I am short description for a cool task"
task task_name: [:prerequisite_task, :another_task_we_depend_on] do
  # Any valid Ruby code is allowed.
end

To pass arguments to your custom rake task:

task :task_name, [:arg_1] => [:prerequisite_1, :prerequisite_2] do |task, args|
  argument_1 = args.arg_1
end

You can group tasks by placing them in namespaces:

namespace :db do
  desc "This task has something to do with the database"
  task :my_db_task do
    # ...
  end
end

Invoking rake tasks looks like this:

$ bin/rails task_name
$ bin/rails "task_name[value1]" # entire argument string should be quoted
$ bin/rails "task_name[value1, value2]" # separate multiple args with a comma
$ bin/rails db:my_db_task

If you need to interact with your application models, perform database queries, and so on, your task can depend on the environment task, which will load your Rails application.

task task_that_requires_app_code: [:environment] do
  puts User.count
end