# RailsPanel: a Chrome DevTools panel that replaces tailing development.log

> RailsPanel pairs a Chrome extension with the meta_request gem to show per-request timings, parameters and rendered views inside DevTools. It is a localhost-only debugging aid, and the extension and the gem ship from the same repository.

**dejan/rails_panel** — Chrome extension for Rails development

- Repository: https://github.com/dejan/rails_panel
- Website: https://chromewebstore.google.com/detail/railspanel/gjpfobpafnhjhbajcjgccbbdofdckggg
- Stars: 3,868 · Forks: 188
- Language: JavaScript
- License: MIT
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/dejan-rails-panel

## What RailsPanel replaces, and who it is for

The README states the goal plainly: RailsPanel is a Chrome extension for Rails development that will "end your tailing of development.log". Instead of a scrolling log, request data appears in the Chrome Developer Tools panel, covering db, rendering and total times, the parameter list and rendered views.

The audience is narrow on purpose. It is a local development tool for Rails developers who already keep a browser open next to their editor. The README lists Rails 5, 6, 7 and 8, and Ruby 3 and 4, as supported environments. Nothing in the README describes a team dashboard, a hosted service or a CI integration, so treat it as a personal debugging aid rather than shared infrastructure.

The repository is not archived, and the last push was on 2026-05-27, the same day as the meta_request-v0.8.6 release. That release followed meta_request-v0.8.5 in November 2024, so the cadence between those two tags was roughly eighteen months. The project is maintained, but not on a fast schedule, and the version numbering suggests the gem is the part that moves.

## How the meta_request gem and the extension talk to each other

There are two halves, and both must be present. The gem lives inside the Rails app under the meta_request directory of the repository. The extension lives under the extension directory and runs in Chrome. The README does not spell out the wire protocol, but the repository layout makes the split clear: one side is Ruby code loaded into the app, the other is JavaScript packaged for the browser.

That split has a practical consequence. The gem is what observes request processing, and the extension is what renders it. If the gem is missing from the Gemfile, the panel has nothing to display, and the README's installation section treats the Gemfile entry as the first step rather than an optional one.

The constraint that shapes daily use is the localhost restriction. The README says the extension works only for localhost requests, on any port. A request to a staging host or to a container reachable by a hostname other than localhost will not appear in the panel. If your development setup proxies through a custom domain, the extension is the wrong instrument until that traffic reaches localhost.

## Installing the gem and loading the extension

Installation starts in the application, not in the browser. The README gives a Gemfile entry scoped to the development group, which keeps the gem out of production bundles:

```ruby
group :development do
  gem 'meta_request'
end
```

After editing the Gemfile, run bundle install as usual, then restart the Rails server so the gem is loaded. The README does not document a generator, an initializer or any configuration key, so there is nothing else to add on the Ruby side.

The second half is the browser extension. The recommended route is the Chrome Web Store listing, which the README prefers because the extension "will auto-update on every new version". The repository's own homepage field points at that same listing.

If the store install fails, or you want to run the latest code and modify it, the README describes the unpacked path. Clone the repository, then load the extension folder through Chrome's Developer mode:

```bash
git clone https://github.com/dejan/rails_panel ~/workspace/rails_panel
```

In the Chrome Extensions page, enable Developer mode, choose "Load Unpacked extension..." and select ~/workspace/rails_panel/extension. The README does not document what the panel shows before the first request arrives, so open DevTools on a localhost page and make a request to confirm the panel populates.

## Where RailsPanel stops being useful

The localhost-only rule is the largest limitation and it is stated without qualification. Any debugging session against a remote environment is out of scope. That rules out the common case of reproducing a bug that only appears on a staging server behind a real hostname.

The second limitation is the supported-environment list. Rails 5 through 8 and Ruby 3 and 4 are named. An application on an older Rails line, or on a Ruby version outside that range, is not covered by the README, and there is no compatibility table beyond that line.

The third is release cadence. Between meta_request-v0.8.5 in November 2024 and meta_request-v0.8.6 in May 2026 there was a long gap, so a new Rails release may sit unsupported for a while before the gem catches up. Anyone tracking a Rails release candidate should check the repository rather than assume the panel already understands the new request pipeline.

Finally, the README documents no rollback or removal procedure. Uninstalling the extension from Chrome and deleting the Gemfile line is the obvious reverse of the install steps, but the README itself is silent on it.

## RailsPanel against reading the log or a profiling gem

The realistic alternative is the workflow RailsPanel is designed to replace: tailing development.log and reading the timing lines the framework already prints. That approach has no install step, works on any host you have log access to, and survives Rails upgrades because it depends on the framework rather than on a gem and a browser extension staying in sync. Its cost is that the data is a stream, not a per-request view, and correlating parameters with rendered views means scrolling.

A second alternative is a profiling gem that instruments the application in depth, for example one that produces flame graphs for a single action. Those tools answer a different question. They are aimed at finding where time goes inside a method call, while RailsPanel's stated scope is db, rendering and total times, parameters and rendered views for a request. If your problem is a slow query inside a controller, a profiler is the better fit; if your problem is not knowing which request did what, the panel is cheaper.

The difference in approach matters most for setup. A log tail needs nothing. A profiler usually needs a gem plus a route or a middleware that you enable deliberately. RailsPanel needs a gem in the development group plus a Chrome extension, and in exchange it gives a persistent panel that stays open across requests.

## Maintenance cost, licence and what to check before adopting

The upgrade surface is small. The gem is pinned by your Gemfile, so a bundle update controls when you move between meta_request versions. The extension updates itself when installed from the Chrome Web Store, which the README presents as the reason to prefer that route. If you load the unpacked version instead, you own the updates and must pull the repository yourself. The two halves can therefore drift: a newer extension against an older gem, or the reverse.

The licence is MIT, Copyright (c) 2012 Dejan Simic. The README includes the full permission text, which allows use, modification, distribution and sublicensing provided the copyright notice and permission notice are included. That is permissive and imposes no copyleft obligation on your application. It is not legal advice; if you redistribute the extension inside a commercial product, read the notice text yourself.

One practical check before adopting: confirm the gem version your Gemfile resolves matches a tag in the repository, since the release list shows meta_request-v0.8.6 as the most recent at the time of writing.

## Conclusion

Adopt RailsPanel if you develop Rails 5 through 8 on Ruby 3 or 4 and want request-level timings without watching a log file. Skip it if you need to profile a staging or production host, since the extension only handles localhost requests on any port. Before relying on it, confirm that the meta_request gem is present in the development group of your Gemfile and that the unpacked extension loads from the extension directory of a clone.

## FAQ

### Does the RailsPanel Chrome extension need the meta_request gem?

Yes. The README's installation section adds meta_request to the development group of the Gemfile before installing the extension, so the gem is a required half of the setup rather than an optional add-on.

### Which Rails and Ruby versions does RailsPanel support?

The README lists Rails 5, 6, 7 and 8, and Ruby 3 and 4, as the supported environments.

### Can I use the RailsPanel extension on a remote or staging server?

No. The README states the extension works only for localhost requests, on any port, so requests to a staging host or a custom domain are outside its scope.

## Sources

- [dejan/rails_panel on GitHub](https://github.com/dejan/rails_panel)
- [License: MIT](https://github.com/dejan/rails_panel/blob/master/LICENSE)
- [Project website](https://chromewebstore.google.com/detail/railspanel/gjpfobpafnhjhbajcjgccbbdofdckggg)
- [README](https://github.com/dejan/rails_panel/blob/master/README.md)
- [Releases](https://github.com/dejan/rails_panel/releases)

---

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