# EventMachine: the reactor pattern Ruby had before servers got fast

> A C++ extension wrapped in a Ruby API that turns connection callbacks into application logic, still shipping commits years after its last tagged GitHub release.

**eventmachine/eventmachine** — EventMachine: fast, simple event-processing library for Ruby programs

- Repository: https://github.com/eventmachine/eventmachine
- Stars: 4,276 · Forks: 633
- Language: Ruby
- License: NOASSERTION
- Published: 2026-10-06 · Updated: 2026-10-06 · Language: en
- Canonical page: https://hysenlabs.com/projects/eventmachine-eventmachine

## A reactor that predates most of its audience

EventMachine describes itself as an event-driven I/O and lightweight concurrency library for Ruby, providing event-driven I/O using the Reactor pattern. That is the whole design in one sentence: one thread waits on many sockets, and your code is a set of callbacks rather than a control flow.

The README situates it against a specific set of peers: JBoss Netty, Apache MINA, Python's Twisted, Node.js, libevent and libev. That list dates the project more than any version number does. Node.js is listed as a comparable, which means EventMachine predates the arrival of event-driven I/O in mainstream server JavaScript, and the library itself says it has been around since the early 2000s.

Two goals are stated. The first is high scalability, performance and stability for demanding production environments. The second is an API that removes the complexity of threaded network programming so engineers can concentrate on application logic. The second goal is the one that shapes the code you write, because it is achieved by never giving you a thread per connection.

## Installing the gem and starting the reactor

```ruby
 require 'eventmachine'

 module EchoServer
   def receive_data data
     send_data ">>>you sent: #{data}"
     close_connection if data =~ /quit/i
   end
end

# Note that this will block current thread.
EventMachine.run {
  EventMachine.start_server "127.0.0.1", 8081, EchoServer
}
```

## post_init, receive_data and unbind are the whole vocabulary

The example module defines three methods, and they are the API you will use for almost everything: `post_init` when a connection is established, `receive_data` when bytes arrive, and `unbind` when the connection goes away. Two more calls appear inside them. `send_data` writes to the socket, and `close_connection` ends it.

That is deliberately small, and it is where the library's claim about eliminating the complexity of threaded network programming is earned or lost. There is no connection object to hold on to, because the connection is the thing that called you. Reading the callback list top to bottom tells you the lifecycle in order: a connection appears, bytes arrive, the connection ends, and your job is to notice when it does so you can release whatever you associated with it.

The cost is that state has to live somewhere other than a stack frame. Since `receive_data` can be called with a partial message at any time, buffering, framing and reassembly are yours to implement. For a line protocol like the echo server that is nothing. For a binary protocol with length prefixes it is real work, and no framing helper is visible in this example.

## Who the README says uses it, and for what

The README groups the intended uses into four categories and names a real project in each, which is more useful than a generic feature list.

Scalable event-driven servers, with Thin and Goliath as the examples. Asynchronous clients for protocols and REST APIs, with `em-http-request` and the `amqp` gem. Network proxies with custom logic, with Proxymachine. And file or network monitoring tools, with `eventmachine-tail` and logstash.

The proxy case is the one that explains why this library still has a place. A proxy is a program with one job per connection and no database, and the reactor model maps onto it almost exactly. Proxymachine in particular is the kind of tool that would be painful to write with a thread per client and trivial with a callback per connection.

The logstash mention is a fair proxy for how embedded this library is in other people's infrastructure. It is also a reminder to check the version your dependency expects, since a library used by a large project inherits that project's stability concerns.

## Ruby, JRuby and a C++ extension in ext/

The README states that EventMachine supports Ruby 2.0.0 and later, and points to `.github/workflows/workflow.yml` for the tested versions rather than listing them inline. It runs on JRuby and, in the README's own phrasing, works well on Windows as well as many operating systems from the Unix family, naming Linux, Mac OS X and the BSD flavours.

The repository layout explains how that support is achieved. There is an `ext/` directory for the native extension, which is where the reactor itself lives, and a `java/` directory for the JRuby side. `win_gem_test/` is a separate area for testing the packaged gem on Windows, and `rakelib/` with a `Rakefile` and an `eventmachine.gemspec` is the build and packaging layer. `lib/`, `tests/`, `examples/` and `docs/` round it out, with `CHANGELOG.md` at the root.

That layout has a consequence for adoption. A library with a C++ extension needs to compile against your Ruby, your compiler and your JRuby if you use it, and the native part is where platform-specific breakage lives. Installing from a gem gets you a prebuilt extension where one exists, but a source install on an unusual combination is a different experience from a pure-Ruby library.

