Falcon: a Ruby HTTP server built on fibers, with HTTP/1 and HTTP/2 in the same process

The problem Falcon solves for Ruby deployments

Most Ruby web applications run behind two moving parts: an application server that speaks Rack, and a separate proxy that terminates TLS and speaks HTTP/2 to clients. Falcon collapses that arrangement. The README describes it as a "multi-process, multi-fiber rack-compatible HTTP server built on top of async, async-container and async-http", and it states that Falcon supports HTTP/1 and HTTP/2 natively. That native support is the practical difference. A Rack application mounted under Falcon can receive HTTP/2 requests without an Nginx or Envoy hop in front of it.

The intended audience is Ruby developers who already run Rack applications, including Rails, and who want one component where they previously had two. The author's own motivation section is explicit about this: after getting the server working, he replaced "production (Nginx+Passenger) and development (Puma) with Falcon" to reduce environment-specific bugs. That is a single-operator account, not a survey, but it tells you what the project is optimised for: consistency between the machine you develop on and the machine you deploy to.

The second audience is narrower. The README describes a long-term goal of a web application platform that describes its own components, including databases, periodic jobs and background jobs. The repository already carries an examples/ directory with entries such as examples/redis/, examples/sequel/, examples/grpc/ and examples/cluster/. Those are starting points, not a finished platform. Treat the platform ambition as direction, not as shipped scope.

Fibers, processes and the request path through async-http

Falcon's concurrency model is the part worth understanding before you deploy it. The README states that each request is executed within a lightweight fiber and can block on upstream requests without stalling the entire server process. That is the core claim: a fiber that waits on a database or an HTTP call yields, and the process keeps serving other requests.

The layering is visible in the dependencies. async provides the fiber scheduler and event loop. async-container provides the multi-process supervision, which is why Falcon can run several worker processes and restart them. async-http provides the actual client and server protocol implementations, including HTTP/2. Falcon itself is the Rack adapter and the service wiring on top. The repository layout supports this reading: the code lives in lib/, the runnable examples sit in examples/, and the test suite is invoked with sus rather than RSpec.

There is a cost to blocking-on-fibers that the README does not dwell on. Any code that blocks the thread rather than yielding to the scheduler, such as a C extension doing synchronous I/O without fiber awareness, will hold up the fiber and therefore the work scheduled behind it. The performance-tuning guide is where that behaviour is discussed, and it is the document to read before you assume your existing gem set is safe. The guides index links it as Performance Tuning.

Recent releases also show that observability is part of the server rather than bolted on. v0.55.0 added support for async-utilization metrics, and v0.55.1 through v0.55.4 are a run of fixes around requests_active, including decrementing it when closing a response body raises and when Falcon::Server#call raises. Those release notes are a useful signal about how utilisation numbers are produced: they are maintained by the server around the response body lifecycle, so a middleware that swallows or delays body close can affect them.

Installing Falcon and running a first Rack application

The README points at the project documentation for usage rather than repeating it, so the canonical first steps live in the Getting Started guide on socketry.github.io. Falcon ships as a Ruby gem, and the repository is a gem project with a falcon.gemspec at the top level. The usual path is to add it to your bundle and run the command-line entry point.

Start by adding the gem to your Gemfile and installing it:

bundle add falcon
bundle install

Falcon provides an executable, so once the gem is installed you can start a Rack application from its directory. The repository's examples/hello/ directory is the smallest reference application to compare against:

bundle exec falcon serve

According to the README, the server you get is multi-process and multi-fiber, and it speaks HTTP/1 and HTTP/2 on the same listener. If you point a browser at it you should see your application's response; the protocol negotiated depends on what the client offers. For a Rails application, the Rails Integration guide is the one to follow, because Rails brings its own middleware stack and initialisation order.

Deployment is documented separately. The Deployment guide covers "the recommended deployment methods, configuration options, and examples for different environments, including systemd and kubernetes". If you run containers, read that guide before writing your own entrypoint, because the process model (a supervisor plus workers) does not map cleanly onto a single foreground command in every orchestrator.

Where Falcon is the wrong tool

The most concrete limitation is not performance, it is configuration stability. v0.55.0 is marked Breaking in three places: it drops the dependency on async-container-supervisor in favour of async-service-supervisor, it removes support for legacy environments including Falcon::Configuration in favour of Async::Service::Configuration directly, and it removes the bake falcon:supervisor:restart task in favour of async:service:supervisor:restart. Anyone who wrote deployment automation against the older names had to rewrite it. If your organisation requires a long deprecation window before a rename, this project's release cadence will be uncomfortable.

