Skip to content
Tech News
← Back to articles

Kino: A high-performance Ractor web server for Ruby 4.0

read original more articles
Why This Matters

Kino introduces a high-performance web server for Ruby 4.0+ that leverages Ractors to run code in parallel across multiple cores, significantly improving speed and memory efficiency compared to traditional forking servers like Puma. Its architecture offers faster request handling, reduced memory footprint, and enhanced production features such as graceful shutdowns and robust error handling, making it a compelling choice for scalable Ruby web applications.

Key Takeaways

Kino

Kino is a high-performance Ractor web server for Ruby 4.0+.

Ruby threads cannot run Ruby code in parallel, so production setups fork a process per core and pay for each copy in memory. Kino runs your code on every core in one small process. A Rust (tokio + hyper) front-end owns the network, parallel Ractors run your Rack 3 app, and a threaded fallback mode runs everything else, Rails included.

Fast. On a real 8-core server, every Kino mode is 1.5-2× ahead of a Puma fork cluster on I/O-light endpoints. Ractor mode also wins on pure CPU, 30%+ . Benchmarks below.

On a real 8-core server, every Kino mode is ahead of a Puma fork cluster on I/O-light endpoints. Ractor mode also wins on pure CPU, . Benchmarks below. A fraction of the memory. About ~7× on the simplistic bench Ractor app, and about 4× less memory than a Puma cluster serving Rails in fallback threaded mode.

About on the simplistic bench Ractor app, and about than a Puma cluster serving Rails in fallback threaded mode. Parallel without forking. Ractor mode runs CPU work more than 5× faster than Kino's own GVL-bound threaded mode, in the same small process.

Ractor mode runs CPU work than Kino's own GVL-bound threaded mode, in the same small process. Production plumbing included. Graceful drain, crash supervision and respawn, bounded queues with 503 backpressure, request timeouts, hardened intake (slowloris and TLS-handshake deadlines, connection and body-size caps), an on_error hook for your error tracker, TLS (rustls), live stats, async access and app logging.

Graceful drain, crash supervision and respawn, bounded queues with 503 backpressure, request timeouts, hardened intake (slowloris and TLS-handshake deadlines, connection and body-size caps), an hook for your error tracker, TLS (rustls), live stats, async access and app logging. Tells you why. kino --check lists exactly what blocks your app from ractor mode, finding by finding, so you do not have to decode Ractor::IsolationError yourself.

lists exactly what blocks your app from ractor mode, finding by finding, so you do not have to decode yourself. Puma-shaped. The same workers × threads topology, a familiar config DSL, a kino CLI. If you can run Puma, you can run Kino.

N.B.: Ractors are officially experimental in Ruby 4.0, and so is this server. The threaded mode is solid. Still, Kino aims to be the best way to experiment with Ractors today—and the best Ractor server when they become stable.

... continue reading