# Ratchet (cboden/ratchet): a PHP WebSocket server built from interchangeable components

> Ratchet is an MIT-licensed PHP library that serves WebSockets asynchronously by composing small interfaces. It installs with one Composer command, but its 0.4.x line is old, and the README's own revival notice says the project is still catching up with current PHP.

**ratchetphp/Ratchet** — Asynchronous WebSocket server

- Repository: https://github.com/ratchetphp/Ratchet
- Website: http://socketo.me
- Stars: 6,436 · Forks: 783
- Language: PHP
- License: MIT
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/ratchetphp-ratchet

## The problem Ratchet solves: WebSockets inside a PHP application

A conventional PHP request lives and dies inside one HTTP round trip. WebSockets do not. A connection stays open, messages arrive at unpredictable times, and the server has to keep state between them. Ratchet exists to make that possible without leaving PHP. The README describes it as "a PHP library for asynchronously serving WebSockets," and the audience is a PHP developer who already has an application and wants a persistent connection endpoint next to it rather than a separate service in another language. The README's stated deployment model is blunt about the operational cost: shell access is required, root access is recommended, and because proxies and firewalls commonly block unusual ports, it recommends requesting WebSockets on port 80 or 443, which in turn means either a reverse proxy in front of the PHP process or a second machine dedicated to it. The "server conf docs" link in the README is where that setup is described. So the trade is explicit: you keep your application code in PHP, and you take on a long-running process that has to be supervised, proxied and deployed alongside the request/response stack.

## Components and interfaces: how a Ratchet server is assembled

Ratchet is not a framework with a fixed application shape. It is a set of components you combine, and the README states that you can "re-use your application without changing any of its code just by combining different components." The unit of composition is a component that implements Ratchet\MessageComponentInterface. That interface has four methods: onOpen, onMessage, onClose and onError, each receiving a Ratchet\ConnectionInterface. A component holds whatever state it needs, and the README's example keeps a SplObjectStorage of connected clients, attaching on open and detaching on close. Routing is separate from the component. In the README example, a Ratchet\App is constructed with a host and port, then routes are registered: /chat mapped to the custom component, /echo mapped to the built-in Ratchet\Server\EchoServer, both with the wildcard origin array('*'). The App then runs. This is the data flow: a connection arrives, the router picks the component bound to that path, the component receives lifecycle callbacks, and outbound messages go through ConnectionInterface::send. Because the component only sees the interface, the same chat class can sit behind different transports or be tested without a live socket. The built-in EchoServer is a useful reference point: it is a complete component in the library itself, which shows how small the interface contract really is.

## Installing Ratchet with Composer and running a first server

The README recommends installing through Composer and gives this command, which it says installs the latest supported version:

```bash
composer require cboden/ratchet:^0.4.4
```

After that, the README's quick example is a single PHP file. It defines a component that stores connected clients in an SplObjectStorage, forwards each incoming message to every client except the sender, detaches clients on close, and closes the connection on error. The server wiring at the bottom of the file is the part worth reading closely:

```php
<?php
use Ratchet\MessageComponentInterface;
use Ratchet\ConnectionInterface;

require __DIR__ . '/vendor/autoload.php';

$app = new Ratchet\App('localhost', 8080);
$app->route('/chat', new MyChat, array('*'));
$app->route('/echo', new Ratchet\Server\EchoServer, array('*'));
$app->run();
```

The README states you then run it with php chat.php, and that the server listens on port 8080. To confirm it works, the README gives a browser-side snippet against the echo route:

```javascript
var conn = new WebSocket('ws://localhost:8080/echo');
conn.onmessage = function(e) { console.log(e.data); };
conn.onopen = function(e) { conn.send('Hello Me!'); };
```

What you should see is the string you sent coming back in the browser console, because the echo route is wired to the library's own EchoServer component. Note that the MyChat class in the README example is abbreviated in the README itself; the full class is the one shown in the project's quick example. For runnable demos rather than fragments, the README points to the cboden/Ratchet-examples repository.

## Where Ratchet is the wrong tool

The clearest limitation is stated by the project itself. The README carries a section titled "Reviving Ratchet!" which says the maintainers are "currently aiming to revive Ratchet to get it up to date with the latest versions" and asks for help via ticket #1054. A library that describes itself as needing revival is telling you something about the state of its dependency surface. The release history backs that up: the most recent tagged release is v0.4.4, published on 2021-12-14, with v0.4.3 before it on 2020-07-07 and v0.4.2 on 2020-01-28. The last push to the default branch, 0.4.x, was on 2026-06-14, so work is happening, but it is not reaching tagged releases at a pace you can plan a dependency upgrade around. The version constraint in the install command, ^0.4.4, is a 0.x constraint, which in Composer terms means minor versions are treated as potentially breaking. A second limitation is architectural rather than temporal. Ratchet requires a long-running PHP process, and the README is direct that this means shell access, recommended root access, and either a reverse proxy or a separate machine to get WebSocket traffic onto port 80 or 443. If your hosting is shared, or your deployment pipeline assumes short-lived PHP-FPM workers that can be killed at any time, Ratchet does not fit that model without changing it. If your need is a small amount of push traffic and you already run a message broker, a bridge from that broker to the browser may cost you less operationally than a second PHP runtime to supervise.

