Robyn: a Python API over actix-web, with setup.py there only to refuse you

setup.py is three lines that reject the old install command

The most direct thing in the repository is a setup.py that does nothing but refuse. It writes to standard error that Robyn does not support installation with `python setup.py install`, tells you to use pip instead, and exits with a non-zero status:

import sys

sys.stderr.write(
    """
==============================
Unsupported installation method
==============================
robyn doesn't support installation with `python setup.py install`.
Please use `python -m pip install .` instead.
"""
)
sys.exit(1)

So there is a legacy entry point that exists only to fail loudly. That is a small courtesy most projects skip, and it saves a class of broken virtual environments where a half-finished build leaves you importing something that does not work. The real build path is declared in the project manifest, which uses the maturin build backend, so the wheel is produced from the Rust source rather than from Python packaging alone.

The Rust release profile aborts on panic, so errors do not unwind into Python

The dependency list in the Rust manifest tells you the architecture. The Python extension is built with PyO3 configured as an extension module with Python object cloning, the async runtime comes from the PyO3 async runtimes on top of tokio, and the server underneath is the actix family with its web, actors, HTTP, file and multipart crates. Routing is a separate router library, and there is a Python serialisation crate for bridging values across the boundary. The release profile then does three things that matter operationally: single codegen unit, fat link time optimisation, and `panic = "abort"`. That last one is the interesting choice, because an abort ends the process rather than unwinding, so a fault in the Rust layer is not an exception your Python handler can catch. If you are reaching for this framework for its speed, that is part of the bargain.

Two optional features, and an event loop that silently disappears on some platforms

The install is short, and so is the optional surface:

pip install robyn

There is also a conda-forge channel, and an extras group that pulls in the two optional features together, Jinja2 templating and Pydantic validation, installed as `pip install "robyn[all]"`. The base dependencies are few and oddly pinned: two of them are pinned to an exact version with no range, one is a JSON library with a bounded range, one is a process library with a very narrow range, and the filesystem watcher used for reloading is pinned to a single major series. Then there is the event loop, which is conditional on the platform, the interpreter implementation and the machine architecture: it is installed only off Windows, only on CPython, and not on 32-bit ARM. So the dependency set is not identical everywhere, which is a good reason to keep a lockfile rather than resolve freely.

Building the extension needs Rust, a C compiler and sometimes patchelf

The local development section is the most honest part of the README, because it tells you the full toolchain. You need Python in the supported range, Rust on latest stable, and a C compiler, then you install three build tools, install the development and test dependency groups, install the git hooks, and build the extension with maturin. There is a second build command for the experimental io-uring path, which is enabled by a cargo feature flag rather than by a separate package. The troubleshooting notes name two failure modes you will probably meet: maturin reporting that patchelf is missing, which they attribute especially to Arch Linux, and Rust compilation errors caused by a missing C compiler, with a per-distribution command for the common Linux families and the usual advice about build tools on macOS and Windows. So contributing to this project means maintaining a Rust and Python build, not editing Python alone.

Processes, workers and reload are command line flags, not configuration

The README exposes the runtime model through CLI flags. The usage output lists a process count and a worker count, both defaulting to one, a development flag that restarts the server when files change, a log level accepting four names, a flag to scaffold a new project template, and a flag to open a browser at the application location. The application itself is small enough to read in full: a framework object constructed with the file, a route decorator on an async function, and a start call with a port. That is the whole getting-started path.

Alpha status, three minors in nine days, and a version that matches the tag

The release list tells you how this project moves. Version 0.88.0, published 2026-06-25, is titled for sessions, binary websockets and templating ergonomics. Version 0.87.0 four days earlier is titled for sub-routers, middleware chains and binary streaming. Version 0.86.0 five days before that is titled for smoother request and response ergonomics. So three feature-bearing minors landed inside nine days, and the project manifest still declares the development status as alpha while its version matches the newest tag. The last push on the main branch is dated 2026-11-02, so work continues behind those releases. The combination to plan around is an alpha classification on a fast cadence: read a changelog before upgrading rather than bumping a range, and expect to read the changelog again when a minor arrives.

The repository ships an llms.txt and examples for agents, MCP and streaming

Two things in the layout say where this project is heading. At the root there is an llms.txt, which is the convention for giving a language model a compact map of a repository, so the project is addressing tooling that reads code directly. And the examples directory contains three files that are not ordinary web routes: one for built-in agent routing and execution, one for connecting to AI applications as a Model Context Protocol server, and one for server-sent event responses. Those match the last two feature entries in the list, agent support and MCP support, sitting alongside the conventional ones such as WebSockets, dependency injection, hot reloading, automatic OpenAPI generation, static file serving, file downloads, authentication, CORS and startup and shutdown events. The consequence is that this is a framework with two audiences, web developers and agent authors, and the examples directory is where you can see which.

Editorial conclusion

Adopt it if you want an async framework that keeps its request handling in Python while the server loop lives in actix, and if a compiled extension in your dependency graph is acceptable. Do not adopt it expecting the ergonomics of a pure Python framework or a stable API, because the alpha classification and the release cadence say otherwise. Before you deploy, pin an exact version, decide whether you need the optional templating or validation extras, and remember that the README documents concurrency settings as command line flags.

Frequently asked questions

Official sources

1. License: BSD-2-Clause
2. Project website
3. README
4. Releases
5. sparckles/Robyn on GitHub