Real World Rails: 200+ Production Codebases as a Corpus for Agent Search
200+ production open source Rails apps & engines in one repo. Search across real codebases with AI agents to research architectural patterns.
At a glance
- What is it?
- Steve Clarke's continuation of the Real World Rails collection aggregates over 200 open source Rails apps and engines as git submodules, so an AI coding agent can grep across real production code instead of a single tutorial. The trade-off is disk: roughly 10 GB shallow, about 29 GB with full history.
- Who is it for?
- Adopt it if you already run an AI coding agent over a local checkout and you want production Rails patterns (multi-tenancy, background job retries, soft deletes, PDF generation) searchable in one tree rather than scattered across GitHub. Do not adopt it if you are on a small SSD, a metered connection, or a CI runner that cannot absorb a 10 GB checkout, and do not treat it as a dependency of your own application.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Shell, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem is sample size, not documentation
Rails guides describe one canonical way to do a thing. Production codebases do it five ways, and the interesting part is usually the fifth. Before this repo, researching those variants meant opening GitHub in a browser, cloning a few candidates by hand, and grepping each one separately. The README frames the shift plainly: when the repo was created you had to "manually grep through code or use custom Ruby scripts to find patterns across apps." The audience is Rails developers and architects who want to see how multi-tenancy, background job retry logic, soft deletes, authentication, or PDF generation are actually implemented across many shipping applications rather than in a single reference implementation. It is a research corpus, not a library, and not a scaffold.
Submodules plus a shallow clone is the whole architecture
There is no application here. The repository is a shell wrapper around git submodules, and the primary language listed is Shell because the scripts are the product. Each of the 200+ apps and engines lives as a submodule pinned to a commit, which means the parent repo records exact revisions rather than tracking floating branches. That pinning is what makes cross-app comparison reproducible: two people who clone the same parent commit see the same source. The scripts are thin: bin/setup initializes and downloads submodules with a shallow clone, bin/update pulls the latest changes and advances every submodule to its latest remote commit, bin/status reports how many apps are initialized, bin/add registers a new app or engine from a GitHub URL, and bin/verify checks that each submodule repository still exists on GitHub and has not been moved or renamed. The last one requires the gh CLI. A weekly GitHub Action updates submodules and opens a pull request, so the default state of the parent branch is whatever was merged most recently, not the bleeding edge.
Disk budget and the git-lfs prerequisite
The README is unusually direct about cost. Running bin/setup clones all 200+ repositories as submodules and uses approximately 10 GB of disk space. bin/setup --full clones complete git history instead, at roughly 29 GB. bin/setup --reset re-downloads all submodules and is the documented way to switch between default and --full modes. Git LFS must be installed before any of this, and the README links to git-lfs.com rather than bundling it. That prerequisite is easy to skip and the failure is not graceful: repositories that store assets through LFS will check out with pointer files instead of real content, which quietly corrupts any agent query that reads binary-adjacent files. If your agent only ever reads .rb files this may never surface, but it is the kind of thing worth confirming once with a known LFS-using app rather than discovering mid-research.
Getting it running, and keeping it current
The documented path is a clone, a cd, and bin/setup. The README gives the clone over SSH as git clone git@github.com:steveclarke/real-world-rails.git, followed by cd real-world-rails/ and bin/setup. Routine updates do not require re-running setup: after the weekly action's pull request is merged, git pull followed by git submodule update brings the checkout in line. If you want every submodule at its latest remote commit immediately, bin/update does that without waiting for the weekly run. Adding an app is bin/add https://github.com/user/repo, which the contributing section pairs with a commit and a pull request. There is also an agent skill installed through npx skills add steveclarke/real-world-rails, which the README says teaches an agent to search across all 200+ codebases. The analyses/ directory is git-ignored, and the README positions it as a place to keep markdown notes and pattern comparisons without them appearing in pull requests.
Where this is the wrong tool
This is not a dependency and not a template. Nothing here is meant to be required from your Gemfile, and the submodules are study material pinned at whatever commits the maintainers last merged. Anyone expecting a curated, tested, versioned library of reusable concerns will be disappointed, because there are no releases: the release list is empty, and the distribution model is a git checkout. The second limitation is freshness granularity. Submodules are advanced by a weekly automated pull request, so between merges your snapshot is stale by design, and bin/update is the escape hatch that trades reproducibility for currency. Third, the corpus is Rails-specific by construction; the contribution criteria require Ruby on Rails and exclude demos and tutorials, so it will not help you research Sinatra, Hanami, or non-Ruby service patterns. Finally, a 10 GB checkout is hostile to ephemeral CI environments and to laptops with limited free space, and there is no documented partial-clone mode for pulling a subset of apps, so the unit of adoption is the whole set.
Alternatives and the actual difference in approach
The README points to sibling collections: Real World Nuxt, Real World Ruby Apps, Real World Sinatra, and Real World Django. The meaningful comparison is Real World Ruby Apps, which targets Ruby generally rather than Rails specifically. If your question is about plain Ruby idiom, gem structure, or non-Rails service objects, that collection is the closer fit, and the Rails-specific corpus will bury the answer under framework conventions. The other axis of comparison is not another repo but a different mechanism: GitHub code search or a locally cloned handful of apps. Those give you freshness without the disk cost, but they do not give you a single pinned revision set, and they do not give an agent one directory to traverse. The trade this project makes is explicit: you pay 10 GB and a git-lfs install to buy a fixed, greppable snapshot of 200+ production apps.
Maintenance cost and licence position
Ongoing effort is mostly disk and bandwidth. Weekly submodule bumps arrive as pull requests, and merging one then requires a git pull plus git submodule update locally, so the maintenance rhythm is tied to someone else's automation. bin/verify exists because upstream repositories get renamed or deleted, and it needs the gh CLI, which is a second tool to install beyond git and git-lfs. The parent repository is MIT licensed, but that licence covers the scripts and the collection, not the 200+ submodules, each of which carries its own licence and its own terms. Copying code out of any individual app into your own project is governed by that app's licence, and nothing in this repo changes that. This is a factual boundary rather than legal advice; if you plan to lift code rather than read it, check the specific submodule's licence file first.
Editorial conclusion
Adopt it if you already run an AI coding agent over a local checkout and you want production Rails patterns (multi-tenancy, background job retries, soft deletes, PDF generation) searchable in one tree rather than scattered across GitHub. Do not adopt it if you are on a small SSD, a metered connection, or a CI runner that cannot absorb a 10 GB checkout, and do not treat it as a dependency of your own application. Before committing, run bin/verify with the gh CLI to confirm the submodule remotes still resolve, and confirm you have git-lfs installed, because bin/setup will fail or produce broken checkouts without it.
Community notes