react_on_rails: a Rails view helper that defaults to a paid renderer

New apps default to Pro, and --standard is the way out

The scaffolding command is short, and the sentence right below it is the one to read twice. New apps default to React on Rails Pro for React 19.2 support, and the `--standard` flag is for readers who intentionally want an open-source-only setup. So the fastest path into this project lands on the paid tier rather than on the MIT gem, and the flag that avoids it gets a single clause rather than an entry in an options list.

npx create-react-on-rails-app my-app
cd my-app
bin/rails db:prepare
bin/dev

Those four lines are the whole install: create the app, move into it, prepare the database, start the dev server. Nothing here says what `--standard` changes in the generated files, so a team that wants the open-source path has to compare two generated apps instead of reading a difference table. Worth knowing before running it, since the default is the commercial configuration.

Adding the gem means a bundle line plus a generator run

For an application that already exists, the path is a Bundler add with `--strict`, then a Rails generator, then the same dev server command.

bundle add react_on_rails --strict
bundle exec rails generate react_on_rails:install
bin/dev

`--strict` pins the gem to one exact version instead of a range, which matters here because the project ships release candidates next to stable tags. The generator is where the integration work happens: it is the step that wires views, assets and Shakapacker together inside an app you already own. The README does not list what that generator writes into your tree; it sends readers to the documentation site for setup guides. When something looks wrong afterwards, the project ships a task named for exactly that situation.

bundle exec rake react_on_rails:doctor

One view helper is the whole entry point

Rendering is a single call in a Rails template, with the component name as a string and the props as a hash.

<%= react_component("HelloWorld", props: { name: "World" }) %>

That one helper is the shape of the library. Rails view helpers, server-side rendering, hot reloading and automatic bundle generation are what the gem wraps around it. Because the component name arrives as a string, the view hands the renderer a name to look up rather than an imported symbol, so nothing in the template fails at parse time over a component that was renamed.

What sits behind that name is where the rest of the work lives, and what sits behind server-side rendering is exactly where the project splits its money. The open-source gem does Rails-oriented SSR. Node renderer support, streaming SSR, React Server Components, fragment caching and TanStack Router SSR are the Pro additions, which is why a version comparison between the two is the page to read before committing to either.

The newest tag is a release candidate, the manifest says 17.0.0-rc.6

The documentation covers React on Rails 17, and the release list moves quickly around it: v17.2.1.rc.1 on 2026-10-29, v17.2.1.rc.2 on 2026-10-31, and v17.2.1.rc.3 on 2026-11-02, with the last push on 2026-11-02. An install without a pin can therefore land on a release candidate. The workspace manifest does not help you tell which one you have either: the root `package.json` is named `react-on-rails-workspace`, is marked private, and carries its own version field reading `17.0.0-rc.6` while the tags sit at 17.2.1 release candidates.

Older documentation stays in the same repository instead of being withdrawn. Historical docs and code for v15, v14, v13, v12 and v11 are all linked from the README, and one of them carries a retraction: the README points at an upgrade guide and tells you to read it before relying on anything written for v15. A developer who finds an older example knows now that the maintainers flagged that generation themselves.

One monorepo holds the gem, the Pro package and the Node renderer

The root manifest lists nine workspaces: `packages/react-on-rails`, `packages/react-on-rails-pro`, `packages/react-on-rails-pro-node-renderer`, `packages/create-react-on-rails-app`, the gem's `spec/dummy`, and four that are `react_on_rails_pro` itself or sit under it. The open-source gem and the commercial packages share one tree, so the paid ones are identified by their names and by a separate license document rather than by living somewhere else.

This is also where the questions people ask about the project get answered or not. The claim is that you keep a single Rails app instead of splitting into a separate frontend and API, and you render React inside Rails views. The answer to what it is runs into the toolchain: Shakapacker, a JavaScript package manager, and a Node runtime all have to be present before any of that rendering happens, which is the subject of the next section.

Requirements pin Ruby and Node, and autobundling tightens Shakapacker

The floors are Ruby on Rails 5.2, Shakapacker 6.0, Ruby 3.3 and Node.js 18, plus a JavaScript package manager such as pnpm, npm, yarn or bun. The tested ranges are narrower than the floors: Ruby is exercised on 3.3 through 4.0, and Shakapacker from 8.2.0 to 10.3.2. Autobundling is called out separately and needs Shakapacker 7.0 or newer, so a project that satisfies the stated 6.0 minimum still cannot turn on automatic bundle generation.

That distance between a stated minimum and a feature requirement is the one that catches people out. Someone reading the requirements list sees 6.0 and stops. Shakapacker is also where Rspack support comes in.

Pro is free in development and metered by headcount in production

The commercial split is stated in numbers. Pro is free in development, test, CI and staging for everyone. In production it is free for organizations under 10 people, under $1M revenue and under $1M raised, and free at any size for charities, schools and hospitals. Larger organizations subscribe at $1,800 per year, covering the whole organization.

What is enforced is thin by design. No license key is needed to run it; a key from a subscription only marks pages `Licensed`. Production use above those thresholds is a matter of whether an organization tells ShakaCode, not whether the code refuses to start. The open-source gem is MIT, per `LICENSE.md`, while the repository's own license field reads `NOASSERTION`, so automation that reads license metadata from the repository receives nothing and has to be told which document applies.

The root holds agent instructions and bundle size checks

A large share of the top-level tree is tooling for machines rather than for readers. Alongside the code sit `.agents/`, `.claude/`, `.cursor/`, `.conductor/`, `AGENTS.md`, `CLAUDE.md`, `PROMPTS.md`, `WARP.md`, `CONTEXT-MAP.md`, `AGENTS_USER_GUIDE.md`, and three generated text bundles named `llms.txt`, `llms-full.txt` and `llms-full-pro.txt`. The help section points AI coding assistants at `AGENTS_USER_GUIDE.md`, so this is deliberate, and one of those generated files is the Pro text, which puts the commercial documentation in machine-readable form inside the same tree.

The remainder of the root is lint and test configuration: `.rubocop.yml`, `.stylelintrc.json`, `eslint.config.ts`, a local `eslint-rules/` directory, `jest.config.base.js`, `.lefthook.yml`, `knip.ts` for dependency checks, and `.size-limit.json` backed by the `@size-limit/file`, `@size-limit/time` and `@size-limit/webpack` packages. Bundles are measured here, not only built.

Editorial conclusion

The open-source gem is a reasonable choice for a Rails application that wants React components rendered from views without standing up a second service, provided you accept its floor: Ruby 3.3, Node 18, Shakapacker, and 7.0 if you want automatic bundling. Pin your version, because the newest tag is a release candidate and the workspace manifest still reads 17.0.0-rc.6. Before you ship, settle the Pro question yourself: production use past the stated headcount and revenue thresholds needs a subscription, and no key is required for the code to run. Check the v15 retraction notice before reusing older examples, and confirm the license metadata your tooling reads, since the repository reports no license identifier while the gem itself is MIT.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. shakacode/react_on_rails on GitHub