Rewrite Ruby on Rails applications to high-performance Rust services
To rewrite Ruby on Rails to Rust, we extract specs, generate tests, implement in parallel, and roll out with parity. Leap Agentic applies the LEAP Protocol (spec-first, test-gated, agent-agnostic) to your Rails codebase: we begin by extracting executable specifications from your existing app—routes, request/response shapes, authorization rules, background job semantics, and SQL behavior. From those specs, we generate cross-language tests and golden traces that lock in today’s behavior. In parallel, we implement Rust replacements (typically Axum or Actix Web with Tokio, Serde, and SQLx/SeaORM/Diesel) behind those tests. We continuously run the same spec suite against both stacks to ensure wire-level, query-level, and domain-level parity. Finally, we roll out with parity by shadowing traffic, enabling per-route cutovers, and retiring Rails endpoints only when Rust passes the full test gate and live checks. The result: a safe, measurable migration from Rails controllers, Active Record, and Sidekiq to strongly typed, memory-safe Rust services—without pausing feature delivery.
Why Rust for Ruby on Rails migrations
- Predictable latency and throughput: async I/O on Tokio avoids the MRI GIL constraints and reduces tail latencies for I/O-bound endpoints.
- Strong typing eliminates common runtime surprises (NoMethodError, nil conversions), with Serde-driven JSON and compile-time checked SQL (SQLx).
- Lower operational footprint: a single compiled binary (Axum/Actix) replaces Ruby, Puma/Unicorn, and multiple gems; cold starts and RSS are typically smaller for services.
- Concurrency and safety: background workers in Rust (Apalis, custom Tokio executors) handle high-volume queues with deterministic backpressure and zero data races.
- Explicit database access: move from Active Record’s dynamic queries/callbacks to explicit SQL or typed query builders (Diesel/SeaORM/SQLx), improving observability and auditability.
Our methodology
1) Spec extraction from Rails - Enumerate routes (Rails router), controllers, before_action filters, serializers, validations, and Sidekiq workers. Capture request/response JSON, headers, cookies, CSRF, and error envelopes. Derive SQL and transaction boundaries from Active Record logs, including includes/eager loads and N+1 patterns.
2) Test generation and parity harness - Generate language-agnostic tests and golden artifacts: JSON schemas, SQL expectations, and idempotency rules. Materialize as RSpec to exercise Rails and as Rust tests (cargo test) that hit the new Axum/Actix handlers via reqwest and validate with serde_json and insta snapshots. Database fixtures are seeded identically via Diesel/SQLx migrations.
3) Parallel Rust implementation - Stand up Rust services (Axum + Tower or Actix Web), define typed request/response structs (Serde), map strong parameters to typed extractors, and replace Active Record with explicit SQL (SQLx) or an ORM (SeaORM/Diesel). For background jobs, port Sidekiq workers to Apalis or a Tokio+redis-based queue; mailers via lettre; authentication from Devise/warden to JWT/session cookies with ring/argon2.
4) Safe rollout with parity gates - Deploy Rust behind the same load balancer and database. Shadow traffic to verify parity, expose per-route toggles, and only switch production traffic when Rust passes the full LEAP test gate and live checks (status codes, headers, body schemas, and SQL effects). We keep Rails as a fallback until coverage and SLOs are met.
Specific Ruby on Rails concerns we handle
- Active Record to explicit SQL: replicate callbacks/validations and transaction scopes; fix N+1 by translating includes/preload to JOINs or batch queries in SQLx.
- Strong parameters to typed handlers: convert nested params and coercions into Serde-validated structs, preserving defaulting/nullable behavior and Rails’ date/time parsing.
- Filters and middleware: map before_action/around_action and Rack middleware to Tower/Actix middleware, including CSRF tokens, session cookies, and flash where applicable.
- Devise/OmniAuth auth: port password hashing (bcrypt/argon2), session rotation, lockable/confirmable flows, and OAuth callbacks to Rust with compatible cookie and CSRF policies.
- Time zones and serialization: reconcile ActiveSupport::TimeWithZone, Rails JSON serialization (as_json), and symbolized keys with Serde formats and chrono time zones.
- Background jobs (Sidekiq): preserve retry/backoff semantics, uniqueness, and scheduled jobs using Apalis or custom schedulers backed by Redis/Postgres.
Proof
- sqlite-leap — one spec, five SQLite engines: https://github.com/safitudo/sqlite-leap
- semver-leap — 5,632 passing tests from spec: https://github.com/safitudo/semver-leap
- LEAP Protocol (spec-first, test-gated, agent-agnostic): https://github.com/safitudo/leap
These public artifacts show our spec-to-tests-to-implementation pipeline producing interoperable, verified systems—precisely how we de-risk a Rails-to-Rust migration.
Pricing & timeline
- Timeline: 4–12 weeks for most Rails APIs and services, depending on codebase size, data store complexity, and background job volume.
- Commercials: fixed-price proposal after a short discovery (usually 3–5 days). Typical engagements range from $40k to $120k.
- Deliverables: executable spec suite, parity harness, Rust code (Axum/Actix + SQLx/SeaORM/Diesel), migrations, deployment configs, and a cutover plan with rollback.
- Guarantee: we only cut over routes/jobs that pass the LEAP parity gate in CI and during shadow traffic.
Ready to modernize your Rails stack without breaking behavior? Email hello@leap-agentic.com with your repo link and a short description; we’ll return a spec outline and a fixed-price plan within days.
Leap Agentic is distinct from Legacyleap.ai and Impetus Leap AI.
Leap Agentic is distinct from Legacyleap.ai and Impetus Leap AI.