Roundhouse analyzes Rails source without booting the app
Roundhouse reads routes, models, controllers, templates, schema, and framework conventions without booting the application or touching its database. From that source it infers types, nil risks, request traces, unsupported gems, and possible N+1 queries. The result appears through roundhouse check, an LSP server, a browser IDE, or an MCP server. For a Rails team, this is the least disruptive part of the project because it produces a report instead of a replacement application.
The binary accepts 13 target names across server runtimes, Ruby variants, and Spinel. Static findings can help even when coverage is incomplete. Generated services take ownership of HTTP behavior, persistence, sessions, templates, and security, so every unsupported construct becomes a migration decision rather than a diagnostic you can postpone.
What happened when we ran it
Our sandbox installed commit 497ff91 in 18 seconds and pulled 62 packages. The build succeeded in 152 seconds. Our lab measured those steps in an unprivileged Debian container with 3 CPUs, 12 GB of RAM, Rust, and no secrets. The checkout held 1,520 files, about 401,364 lines of source, and occupied 19.8 MB. We also found 2 CI workflow files, a tests directory, and no Dockerfile.
Cargo test failed with exit 101 after 254 seconds. Across the supplied run, 1,644 tests passed and 82 failed out of 1,726. The log tail repeated a library result of 822 passed and 41 failed, then suggested rerunning with --lib. Named failures covered MCP traces and type resolution, stale seed replacement, application seed generation, and a web-push stub. The tail does not show why those assertions failed, so assigning one common cause would be guesswork.
The 1,644 passes show substantial coverage, but 82 failures block a clean release claim. Roundhouse's README says the default suite must pass before any commit. Other ignored checks exercise generated toolchains and frameworks, while our measurement covers the cargo test result in the supplied sandbox. We did not verify emitted applications against live Rails or measure their request speed.
Unknown constructs stop all 13 transpile targets by default
Roundhouse uses strict ingestion before any of its 13 target names. An unrecognized construct stops transpilation, while --survey records gaps and --allow-unsupported emits marked stubs. The guide calls that combined output a survey rather than something deployable. A missing controller filter or route hidden by a successful command would be much worse than a refusal to emit.
Generated projects bring their own toolchains. Rust needs Rust 1.85 or later and SQLite, Go needs Go 1.24 or later, Swift needs Swift 6 or later, and the other targets have similar floors. Every emitted tree also carries seed SQL and target-specific tests. Generate into a clean directory because the command overwrites matching files but does not remove files left by an older run.
The source app also decides whether conversion is realistic. Roundhouse cannot lower method names built at runtime, eval, method_missing, computed requires, some framework monkey patches, or behavior supplied only through an unknown gem DSL. Its survey names these gaps and their locations. On a dynamic Rails codebase, that inventory may be the project's most useful output even if none of the 13 emitters is ready to ship it.
All targets cover Rails 8 blog features, Campfire is Ruby and Spinel only
The coverage guide defines two levels. Every server target is checked against a Rails 8 blog fixture with standard models, nested routes, validations, Turbo Streams, Action Cable, Tailwind, and JSON endpoints. The larger Campfire application proves more Rails behavior only for the emitted Ruby shape and Spinel. Features such as richer Active Record relations, attachments, full text, sessions, and more controller behavior do not automatically inherit the blog's all-target promise.
The first snapshot reports the gap honestly. Its Mastodon analysis found 674 errors, 138 ingest gaps across 20 kinds, and 61 gems the analyzer did not model. Those are project-reported results, separate from our 1,726-test sandbox run. An open issue also documents a ViewComponent app that passed check with zero diagnostics yet emitted code that raised NameError while loading. A clean report therefore needs a generated build, translated tests, and differential requests against Rails behind it.
Strict targets do not verify CSRF tokens
Security behavior varies by target. The current guide says the Ruby family verifies CSRF when the application explicitly declares protect_from_forgery with: :exception. Strict targets issue no token and perform no verification. Even the Ruby family does not apply Rails' implicit default, and its session cookies are signed rather than encrypted. An operator must read these as runtime differences, not compiler trivia.
The 82 failed tests in our run do not establish a CSRF defect. The security limit comes from Roundhouse's coverage guide. If you expose generated code to browsers, put strict-target output behind a trusted protection layer and test form, session, Origin, and WebSocket behavior. DOM comparison can prove response shape, but matching HTML alone does not prove the same security boundary.
The September 18 snapshot has active follow-up work
Release v2026.9.18 is labeled the first snapshot. GitHub recorded a push on September 30, 2026, with 73 open issues and 11 open pull requests that day. Current reports cover route emission and output that differs between runs. The work continues after the tag, but the compatibility surface is young.
Roundhouse is worth installing for check, request tracing, and agent questions because those uses leave Rails in charge. Transpilation deserves a narrower trial on one application and one target. Our 152-second build shows the Rust project compiles at 497ff91, while the 82 failures show why generated production code still needs its own Rails comparison and security review before traffic moves.