kino logo

kino

A high-performance Ractor web server for Ruby 4.0+: Rack 3-based, with a Rust Tokio/Hyper front-end and Ractor-parallel Ruby workers and threaded fallback mode.

releaseyard docs
Website GitHub

What is it?

What it is

Kino is a high‑performance Ruby 4.0+ web server that runs Rack 3 applications in parallel using Ractors. It combines a Rust (tokio + hyper) network front‑end with a pool of Ractors (or Threads) to dispatch requests, enabling true CPU parallelism in a single process.

Why it exists

Ruby threads are bound by the Global VM Lock, so production servers fork a process per core to achieve parallelism, incurring memory and startup overhead. Ractors remove the GVL restriction, allowing multiple Ruby workers in one process. Kino provides the missing piece—a server that can dispatch HTTP requests to Ractors, delivering better throughput, lower memory usage, and graceful shutdown while keeping a familiar Puma‑style API.

Who should use it

Ruby 4.0+ developers building high‑performance Rack or Rails applications who want a single‑process, Ractor‑based web server with low memory footprint and fast I/O/CPU throughput.

Who should avoid it

Users on Ruby versions older than 4.0, applications that cannot be made Ractor‑shareable, or teams that require fully stable, production‑grade forking semantics and cannot tolerate experimental Ractor features.

How it works

A quick walkthrough in plain English

How kino works

Step 1 of 3

You interact with it

Open kino, send a request, or connect it to your stack.

Features

High-performance Ractor web server for Ruby 4.0+
Parallelism without forking (single process with multiple Ractors)
Memory efficiency (~7× less memory than Puma clusters)
Production-ready plumbing (graceful shutdown, crash supervision)
`kino --check` diagnostic tool for Ractor compatibility
Rust-based front-end (tokio + hyper) for network handling
Rack 3 compliance with streaming bodies and headers
Async logging and access logs with color-coded output
Request timeouts and backpressure handling (503 responses)
Live stats and metrics reporting

Advantages

  • 1.5-2× faster than Puma fork clusters on I/O-light endpoints
  • 30%+ CPU performance gain in Ractor mode vs. threaded
  • Fraction of memory usage compared to fork-based servers
  • Parallel CPU work up to 5× faster in Ractor mode
  • Graceful shutdown and crash resilience
  • Transparent diagnostics for Ractor isolation issues
  • Familiar Puma-like configuration and CLI
  • Supports Rails in threaded fallback mode
  • Async access and app logging without performance penalty
  • TLS support via rustls

Disadvantages

  • Requires Ruby 4.0+ (Ractors are experimental)
  • Rails apps cannot use Ractor mode yet (threaded fallback only)
  • Potential compatibility issues with non-shareable apps
  • Rust dependencies may complicate builds on non-Linux/macOS
  • Memory benefits depend on app shareability
  • Experimental features may have stability risks
  • Limited to Ruby ecosystem (no direct Node.js/Python support)
  • Complex configuration for optimal performance tuning

Installation

FAQ

Why should I use Kino instead of Puma?

Kino runs your Ruby code in a single process using Ractors, avoiding the memory overhead of forking. It offers 1.5-2× faster I/O performance and 30%+ CPU gains over Puma's fork cluster, with significantly lower memory usage (~7× less for simple apps).

How do I ensure my app is Ractor-shareable?

Your app must avoid capturing unshareable state (e.g., mutable variables, instance variables). Use `Ractor.shareable_proc` for endpoints and freeze configuration at boot. Kino's `--check` flag identifies blockers preventing Ractor mode.

What's the difference between :ractor and :threaded modes?

:ractor runs parallel Ruby code in isolated Ractors (requires a shareable app), while :threaded uses GVL-bound threads (works for any app, including Rails). :ractor is faster for CPU-bound tasks but requires careful app design.

Can Kino handle Rails applications?

Yes, but Rails apps run in Kino's :threaded fallback mode today since they aren't Ractor-shareable. Kino provides a :threaded-compatible setup with similar performance to Puma, though Ractor support for Rails is under development.

How does Kino handle slow requests?

Set `request_timeout` to limit response time. If a handler exceeds this, Kino returns a 504 error immediately while allowing the handler to finish. This prevents blocking other requests but requires tuning based on your app's slowest endpoints.

How does Kino manage logging efficiently?

Kino uses an async logging system where log lines are written through a lock-free channel to a Rust flusher thread. This avoids mutex contention, allowing Kino to handle ~2.4× more requests per second compared to a standard `::Logger`.

Loading documentation…
View on GitHub

Featured in Videos

YouTube tutorials and walkthroughs for kino

Alternatives

Similar projects ranked by category, topics, and text overlap.

Compare
kino | MushyBook