Your Rails admin, in your codebase.
Not on a platform.

01 · credit where it's due

What Forest Admin gets right

Forest Admin is a serious product, and it solves a real problem well. If you are weighing it against Avo, start from what it does genuinely better than most hosted admin tools.

02 · the structural difference

The data path stays yours. The admin does not.

Here is the distinction worth being precise about. With Forest, your data path stays on your infrastructure, but the admin that reads it is a product hosted on Forest's platform. Your app exposes data through the agent gem; the interface, the layout, the fields, the segments, the dashboards, is configured in Forest's web editor and stored on their side. When someone on your team opens the admin, it fetches its UI configuration from Forest and your records from your app.

With Avo there is no other side. The admin is a Rails engine in your Gemfile, and every resource is a Ruby class in your repository. Nothing about it lives on a server you do not control. That single difference is what this whole page is about, and it is the same argument the homepage makes about the two apps every product ships: the internal tool should be part of your codebase, not a second system you rent and report to.

04 · where Avo comes in

With Avo, the admin is part of the app

Avo is a Rails engine you add to your Gemfile. Your resources, fields, actions, and permissions are Ruby classes that live in app/avo, right next to the rest of your code. That one fact changes how the whole admin behaves.

A resource is just a class. This one gives you a full CRUD screen for your users, filtered, searchable, and ready to extend:

# app/avo/resources/user.rb
class Avo::Resources::User < Avo::BaseResource
  self.title = :name

  def fields
    field :id, as: :id
    field :name, as: :text
    field :email, as: :text
    field :plan, as: :select, options: { free: "Free", pro: "Pro" }
    field :created_at, as: :datetime, sortable: true
  end
end

That file is reviewed in a pull request and deployed with your app. Building your admin in your resource Index view and its fields is the whole configuration, in code you already know how to read. Already running a hosted admin? Here is how teams move their admin back into their codebase.

05 · side by side

Avo and Forest Admin, in one view

Same job, two different places for the admin to live. Here is where they diverge.

If a hosted admin is what you are set on, it is worth reading the Retool comparison too, and the full list of Avo alternatives.

06 · when to pick Forest instead

When Forest Admin is the better fit

Avo is not the right answer for everyone, and pretending otherwise would waste your time. Reach for Forest Admin when:

But if you are a Rails team that wants the admin to be code you own, review, and ship like the rest of your app, that is exactly what Avo is for.