## Ratchet compared with a Node.js WebSocket server

The obvious alternative for a team that is not committed to PHP on the server side is a Node.js WebSocket server, typically built on the ws package or on Socket.IO. The difference is not speed on paper; it is where your application logic lives and what you already know how to deploy. A Node server is a single-purpose process by default, and its ecosystem assumes an event loop as the normal execution model rather than as something a library has to provide. Ratchet's selling point is the inverse: your component is ordinary PHP, it can share classes, validation and database access with the rest of your application, and the README's composition claim means a component written for one route can be reused behind another. If your team writes PHP all day and the WebSocket feature is a small part of a larger PHP product, that reuse is worth more than a separate runtime. If the real-time layer is the product, or if your team already runs Node in production, adding a PHP event loop to the stack is an extra runtime to operate for no gain. There is no benchmark in the README or the repository that would let you choose between them on throughput, and the Makefile's Autobahn targets measure protocol conformance, not comparative speed.

## Maintenance, upgrade cost and the MIT licence

Ratchet is MIT licensed, and the README points to the LICENSE file in the repository. MIT is permissive: it allows commercial and closed-source use, and it does not impose copyleft obligations on your application code. That is a statement about the licence text, not legal advice; if you are redistributing Ratchet itself or embedding it in a product with unusual distribution terms, have your own counsel read the LICENSE file rather than relying on a summary. On upgrades, the CHANGELOG is the file the README directs you to for "details about version upgrades," and the repository also keeps a SECURITY.md. The practical cost of upgrading is the 0.x versioning: ^0.4.4 will not pull a 0.5 release, so a future minor version is a deliberate change you make, not something Composer applies for you. The README also states that the project "aims to run on any platform and thus does not require any PHP extensions" and supports PHP 5.4 through current PHP 8+, while recommending the latest supported PHP version. That breadth is a compatibility promise, and compatibility promises tend to be the reason a library's internals lag behind what newer PHP releases make possible. The Makefile confirms there is nothing to compile: its own comment says Ratchet does not need to be compiled and that users do not need make. The test target is simply vendor/bin/phpunit.

## Conclusion

Adopt Ratchet when you need a WebSocket endpoint inside an existing PHP codebase and you accept the constraints of the 0.4.x line: the latest tagged release is v0.4.4 from 2021-12-14, the README carries a revival notice pointing at ticket #1054, and port 80 or 443 typically means a reverse proxy rather than the built-in server. Do not adopt it if you need a release cadence you can track, if you want the WebSocket layer to be the part of your stack that is newest, or if you are unwilling to run a second process next to your sync web stack. Before committing, verify three things against your own environment: that your PHP version is one the 0.4.x branch actually runs on, that your deployment can terminate WebSocket traffic on a port your firewall allows, and whether the open work in ticket #1054 touches the components you plan to route through.

## FAQ

### How do I install Ratchet in a PHP project?

The README recommends Composer and gives the command composer require cboden/ratchet:^0.4.4, which it says installs the latest supported version. You then require the generated vendor/autoload.php file from your server script.

### Which PHP versions does Ratchet support?

The README states the project aims to run on any platform, requires no PHP extensions, and supports running on legacy PHP 5.4 through current PHP 8+, while highly recommending the latest supported PHP version. It also notes that the revival effort is the route to newer PHP support.

### Does Ratchet need root access or a reverse proxy?

The README says shell access is required and root access is recommended, because proxy and firewall blockage is avoided by requesting WebSockets on port 80 or 443. It suggests either a reverse proxy in front of your sync web stack or two separate machines, and links to its server configuration docs.

### Is Ratchet still maintained?

The README has a section titled "Reviving Ratchet!" stating the maintainers aim to get it up to date with the latest versions and asking for help through ticket #1054. The most recent tagged release is v0.4.4 from 2021-12-14, and the last push to the 0.4.x branch was on 2026-06-14.

## Sources

- [License: MIT](https://github.com/ratchetphp/Ratchet/blob/0.4.x/LICENSE)
- [Project website](http://socketo.me)
- [ratchetphp/Ratchet on GitHub](https://github.com/ratchetphp/Ratchet)
- [README](https://github.com/ratchetphp/Ratchet/blob/0.4.x/README.md)
- [Releases](https://github.com/ratchetphp/Ratchet/releases)

---

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