reflex: the framework depends on a dev build of reflex-base

The core package has a development build as its floor

Read the dependency list and one line stands out from the rest.

reflex-base >= 0.10.2.dev0

Every other constraint in the project is a normal range, and this one is a development version used as a lower bound. So installing the published framework resolves a package tagged dev, which is not what you expect from a library you pulled from a package index. The reason is visible in the layout: this is a monorepo, with a packages/ directory, a reflex/ directory for the main package, and a separate reflex-components family in the dependency list that mirrors it. The core and its components are versioned on their own lines and published together, so the floor moves as the project develops rather than sitting at a settled release. The practical consequence is that two installs a month apart can resolve differently, and that pinning reflex alone does not pin what is underneath it.

Redis is a required dependency and the quickstart never mentions it

The dependency list runs to more than a dozen entries and redis is one of them, pinned to a range from 6.4 up to but not including 8.0. It sits alongside granian with the reload extra as the server, starlette as the HTTP layer, and python-socketio for the socket connection that carries state between browser and server. So Redis is not an optional add-on you reach for when your app grows, it is part of what the resolver installs every time. The quickstart does not mention it at all. It goes from uv init to a running app at http://localhost:3000 and stops. The dependency is the redis Python client package; the README does not say whether a running Redis server is needed. Read the dependency list as part of the install, not as an implementation detail.

The package classifies itself as a beta

The project metadata carries a development status classifier of 4, Beta, alongside the Apache Software License classifier and Python version classifiers running from 3.11 through 3.15. The declared Python range is greater than or equal to 3.11 and below 4.0. This is a small detail and it is the most honest signal in the file, because it is the project describing itself rather than a reader inferring from a version number. A 0.10.x version with a beta classifier tells you something a 0.10.x version alone does not: the framework expects its own API to keep moving, which matters if you are building something you intend to maintain rather than something you intend to demo. The Python ceiling is the other number to note, since the supported range stops before 4.0 and the classifiers enumerate specific minor versions rather than a vague recent range.

The recent release feed is publishing a build SDK, not the framework

The three most recent releases are v0.10.1, reflex-components-radix 0.10.1 and reflex-hosting-cli 0.2.1, all cut on 27 October 2026. Only the first is the reflex package itself; the other tags belong to separately versioned packages from the same repository. It is reinforced by the fact that the project's version field is declared dynamic in its build configuration, so the framework's own number is not read from a static line in the file. The consequence is that the release page mixes framework and component package tags, and the most recent push, dated 2 November 2026, tells you the code is moving while the framework's version number tells you nothing about which commit you have. If you need to know what you are running, capture it at install time.

There is no pip install on the page, only a uv quickstart

The installation section is one sentence and contains no command, and the closest thing to an instruction is a strong recommendation to use a virtual environment so that the reflex command is available in your PATH. The first app walkthrough then goes straight to uv.

mkdir my_app_name
cd my_app_name
uv init

uv add reflex
uv run reflex init
uv run reflex run

That is the entire documented path, and it points at one specific Python package manager. If you arrived expecting a pip install line, there is not one on this page. The consequence is mostly practical: uv init creates a project and uv add reflex adds the framework into it, so you get a managed project layout rather than a library dropped into an existing environment, and the reflex command is invoked through uv run rather than found on your PATH. The virtual environment warning exists for exactly the reason the layout is managed this way, since an install that lands outside the project leaves the command somewhere unexpected.

A dozen component packages each carry their own version line

The framework's user interface is not one library. The dependency list names separate packages for code, core, dataeditor, gridjs, lucide, markdown, moment, plotly, radix, react-player, recharts and sonner, and each one has its own floor, mostly at 0.10.0 or 0.10.1, with lucide at 1.1.1. Below them sits reflex-hosting-cli at a different line again. That is the monorepo structure showing up in your own dependency resolution: every one of these component packages is a required dependency of reflex, so they are installed together. The hosting client is also a required dependency of the core package rather than something you opt into, so a self hosted install still carries the hosted path's client with it.

The showcase example is welded to one vendor SDK and one model name

The example the project leads with is an image generation app, and reading it tells you what the framework's state model looks like. A class inherits from the state base, declares typed fields for the prompt, the resulting image URL and a processing flag, and its handlers are marked as events. The generate handler sets the flag, yields, awaits a call to the image endpoint, stores the result as a base64 data URL, then clears the flag. That yield is the whole idiom in one line, because it is what flushes state to the browser before the await suspends. The coupling is in the other lines. The client is constructed from the OpenAI SDK and the call names one specific model, so the flagship example needs an OpenAI account and a key, and it breaks by name if that model identifier changes. It is a good illustration of the state pattern and a poor default for a first run without credentials.

A lockfile, a Python pin, and a hash file for generated type stubs

The repository root carries the files you would expect from a project that takes its install seriously, and one you might not. There is a lockfile, a pinned Python version file, a pre-commit configuration, and a hashes file whose name ties it to type stub generation. There is also a separate debugging document and a separate MCP document in the root, so the agent integration has documentation of its own rather than a section, and directories for the editor tooling the project uses. The examples directory carries its own lint configuration (examples/ruff.toml).

Editorial conclusion

Adopt it if you want to ship a web app from a single Python codebase and accept a beta classification plus a moving multi-package dependency tree. Hold off if you need a stable API surface you can pin, or if a component version line per UI library is a constraint your environment will not take. Before you start, check two things yourself: which reflex-components version each of your needed widgets resolves to, and whether the OpenAI key the flagship example needs is something you are willing to hand a new project.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes