# Socketify.py puts uWebSockets behind a Python API and admits it is version 0.0.31

> Socketify.py is an MIT licensed Python binding of the uNetworking/uWebSockets C core, offering HTTP, HTTPS, WebSocket, ASGI and WSGI servers with routing, pubsub and TLS 1.3, aimed at PyPy3 as much as CPython. The version number and the release dates are the first thing to weigh before you adopt it.

**cirospaciari/socketify.py** — Bringing Http/Https and WebSockets High Performance servers for PyPy3 and Python3

- Repository: https://github.com/cirospaciari/socketify.py
- Website: https://www.socketify.dev
- Stars: 1,714 · Forks: 62
- Language: Python
- License: MIT
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/cirospaciari-socketify-py

## The C core is borrowed, the API is not

Socketify.py is a binding, not a reimplementation. The README states that the full C API from uNetworking/uWebSockets was created and adapted for it, and that the same C API is used by Bun. That inheritance explains both the feature list and the shape of the Python surface.

What you get from that core is a compact event loop server with HTTP and HTTPS, WebSockets with pubsub, TLS 1.3, dynamic URL routing with wildcard and parameter support, per-SNI HTTP routers, Proxy Protocol v2, shared or dedicated compression, backpressure with maximum payload and idle timeouts, automatic ping/pong, per socket data, middlewares and template support. Mako and Jinja2 examples exist in the repository for the template layer.

The WebSocket handler is a dictionary of callbacks rather than a class hierarchy, with keys for `open`, `message`, `drain`, `close` and `subscription`. The `drain` callback exists because `ws.send` returns false when backpressure builds up, so a handler that ignores the return value silently drops into a buffered state you then have to inspect with `get_buffered_amount`.

Routing is by method and pattern, including a wildcard form, and both sync and async callables are supported, which is what lets the same app serve an ASGI app under one prefix and a lambda under another.

## ASGI and WSGI: a compatibility layer rather than a migration

The project documents both ASGI server and WSGI server support through its CLI documentation.

That is the pragmatic adoption path and also the reason to be careful. Running an existing ASGI app on an event loop library designed for handler callbacks means the performance characteristics of your framework still apply on top of the transport. The README publishes separate benchmark charts for the WSGI server and the ASGI server requests per second on Linux x64, which is at least an admission that they are not the same numbers.

The templates and middlewares features belong to the socketify-native path. The middleware examples include an async variant and a router variant, and the repository examples directory carries graceful shutdown, broadcast, backpressure, file stream, error handler, custom JSON serializer, automatic port selection and Unix domain socket examples, which is a reasonable map of what the library expects you to handle yourself in other frameworks.

## Installing means installing system libraries too

The package installs from PyPI as `socketify`:

```bash
pip install socketify
```

PyPy3 gets its own invocation, which is the interpreter the project appears to optimise for:

```bash
pypy3 -m pip install socketify
```

There is an editable install form for working on the library itself, and a requirements.txt path that just lists `socketify`.

The part that bites people is the system dependency. On Linux and macOS you may need libuv and zlib present before the package works. On macOS the README gives `brew install libuv` and `brew install zlib`. On Ubuntu and Debian it is `apt install libuv1 zlib1g`, and on RHEL and Oracle Linux, `yum install cmake zlib-devel libuv-devel`. On a container image that does not already carry them, that is an extra layer before the import works.

Supported platforms are stated as macOS on x64 and Silicon, Linux x64 and Windows. The build system requires cffi and setuptools, and requires-python is 3.8 or greater.

## Running a first app, including TLS

The hello world example imports App, registers a route, starts a listener and runs the application. The listen callback receives a config object:

```python
from socketify import App

app = App()
app.get("/", lambda res, req: res.end("Hello World socketify from Python!"))
app.listen(3000, lambda config: print("Listening on port http://localhost:%d now\n" % config.port))
app.run()
```

TLS is configured through AppOptions rather than a separate call, passing key file, certificate file and passphrase:

```python
from socketify import App, AppOptions

app = App(AppOptions(key_file_name="./misc/key.pem", cert_file_name="./misc/cert.pem", passphrase="1234"))
```

The same App then takes routes and the same listen and run pair. That is the whole shape of it: an options object at construction, routes by method, a listen callback, then run.

A WebSocket route widens the handler to the dictionary form and takes per route options, with `compression` set to `CompressOptions.SHARED_COMPRESSOR`, a 16 MB `max_payload_length`, a 12 second `idle_timeout` and one callback per event including `subscription` for the pubsub layer.

## Version 0.0.31, released in 2024, with a repository that moved in 2026

This is the part to weigh hardest. The package version is 0.0.31 in both pyproject.toml and setup.py, and the three most recent GitHub releases are v0.0.31 on 2024-10-29, v0.0.30 on 2024-10-23 and v0.0.29 on 2024-10-22. Three releases in one week, then silence on the release channel for roughly two years.

The repository is not archived and the last push was on 2026-08-17, so work continues on the default branch without producing tagged releases. For a 0.0.x project under a maintainer's own name and with a single author listed in the project metadata, that means pip gives you code from 2024 while master is somewhere else entirely.

The roadmap reinforces that the project is mid-flight. Listed as upcoming are in-memory cache tools, a libuv powered fetch API, async file IO powered by libuv, full asyncio integration with libuv, an SSGI server spec and RSGI server support, full HTTP3, HPy integration for CPython, PyPy and GraalPython, and hot reloading. There is an SSGI.md document in the repository root for the spec in progress.

The repository also carries a CLONE.md and SECURITY.md, and the fact that setup.py is mostly commented out, including a disabled Windows platform check, suggests the packaging story is still being worked on.

## Against uvicorn and hypercorn

Where Socketify.py differs is the WebSocket side. Its pubsub subscription model and per socket backpressure callbacks are part of the API surface. If your WebSocket traffic is chat, presence or fan-out, that difference can be the whole decision.

The third option is not using Python at all: Bun already speaks the same C API family, as the README itself notes. If you are choosing a runtime rather than binding to Python, that is the comparison the project invites.

The realistic risk in all of these is not throughput, it is the dependency chain. A Python binding over a vendored C library with libuv, zlib and cffi underneath is more moving parts than a pure Python or wheel-only ASGI server, and the version numbers here do not promise you a maintenance commitment for any of them.

## Conclusion

Adopt Socketify.py when you are on PyPy3, when you want WebSocket and HTTP in one process without a C toolchain of your own, and when you can accept a 0.0.x API. Do not adopt it for a team that needs a supported release line, because the published versions all date from 2024 while the last push was on 2026-08-17, so a fixed API and a moving master are not the same guarantee. Verify first by installing it on the exact platform you deploy to, because the package needs libuv and zlib present on Linux and macOS and has never declared a Windows build as supported in setup.py.

## FAQ

### How do I install socketify.py?

Install the PyPI package with pip install socketify, or use pypy3 -m pip install socketify for PyPy3. On Linux and macOS you may also need libuv and zlib installed on the system.

### What does Socketify.py support out of the box?

HTTP and HTTPS, WebSockets with pubsub, TLS 1.3, dynamic URL routing with wildcards and parameters, per-SNI routers, Proxy Protocol v2, compression, backpressure with payload and idle timeouts, automatic ping/pong, middlewares and templates. It can also serve ASGI and WSGI applications.

### How do I handle WebSocket backpressure in Socketify.py?

The send call returns false when backpressure builds up, so a handler should wait for the drain callback before sending again. The drain callback receives the socket and get_buffered_amount reports how much is buffered.

### Is Socketify.py actively released?

The repository is not archived and the last push was on 2026-08-17, but the package version is 0.0.31 and the three most recent releases are v0.0.31 from 2024-10-29, v0.0.30 from 2024-10-23 and v0.0.29 from 2024-10-22. Recent work lands on the default branch rather than as tagged releases.

## Sources

- [cirospaciari/socketify.py on GitHub](https://github.com/cirospaciari/socketify.py)
- [License: MIT](https://github.com/cirospaciari/socketify.py/blob/main/LICENSE)
- [Project website](https://www.socketify.dev)
- [README](https://github.com/cirospaciari/socketify.py/blob/main/README.md)
- [Releases](https://github.com/cirospaciari/socketify.py/releases)

---

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