Rails admin panel
The Rails admin panel you don't have to build
Your team runs the business from screens inside your Rails app, built with Avo on the models you already have. Your agents add resources in plain Ruby, you review a short diff, and no app starts from a blank page.
14 days free, no card needed to start. Community is free forever.
extend_trial
refund_order
merge_duplicates
export_invoices
suspend_account
None of this reached an engineer, and every row names who did it. That is the difference between an admin panel your team reads and one they work from.
986
apps ran Avo in production in the last 90 days
796
releases of Avo core, averaging one release every 0.9 days
v4.3.13
shipped about 5 hours ago
what you get
Two weeks of the real thing, in your own app
The trial is not a sandbox with sample data. You install the gem in the Rails app you already have, pick the add-ons you want to evaluate, and put your team on a working admin for fourteen days.
Every add-on you select is unlocked for the full 14 days, so you are judging the version of Avo you would actually pay for.
It runs in your app, on your servers, against your real schema. There is no demo environment whose results you have to translate.
Priced per app with unlimited users, so putting support, finance, and ops on it during the trial costs nothing extra.
Nothing is stranded if you stop. Avo core is open source, so the resource files you wrote keep working on the free Community tier and only the add-on features switch off.
Cancel from your account at any point before day 14 and you are not charged.
The trial takes a card at checkout and becomes a paid subscription when the fourteen days are up unless you cancel. If you would rather not put a card down at all, the Community tier is free forever and asks for no payment details.
14 days free, no card needed to start. Community is free forever.
what it does
Your models are already the hard part. Build the rest on Avo.
Point Avo at the models you already have and it renders the screens on top of them. One resource file declares the fields, and Avo handles the Index, Show, and form views, the associations, the validations, and who is allowed to see what. It is a Rails engine mounted in your app, so your models, your policies, and your deploy stay exactly where they are.
Every model becomes a working screen
One resource file turns a model into a full CRUD interface with Index, Show, and form views. Over 30 field types cover everything from a boolean to a money column to a rich text body, and every Rails association type is handled, so your polymorphic join is not the exception that breaks it. See the resources docs.
Your team acts on data, not just reads it
Actions turn "can you run this script for me" into a button the right people can press, on one record or a filtered selection. The real work stays in Ruby you can test, so the admin becomes the place things happen instead of a read-only window on the database. See the actions docs.
The right access for each person
Avo sits behind the authentication you already use, and Pundit-style policies decide who reaches which resource, which field, and which action. Support sees the account without the card details, finance sees the invoices, and the destroy button is a permission rather than a matter of trust. See the authorization docs.
Answers without opening a console
Search every resource from one Cmd+K box with the Rails search gem, filters that narrow a list to the records in question, and dashboards with metric and chart cards. The questions that used to arrive as a Slack message at 5pm get answered by the person asking them.
Your data never leaves your servers
Avo is a gem in your Gemfile, not a service sitting between your team and your database. Nothing is proxied, nothing is mirrored, the admin deploys when your app deploys, and it keeps working on a network with no route to the outside world.
The edges are plain Rails
When you need something Avo does not do, you write a custom tool, eject the view, or drop in a Stimulus controller. You are extending a Rails app you own, not filing a feature request and waiting on someone else's roadmap. See the custom tools docs.
An Account resource with the fields and the verb support keeps asking for, the whole file:
class Avo::Resources::Account < Avo::BaseResource
self.title = :name
self.includes = [:owner]
self.search = {
query: -> { query.ransack(name_cont: params[:q], m: "or").result(distinct: false) }
}
def fields
field :id, as: :id
field :name, as: :text, required: true
field :status, as: :badge, enum: ::Account.statuses
field :plan, as: :select, enum: ::Account.plans
field :mrr, as: :money
field :trial_ends_at, as: :date_time
field :owner, as: :belongs_to
field :users, as: :has_many
field :internal_notes, as: :textarea, hide_on: :index
end
def actions
action Avo::Actions::ExtendTrial
end
end
14 days free, no card needed to start. Community is free forever.
on rails 8
Run your Rails 8 admin on the defaults Rails 8 ships
A new Rails 8 app starts on Propshaft for assets, importmap instead of a Node build, and a built-in authentication generator. Your admin should run on those defaults, not bring the old stack back in with it.
No second asset pipeline
Avo's CSS and JavaScript ship prebuilt inside the gem, and Propshaft serves them the way it serves the rest of your app. There is no Sass compiler, no Node step, and no Sprockets to keep around for the admin. Apps still on Sprockets work too.
Sign-in from the Rails 8 generator
If your app uses bin/rails generate authentication, point config.current_user_method at it and Avo sits behind the same login. The authentication guide has the few lines it takes. Avo adds no user model and no Devise.
Hotwire, not jQuery
Avo is built on Turbo, Stimulus, and Tailwind, the tools a new Rails 8 app starts with. A custom field or a Stimulus controller you add to the admin is written the way you write the rest of the app.
What changes for ActiveAdmin on Rails 8
-
01
The stable line runs
ActiveAdmin 3.4 added Rails 8.1 support, and 3.5.2 (July 2026) is current. If your admin already works, the Rails upgrade alone won't break it.
-
02
Its assets are the catch
The install generates an SCSS stylesheet for the asset pipeline and depends on jquery-rails. Propshaft can't compile Sass, so a Rails 8 app keeps Sprockets and a Sass compiler around for the admin, or wires ActiveAdmin's npm package into Vite by hand.
-
03
Version 4 fixes that, and is still in beta
It moves to Tailwind, importmap, and cssbundling, and has shipped betas since January 2024 (beta23 landed in September 2026). Its upgrade guide adds an npm package and a Tailwind build step, and drops sortable has-many forms.
-
04
Sign-in defaults to Devise
The default install adds Devise and an AdminUser model. On an app built with the Rails 8 generator, you skip that with
--skip-usersand wire up your own.
If ActiveAdmin 3 is working and the extra pipeline doesn't bother you, stay put. If you're starting a Rails 8 app, or the extra pipeline is what you want gone, read the ActiveAdmin alternative page, or move one resource at a time with both admins mounted side by side.
14 days free, no card needed to start. Community is free forever.
how long it takes
Working admin this afternoon, team on it by Friday
Add the gem, run bin/rails generate avo:install, and mount Avo behind the authentication you already have. Generate a resource for your busiest model and you are looking at real production data in a real interface.
Generate the rest of the resources. Set each title to the attribute people recognize, preload associations through self.includes so Index views stay quick, and match the field types to the columns. The shape of the admin is done.
Write the policies that decide who sees what, then turn the two or three scripts your team keeps asking you to run into actions with a button. Ship it and let support work from production.
Support and finance work from Avo instead of your inbox. The console one-liners are gone, and the admin is a handful of resource files in your repo that any Rails developer on the team can extend.
Prefer to prompt?
Hand this to Claude Code, Cursor, or whatever agent you build with, and review what it ships like any other pull request.
Build an admin panel for an existing Ruby on Rails application using Avo 4 (https://avohq.io, docs at https://docs.avohq.io/4.0/). The app and its schema already exist, so read the code before you write any.
1. Start by reading db/schema.rb and app/models. List every model, its columns, its associations, and its enums. Identify the handful of records the team actually works with day to day (usually the user or account, the thing they buy, and the record that goes wrong) and treat those as the priority. Do not generate a resource for every join table and every internal bookkeeping model; a good admin surfaces what people act on.
2. Add the avo gem, bundle, run bin/rails generate avo:install, and mount Avo behind the app's existing authentication rather than inventing a new login. Set config.current_user_method in config/initializers/avo.rb so Avo knows who is signed in, and confirm an anonymous request cannot reach the mount point.
3. Generate a resource per priority model with bin/rails generate avo:resource and then make each one concrete. Set self.title to the attribute a human recognizes, give self.search a ransack query across the fields people are looked up by such as name, email, or reference number, and set self.includes to preload the associations the Index and Show views render so the list does not fire a query per row. Match field types to the columns deliberately: badge for a status enum, select for an editable enum, money for currency columns, file for Active Storage attachments, belongs_to and has_many for associations, and hide_on: :index for the long text nobody reads in a list. See https://docs.avohq.io/4.0/resources.html.
4. Find the verbs. Grep the repo for rake tasks, scripts, and console snippets the team runs by hand, and turn each into an Avo Action. Put the real behavior in a model method or a small service object and have the action call it, so the logic is testable Ruby rather than admin-only code. Typical examples: extend a trial, resend a receipt, retry a failed charge, merge duplicate records, suspend an account.
5. Add the ways people find things: filters over the columns support narrows by, scopes over the model scopes that already exist, and a dashboard with metric cards for the numbers someone currently checks in the console (https://docs.avohq.io/4.0/dashboards.html).
6. Authorize with Pundit policies that reflect the real roles in the company rather than a single admin boolean. Support can look up and act on accounts but cannot see payment details, finance sees the money and can refund, engineering can run the backfills, and destructive actions are gated to the people who should have them (https://docs.avohq.io/4.0/authorization.html).
7. Write a request spec for each policy boundary, asserting that a user without the role gets denied rather than merely not seeing a button. Hiding a control in the UI is not authorization.
14 days free, no card needed to start. Community is free forever.
or start from scratch
What building an admin panel from scratch actually costs
The admin panel is the part of the app nobody scopes and everybody needs. It starts as a few generated screens for the team, then support asks for a filter, finance asks for an export, and a year later it is a second app you are still steering and re-reviewing.
-
01
You are shipping two apps, not one
Every product is secretly two apps: the one customers see, and the internal tool where your team manages users, plans, prices, and content. Generate the second one from scratch and your tokens, your time, and your review split across two apps instead of one.
-
02
The first version is the cheap part
Scaffolding CRUD screens takes an afternoon, and an agent can do it faster than that. What costs you is everything after: the edge cases, the error states, the large tables that time out, and the prompting, steering, and re-reviewing you spend on screens no customer will ever see, again in the next app.
-
03
It holds the keys to everything
Your admin can read every customer record and change any of them, so its access-control layer is the code you can least afford to get subtly wrong. Generated fresh for each app, it's also the code you have to review hardest, every time.
-
04
Nobody wins their market on admin quality
No company ever beat a competitor because the internal tooling was nicer. The work is real and it never stops, but it is overhead however well you do it, so the sensible move is to build as little of it from scratch as you can.
14 days free, no card needed to start. Community is free forever.
start today
Stand up an admin panel this week
Install it in the app you already have, point it at your models, and see a working admin before the afternoon is out. If it is not a fit, cancel before day 14 and keep the resource files you wrote.
14 days free, no card needed to start. Community is free forever.
More things teams run from their Rails app
Avo by industry
Avo for your team
Frequently asked questions
- What is the best admin panel for Ruby on Rails?
- It depends on how far the admin has to go. Administrate is a reasonable fit for a small app that needs plain CRUD and nothing more. ActiveAdmin and Rails Admin both have large installed bases and both carry a decade of legacy, and Rails Admin has been quiet since its 3.3.0 release in December 2024. Avo is built for admins that keep growing: CRUD, actions, filters, dashboards, and fine-grained permissions in one framework, configured in plain Ruby, with the heavier capabilities available as add-ons when you need them. See Avo alternatives for the comparison in detail.
- Should I build my own Rails admin panel or use a gem?
- Your agent can build one, and the first version is not the hard part. What costs you is the year after: the filter support asks for, the export finance needs, the permission model that stops a new hire deleting an account, and the security review nobody scheduled, each one prompted, steered, and re-reviewed. Start from scratch when the admin genuinely is the product. Build on Avo when it is the thing standing between you and the product.
- Do I need a credit card to try Avo?
- For the 14-day trial, yes. Checkout takes a card and the trial becomes a paid subscription when the fourteen days are up unless you cancel first, so we say so plainly rather than burying it. If you would rather not put a card down, the free Community tier needs no payment details at all and does not expire. See pricing.
- What happens when the Avo trial ends?
- On day 15 the add-ons you selected convert to a paid monthly subscription for that app. Cancel from your account any time before then and you are not charged. Either way the resource files you wrote stay in your repo: Avo core is open source, so your admin keeps working on the free Community tier and only the paid add-on features switch off.
- How long does it take to install Avo in an existing Rails app?
- Minutes to a first working screen. You add the gem, run bin/rails generate avo:install, mount it behind the authentication you already have, and generate a resource for one model. Most teams have the shape of the whole admin done inside a day, because the schema work is already finished. Nothing in your database changes.
- Can I try Avo on my existing production app?
- That is the intended way to trial it. Avo reads the models and schema you already have rather than asking you to adopt new ones, it runs behind your existing authentication, and out of the box it adds no tables and modifies nothing. You are evaluating it against your real data and your real edge cases from the first hour.
- Is Avo a good Rails Admin or ActiveAdmin alternative?
- Yes, and it is the most common reason people arrive here. Rails Admin still depends on Sprockets, which is friction on a Rails 8 app that defaults to Propshaft, and its extras come from community plugins that are largely unmaintained. ActiveAdmin works well early and gets harder as the admin grows, when you start working around the library rather than with it. Avo is configured in plain Ruby, extended with ordinary Rails code, and its capabilities are first-party add-ons we maintain. See the Rails Admin comparison and the ActiveAdmin alternative page.
- Does Avo support authorization and Pundit?
- Yes, through the Authorization add-on. You write plain Pundit policies in app/policies and set config.authorization_client = :pundit, and Avo calls them to decide who reaches each resource, button, action, association panel, and file field. A false return hides the control and blocks the underlying request, so it is real authorization rather than a hidden button. You can plug in another client such as action_policy if that is what your app already uses. The add-on is priced per app and available on any plan rather than reserved for an enterprise contract. See the authorization docs.
- Does Avo work with multi-tenant Rails apps?
- Yes, and multi-tenancy is part of the free Community tier rather than an upgrade. Because Avo runs inside your app, it uses the same scoping your app already applies, so a tenant's admin sees only that tenant's records. See the multitenancy docs.
- Does Avo work with Rails 8?
- Yes. Avo 4 targets current Rails, works with Propshaft as well as Sprockets, and is built on Hotwire and Tailwind rather than jQuery. Upgrades arrive through your Gemfile and improve the foundation underneath the resources you wrote, with nothing in your repo to merge or reconcile.
- How do I add an admin panel to a Rails 8 app?
-
Add the avo gem, run
bin/rails generate avo:install, and mount Avo behind the sign-in you already have. If you used the Rails 8 authentication generator, the authentication guide shows how to tell Avo who the current user is. Then runbin/rails generate avo:resourcefor each model your team works with. Avo's assets come prebuilt in the gem, so Propshaft serves them with no Node or Sass step. - Should I start a new Rails 8 app on ActiveAdmin or Avo?
- For a new app, we'd pick Avo, mostly because of the stack. ActiveAdmin 3.5 runs on Rails 8, but next to Propshaft it needs Sprockets and a Sass compiler, or a Vite setup you wire by hand, plus jQuery. ActiveAdmin 4 drops those and has been in beta since January 2024. Avo runs on the defaults a new Rails 8 app already has. If ActiveAdmin already works for you, there's no rush; the ActiveAdmin alternative page covers when switching pays off.
- Does Avo add tables to my database?
- No. Out of the box Avo reads your existing schema and adds nothing to it. A few add-ons that have to store their own records, such as audit logging, come with migrations, and those are opt-in. If you never install them, your schema is untouched.
- Does my data leave my servers?
- No. Avo is a gem that runs inside your Rails app, on your infrastructure, behind your authentication. There is no third-party service in the path between your team and your database, which is the practical difference between Avo and a hosted admin tool like Retool or Forest Admin. See the Retool comparison.
- Can AI agents like Claude or Cursor work in my Rails admin?
- Yes, with the Rails MCP server add-on. Claude, Cursor or ChatGPT connect to your Avo app over the Model Context Protocol to search and update records and run your actions. An admin approves each client first, and every call goes through the same policies your team works under.
- Is there a free version of Avo?
- Yes. The Community tier is free, open source, and covers the basics: resources, fields, every association type, actions, basic filters, custom tools, theming, multi-tenancy, and i18n. The deeper capabilities are add-ons you buy per app, individually or as a bundle: authorization, dashboards, global search, scopes, dynamic filters, kanban boards, audit logging, and more. See pricing.
- Can I customize Avo when it does not do what I need?
- Yes, and this is the part people underestimate. You can eject any view and edit the ERB, write a custom field, add a custom tool with its own controller action, or attach a Stimulus controller. Because it is a Rails engine in your app, the escape hatch is always the same one: write ordinary Rails code.
- Is Avo a CMS?
- Not by itself, but it is a good foundation for one. If you need editors publishing content, see building a CMS on Rails, which covers rich text, media, and publish state on your own models.