## Commits in 2026, tagged releases that stopped in 2018

The release history in the repository needs reading carefully, because the two dates disagree. The most recent GitHub release is v1.2.7, published on 2018-05-12, whose entire note is a fix for a segfault on large numbers of connections. Before it, v1.2.6 on 2018-04-30 fixed a segfault when an exception is raised from an `unbind` callback, a race condition while initializing the machine, a `bind()` conflict with `std::bind()` on newer compilers, more verbose SSL connection errors, and Java-side fixes including returning zero when sending data to a closed connection.

Against that, the repository's last push was on 2026-07-24. So development has continued for years without new tags appearing on GitHub. If you are picking a version, do not assume the 2018 tag is the ceiling of what exists, and do not assume a recent commit means a recent release either.

Licensing is dual and unusual: the README says EventMachine is copyrighted free software made available under the terms of either the GPL or Ruby's License, with copyright dated 2006 to 2007 to Francis Cianfrocca. GitHub itself reports no recognised licence type for the repository, so the README sentence is the authoritative statement and the two-option scheme is the one to rely on. In practice the Ruby's License option is what makes the library usable inside a permissively licensed product, and choosing it is a decision worth making explicitly rather than by default.

## Reference docs, a wiki, and a community that has moved on

The documentation section is honest about its own thinness, saying that currently there are only reference documentation and a wiki. The reference is generated rubydoc for the repository frames, which is fine for signatures and useless for the reactor's control flow. The wiki is where behaviour tends to live, which means it is also where rot tends to accumulate.

For orientation the README points at two older introductions rather than writing one: a blog post about EventMachine by Ilya Grigorik and EventMachine introductions by Dan Sinclair. Both predate the modern Ruby ecosystem, so treat them as conceptual background and check anything version-specific against the source.

The community channels are the part most likely to send you nowhere. The README lists a Google Group mailing list and the IRC channel `#eventmachine` on `irc.freenode.net`. Freenode is long gone as a network, so that channel cannot be where answers are today. The mailing list is the more plausible route, and the source and issue tracker are the last resort. The README's own alternatives section points to Celluloid if you want to stay with Ruby but leave EventMachine behind.

## Conclusion

EventMachine is worth reaching for when you are writing a long-lived connection server in Ruby and want a single-threaded reactor rather than a thread per client: the callback style keeps the connection lifecycle visible in three methods, and the same API covers a proxy, an async HTTP client and an AMQP consumer. Two caveats should shape the decision. The library's own age is the risk, not the code: commits landed on 2026-07-24 while the most recent tagged release is 1.2.7 from 2018, so you are tracking a project whose release process on GitHub has been dormant for years. And the documentation is thin by the maintainers' own admission, with a rubydoc reference and a wiki as the whole of it. Install it with `gem install eventmachine`, read the reactor callback list before your first connection, and check the `ext/` build against your Ruby and JRuby versions.

## FAQ

### How do you install EventMachine in a Ruby project?

The README gives two routes: `gem install eventmachine` from RubyGems, or adding `gem 'eventmachine'` to your Gemfile if you use Bundler. Because the library has a C++ extension in `ext/`, a source install compiles native code.

### Which Ruby versions does EventMachine support?

The README says Ruby 2.0.0 and later, and directs you to `.github/workflows/workflow.yml` for the versions actually tested. It also runs on JRuby, with a `java/` directory in the repository for that side.

### What licence is EventMachine released under?

The README states that EventMachine is free software available under the terms of either the GPL or Ruby's License, with copyright from 2006 to 2007 to Francis Cianfrocca. GitHub does not report a recognised licence type for the repository.

### Is EventMachine still being worked on?

Commits have continued well past its last tag: the repository's last push was on 2026-07-24, while the most recent GitHub release is v1.2.7 from 2018-05-12. The changelog in the repository root is the fuller record.

### Which projects use EventMachine?

The README names Thin and Goliath for event-driven servers, `em-http-request` and the `amqp` gem for asynchronous clients, Proxymachine for proxies, and `eventmachine-tail` and logstash for monitoring tools. Those are presented as examples of the categories it suits, not as an endorsement list.

## Sources

- [eventmachine/eventmachine on GitHub](https://github.com/eventmachine/eventmachine)
- [Issues](https://github.com/eventmachine/eventmachine/issues)
- [README](https://github.com/eventmachine/eventmachine/blob/master/README.md)
- [Releases](https://github.com/eventmachine/eventmachine/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/eventmachine-eventmachine