# RailsAdmin: the Rails engine that gives you an admin panel in one generator run

> RailsAdmin mounts a CRUD interface over your ActiveRecord or Mongoid models from a single Rails engine, with Devise, CanCanCan, Pundit and PaperTrail as optional add-ons. It is for teams that want a working admin page today and are willing to accept its defaults.

**railsadminteam/rails_admin** — RailsAdmin is a Rails engine that provides an easy-to-use interface for managing your data

- Repository: https://github.com/railsadminteam/rails_admin
- Stars: 7,955 · Forks: 2,227
- Language: Ruby
- License: MIT
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/railsadminteam-rails-admin

## What RailsAdmin actually replaces

Every Rails app with more than a couple of models eventually needs a screen where a support person can fix a mistyped email address or delete a duplicate row. RailsAdmin is the answer Rails gives to that need: a Rails engine, distributed as the rails_admin gem, that reads your models and renders list, show, edit and delete views for them. The description in the README is one sentence long, and that restraint is accurate. It is not a CMS, not a workflow tool, and not a reporting layer. It is a data browser with forms.

The audience is narrow and identifiable. You already have a Rails application, your models are backed by ActiveRecord or Mongoid (the two ORMs the README lists as supported), and you want an admin interface without building routes, controllers, views and form objects by hand. If your data lives somewhere else, or if your application does not use Rails at all, the engine has nothing to attach to.

## The engine model: routes, controllers and views shipped as a gem

RailsAdmin works the way Rails engines work. The gem ships an app/ directory, a config/ directory and a lib/ directory, and mounting it in your routes file gives it a namespace under which its own controllers and views run. The README's install flow ends by telling you to administer your data at /admin if you accepted the default namespace, which is the clearest statement of how the routing works: the engine owns a path prefix and everything below it.

Configuration happens in two places. Globally, in config/initializers/rails_admin.rb, which the README points at for base configuration. Per model, inside a rails_admin block in the model class itself. The README's Ball example shows the shape: a block that calls configure :player and sets a label. That block is the extension point for field visibility, labels and grouping, and the README links separate documents for models, groups and fields.

The front end is not server-rendered HTML alone. The repository's package.json lists Bootstrap 5, jQuery, jQuery UI, flatpickr, Popper, Font Awesome, @rails/ujs and @hotwired/turbo-rails as dependencies, and the package is published with a src/ directory as its main entry. So the admin UI is a JavaScript and SCSS bundle as well as a set of Ruby views. That is the reason the upgrade notes for 2.x mention Webpack and Webpacker support: the asset side of the engine changed enough to require configuration work in the host app.

## Installing the rails_admin gem and reaching /admin

The README gives a five-step install. Add the gem to the Gemfile pinned to the 3.x line, bundle, run the install generator, answer the namespace prompt, and start the server.

```ruby
gem 'rails_admin', '~> 3.0'
```

After the Gemfile edit, run bundle install and then the generator. The generator asks for a namespace for the routes; the README notes that if you choose the default, the panel lives at /admin.

```bash
bundle install
rails g rails_admin:install
rails s
```

With the server running, open http://localhost:3000/admin. You should see the RailsAdmin interface listing the models it discovered in your application. Authentication is not part of that first screen: the README lists authentication as a feature available via Devise or another mechanism, and points to a separate document for Devise setup. Until you wire that up, whatever the engine exposes is reachable by anyone who can reach the route, so the initializer and the authentication document are the next thing to read, not an optional extra.

Per-model customization goes in the model. The README's example adds a label to a belongs_to association:

```ruby
class Ball < ActiveRecord::Base
  validates :name, presence: true
  belongs_to :player

  rails_admin do
    configure :player do
      label 'Owner of this ball: '
    end
  end
end
```

That block is where you spend most of your configuration time once the panel is up.

## Authentication and authorization are deliberately left outside

RailsAdmin does not ship its own user model. The README lists authentication via Devise or other, authorization via CanCanCan or Pundit, and user action history via PaperTrail, each as a feature with its own linked document. That is a defensible split: most Rails apps already have a user table and an authorization gem, and a second one would be a conflict rather than a convenience.

The cost is that the default install is open. The generator will not create a login screen for you, and the README does not present an unauthenticated admin panel as a temporary state to be fixed later. If you mount the engine and walk away, you have published a CRUD interface over your database at a predictable path. The authorization documents are the ones to read before the first deploy, and the choice between CanCanCan and Pundit is a real fork in the road: they express rules differently, and the README treats them as alternatives rather than as layers.

## Upgrading from 2.x and what the Webpack change costs

The README has a short section on upgrading from 2.x, and it is honest about the shape of the work without being complete. It states that Webpack and Webpacker support were introduced, that this brings additional dependency and configuration requirements, and that running rails g rails_admin:install will suggest required changes based on the current setup of your app. It does not enumerate those changes, and it does not document rollback.