The second limitation is the fiber model itself. A request that blocks the thread instead of yielding will not get the concurrency benefit the README describes, and the failure is silent: the server keeps running, it just stops overlapping work. That makes Falcon a poor fit for applications dominated by synchronous C extensions or by gems that were written assuming a thread-per-request server.

The third is scope. Despite the platform ambition in the README, Falcon is a web server. It does not manage your database, your background job queue or your scheduled tasks. The examples/ directory shows how to combine it with those things, but that is sample code, not a supported platform. If you want a single tool that owns all of that today, Falcon is not it.

Finally, there is the support model. The README offers Priority Business Support through Socketry.io, with direct Slack and email access, advance notification of bugs and security issues, and priority consideration of feature requests. That is a commercial arrangement sitting alongside an MIT licence. If you need guaranteed response times, that is where they come from, not from the repository.

Falcon compared with Puma and with a proxy-fronted stack

The obvious alternative is Puma, which the README names as the development server the author replaced. The difference is architectural, not just a matter of which one is faster. Puma uses a thread pool per process: each request occupies a thread for its duration, so concurrency is bounded by the number of threads you configure, and a slow upstream call ties up a thread. Falcon uses fibers on an event loop, so a request waiting on I/O yields and the process continues. The trade-off runs the other way too. Puma's model is easy to reason about and works with any gem, including ones that block the thread, because blocking a thread only affects that request. Falcon's model rewards fiber-aware code and punishes the opposite.

The second alternative is keeping Puma and putting Nginx or another proxy in front for TLS and HTTP/2. That preserves the older operational model and gives you a mature configuration language for routing, caching and rate limiting. Falcon's counter-argument is the one in its motivation section: one component instead of two, and fewer differences between development and production. If you already have a proxy configuration you trust and a team that knows it, Falcon removes a layer you may not want removed.

A third point of comparison is the cluster story. v0.56.0 added Falcon::Environment::Cluster and Falcon::Service::Cluster for running workers with independently bound endpoints, plus Falcon::Listener to describe bound listeners shared by regular workers or owned by cluster workers. v0.57.0 updated the Envoy cluster example to use dedicated CDS and EDS services from async-service-supervisor-envoy v0.5. That is a real capability for dynamic load balancing via xDS and ORCA, but it is also the newest and least settled part of the server, and it depends on Envoy being part of your infrastructure.

Maintenance, upgrades and what the MIT licence leaves you

The repository is not archived, and the last push was on 2026-08-11. Releases have been frequent: v0.55.6 on 2026-07-22, v0.56.0 on 2026-07-31 and v0.57.0 on 2026-08-09. That cadence cuts both ways. Fixes arrive quickly, as the run of requests_active corrections in v0.55.1 to v0.55.4 shows, but so do breaking changes, as v0.55.0 shows. The pre-1.0 version number is consistent with that: the maintainers have not committed to a stable API surface.

Upgrade cost is therefore mostly about configuration and task names, not about your application code. Before upgrading across a minor version, read the release notes for that version in releases.md or on the releases page. The v0.55.0 notes are the model to expect: a short list of renames with a migration instruction attached to each. Budget time for that, and pin the gem version in your Gemfile.lock so an unattended bundle update cannot move you across a breaking change.

The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are included. That is the whole of the licence text's requirement; it does not impose a copyleft obligation on your application. The Priority Business Support offering is a separate commercial agreement and is not part of the licence. This is a description of what the licence says, not legal advice; if your organisation has specific obligations around attribution in distributed artifacts, have your own counsel read license.md.

Editorial conclusion

Adopt Falcon if you run a Rack or Rails application, want HTTP/2 termination inside the Ruby process, and can track a configuration API that has changed across releases (v0.55.0 removed Falcon::Configuration in favour of Async::Service::Configuration). Do not adopt it if you need a stable, versioned configuration surface with a long deprecation window, or if you have no appetite for pinning versions. Before committing, check the guides for Rails Integration and Deployment on socketry.github.io, then run your own application under the server and check that your middleware still behaves the same way, because v0.57.0 lists a Rack Compatibility change.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. socketry/falcon on GitHub