Start here
Rails UI is a product acceleration system, not just a component library. Think in three layers:
- Components are the building blocks: forms, navigation, dialogs, tables, and more, in clean ERB wired to Stimulus and Hotwire.
- App kits are complete product surfaces for a kind of SaaS: real dashboards, auth, settings, billing, and email, designed as one coherent system.
- Patterns and layouts connect them, so screen twenty matches screen one.
You do not build from a blank page. You install a kit close to your product, keep the screens that fit, and customize the rest. Everything is your code (plain ERB and Tailwind in your repo), so you and your AI assistant can read, reuse, and extend it. The rest of this page gets you from install to a polished, shippable screen fast.
The open gem includes the free app kits and base components. Full Access unlocks the private Rails UI repository with the complete kit catalog and subscriber updates. Rails UI Charts and Charts Pro are separate gems for dashboards and metrics. Chapter work will go deeper still: designer-built product modules with the states, copy, responsive behavior, and implementation notes a one-shot component rarely carries.
The first 30 minutes
- 0 to 5 min, install. Follow the Quick Start to add the gem, run the installer, and boot your app.
- 5 to 10 min, pick an app kit. Open the App kits and choose the one closest to what you are building, not the prettiest. Install it.
- 10 to 20 min, ship one real screen. Drop in a dashboard or settings screen from the kit, and convert one existing form to the Rails UI form builder. Load it in the browser.
- 20 to 30 min, make it yours. Set your brand colors in the config, restyle the screen, and wire one Stimulus interaction. Commit.
Outcome: a real, on-brand, coherent screen running in your app in half an hour, not a pile of snippets.
How to choose an app kit
- Start from the use case, not the look. CRM or projects to Hound. AI app to Corgie. Finance to Husky. Property to Shepherd. Agency or client portal to Boxer. Community or courses to Collie. PaaS or servers to Retriever. Hiring or ATS to Setter.
- It is a starting point, not a lock-in. Keep the screens that fit, delete the rest, restyle anything.
- Kits share one system. The same components and design language run across all of them, so you can borrow a screen from another kit and it still fits.
- Do not overthink it. Pick the closest match and start. You can change everything later, and the free kits let you try the workflow first.
How to customize Rails UI for your app
- Brand once, inherit everywhere. Set your colors, fonts, and radius in your Tailwind config and the Rails UI config. Components and screens pick it up.
- It is your code. Installed views live in your app (for example under
app/views/rui) as plain ERB and Tailwind. Edit them directly.
- Use the form builder. Swap to
Railsui::FormBuilder so every form inherits consistent styling and states. See Forms for the details.
- Compose, do not reinvent. Build new screens from existing components and patterns so the product stays consistent.
- Stay upgrade-friendly. For views you heavily rewrite, copy them into your own view folders so future updates do not overwrite your work.
How to use Rails UI with AI tools
- It is AI-readable by design. Plain ERB and Tailwind in your repo is exactly what Cursor, Claude, and ChatGPT read best.
- Give it context. Point your assistant at the Rails UI files in your project, or at llms.txt, so suggestions match your existing UI.
- Ask in the style of what exists. Request new screens in the style of a specific Rails UI view and the result stays consistent.
- Divide the work. AI writes the logic, Rails UI provides the product layer it would otherwise skip.
- Review for consistency. Check generated views against the kit: same components, spacing, and states.
Prompts to try
Copy these into your assistant once a kit is installed.
Add a settings page to this Rails app using the existing Rails UI components and Railsui::FormBuilder. Match the layout and spacing of an existing Rails UI screen.
Build empty, loading, and error states for this index view using the Rails UI card and button components already in this project.
Create a billing page in the style of the Rails UI dashboard, reusing existing partials and Tailwind classes.
Refactor this hand-written form to use Railsui::FormBuilder so it matches the rest of the app.
Generate a Stimulus controller for this Rails UI modal partial and wire it up with Turbo.
Add a sidebar nav item that matches the existing Rails UI navigation partial exactly, including active and hover states.
Turn this static table into a Rails UI data table using the same markup and classes, paginated with Turbo Frames.
Create a confirmation dialog with the Rails UI dialog component and trigger it from this delete button.
Build a three-step onboarding flow reusing Rails UI form and card components, consistent with the installed kit.
Audit this view and rewrite it with the Rails UI components and Tailwind classes already in the project, fixing inconsistent spacing and missing states.
Launch checklist
Run through this before you ship a polished Rails SaaS.
-
Auth screens styled (sign in, sign up, password reset, confirmation)
-
First-run onboarding and empty states
-
Core dashboard and primary CRUD screens consistent
-
Account, settings, team, and billing screens
-
Transactional email templates styled
-
Empty, loading, error, and permission states everywhere
-
Responsive on mobile
-
Dark mode consistent (if used)
-
Brand colors and fonts applied via config
-
All forms use Railsui::FormBuilder
-
Navigation, breadcrumbs, and active states consistent
-
404 and 500 pages styled
-
Flash messages and toasts wired
-
Accessibility basics (labels, focus states, contrast)
-
Production assets built
Next steps