That is the practical upgrade risk. The gem's JavaScript dependencies now include Turbo and Bootstrap 5, and the generator makes suggestions rather than performing a fixed, documented transformation. If your application already has an asset pipeline configuration with opinions, the generator's suggestions need to be read rather than accepted. There is no release notes file at the top level of the repository (the entries include CHANGELOG.md, so change history lives there rather than in a GitHub releases feed), and the README does not give a version compatibility matrix beyond the Ruby versions listed below.

## Ruby and ORM support boundaries

The README lists the Ruby implementations the library aims to support and is tested against: Ruby 2.7 through 3.4, plus JRuby. The upper bound matters if you track Ruby releases closely, and the lower bound tells you the project still carries compatibility with older applications rather than requiring a recent runtime.

The harder boundary is the ORM list. ActiveRecord and Mongoid are the two supported options. If your application uses Sequel, ROM or a hand-rolled persistence layer, RailsAdmin has no path to your models, because the engine's field discovery and form generation are built around those two. That is a design constraint, not a missing plugin. The per-model rails_admin block and the association configuration shown in the README both assume ActiveModel-style associations and validations, which is why the README can promise automatic form validation as a feature at all.

## RailsAdmin against Active Admin and Avo

The related searches around this project pair it most often with Active Admin, and the comparison is fair because both are Rails engines that mount an admin namespace. Active Admin's approach centers on a generated resource file per model, where you declare the index, filters, form and show page as Ruby DSL blocks in app/admin. RailsAdmin inverts that: the default interface is derived from the model, and you adjust it with a rails_admin block inside the model class, as the Ball example shows. RailsAdmin's configuration therefore lives in your domain code, and Active Admin's lives in dedicated admin files. Teams that dislike mixing presentation into models will prefer the second arrangement; teams that want the panel to follow the schema automatically will prefer the first.

Avo is the other name that appears in the same searches. It is a newer admin framework for Rails, and the README does not describe it, so the honest statement is that the difference in approach is not documented in this repository. What can be said from the README is what RailsAdmin itself commits to: CRUD over ActiveRecord and Mongoid, custom actions, search and filtering, and export to CSV, JSON and XML, with authentication and authorization delegated to other gems. Compare those four capabilities against whatever the alternative documents, rather than against a summary.

## Maintenance, licence and what to check before adopting

The repository is not archived, and the last push was on 2026-09-21, one day before this writing. That is a current codebase by any reasonable reading, and the presence of a GitHub Actions test workflow, Coveralls and Code Climate badges in the README is consistent with a project that runs continuous integration. Note what those badges are: build, coverage and code quality signals, not measures of fitness for your application.

The licence is MIT, stated in the README badge table and in the repository's LICENSE.md. MIT is permissive: it allows commercial and closed-source use, and it places the copyright and permission notice in the distributed copies. This is a statement of what the licence text says, not legal advice; if your organisation has a licence review process, send it the LICENSE.md file rather than a summary.

Upgrade cost is the part to budget for. The 2.x to 3.x transition required asset configuration changes, the gem's front-end dependencies include Bootstrap 5, jQuery and Turbo, and the generator suggests changes instead of applying a documented set. A Rails app with a heavily customized asset pipeline should treat the generator output as a diff to review. The supported Ruby range, 2.7 to 3.4 plus JRuby, is wide, which reduces the pressure to upgrade the runtime and the gem at the same time.

## Conclusion

Adopt RailsAdmin when you have an existing Rails app with ActiveRecord or Mongoid models and you need an internal CRUD screen this week; the four-step install and the rails_admin block per model get you there. Do not adopt it if you need a custom-built front end or you run an ORM outside ActiveRecord and Mongoid. Before committing, run rails g rails_admin:install in a branch and check which files it wants to touch, because the README says the generator suggests changes based on your current setup rather than listing them.

## FAQ

### How do I install RailsAdmin in a Rails app?

Add gem 'rails_admin', '~> 3.0' to your Gemfile, run bundle install, then run rails g rails_admin:install and provide a namespace for the routes when asked. Starting the server afterwards serves the panel at /admin if you chose the default namespace.

### Does RailsAdmin include authentication and authorization?

No. The README lists authentication via Devise or other and authorization via CanCanCan or Pundit as features, each with its own document, so the engine itself does not create a login or a permission model.

### Which ORMs and Ruby versions does RailsAdmin support?

The README lists ActiveRecord and Mongoid as the supported ORMs, and states that the library aims to support and is tested against Ruby 2.7 through 3.4 plus JRuby.

### What changed when upgrading RailsAdmin from 2.x to 3.x?

The README says Webpack and Webpacker support were introduced, which brings additional dependency and configuration requirements, and that running rails g rails_admin:install will suggest required changes based on your app's current setup.

## Sources

- [Issues](https://github.com/railsadminteam/rails_admin/issues)
- [License: MIT](https://github.com/railsadminteam/rails_admin/blob/master/LICENSE)
- [railsadminteam/rails_admin on GitHub](https://github.com/railsadminteam/rails_admin)
- [README](https://github.com/railsadminteam/rails_admin/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/railsadminteam-rails-admin