llama-deploy's README is a deprecation notice, and its last release shares a date with its last commit

The README body is one caution block

The entire prose content of this README is a deprecation notice. It sits under the project title, inside a caution admonition, and it says the project is deprecated and that to serve workflows you should use a different project instead. There is no install command, no usage example, no architecture description, and no feature list, which is why the repository is a twenty three word document by any count. What remains above the notice is a row of badges: one for the uv package manager, one for the package on PyPI, two for separate CI workflows, one for documentation, and one for a coverage service. The two workflow badges matter more than they look. They point at distinct unit test and end to end test workflows, which matches a tree that carries both a unit test directory and an end to end one, so the project's testing habit outlived its usefulness here.

The successor is called llama-agents and lives in workflows-py

The replacement named in the notice is llama-agents, and the link goes to a repository named workflows-py. The thing you would install and the place its source lives therefore have different names, which is the single most practical fact on the page for anyone migrating. It also explains the dependency: the runtime requirements include a workflows package from the same organisation, so llama-deploy was already built on the layer that the successor now exposes directly. The project's own metadata describes it as deploying agentic workflows to production, and that string contains a misspelling of the word workflows, which is worth knowing if you search the package index by description text rather than by name. The deprecation notice points at the successor for serving workflows, and it does not say whether the existing deployment servers keep working or stop working.

The last release and the last commit are the same day

Three releases are on record: v0.9.0 on 2025-07-18, v0.9.1 on 2025-07-29, and v0.9.2 on 2026-04-06. The first two are eleven days apart, which looks like a normal maintenance rhythm. The third is more than eight months later, and it is dated the same day as the last push to the default branch, minutes apart by the timestamps. That is the shape of a project being closed rather than one being paused: a final commit that replaces the documentation with a notice, and a tag cut alongside it so the final state is installable. The default branch was last pushed 2026-04-06, which is a hundred and seventy nine days before the present day, and the repository is not marked archived, so it remains readable and cloneable while receiving nothing.

One pydantic version is excluded and nothing explains why

The runtime dependency list is long and mostly bounded, and two entries are precise in a way the rest are not. One pins pydantic to anything except version 2.10, written as an inequality exclusion rather than a range, so every other version is permitted and exactly one is refused with no comment attached. The other pins python-multipart to a single patch series, allowing one patch release and nothing above it, on a package whose version numbers are still in a zero series. Both are the kind of constraint that exists because something broke at a specific version, and the absence of an inline note means anyone upgrading has to rediscover the reason. A third entry caps prometheus-client below 0.22 while most neighbours are open ended, which is a smaller inconsistency in the same list.

The broker clients are in both the dev group and the extras

The package declares four optional extras. Kafka pulls an asynchronous client and a second client for the same broker, RabbitMQ pulls one client, Redis pulls one client, and observability pulls the OpenTelemetry API, SDK, asyncio instrumentation and a Jaeger exporter. Those three brokers are therefore optional in the sense that a user who does not name them does not install them, which is the right shape for a deployment tool whose queueing needs vary. The same four packages, however, also appear in the development dependency group, alongside the test runner, the async test plugin, coverage, linting, type checking and pre-commit. So the test environment always has all three brokers available even though the runtime does not need them, and a test that passes against a broker client can still fail to install on a minimal runtime.

Two documentation links pointing at two versions

The same guide is linked twice in the same repository and the two links disagree. The badge in the README points at the documentation under the latest path, and the homepage recorded for the repository points at the same guide under the stable path. For a project with eight releases and no active maintenance, that difference is not cosmetic: the stable path is the copy a reader would assume is correct for an installed version, and the latest path is the copy that will keep moving. Both are on the project's own documentation site, so neither link is broken, they simply describe different versions of the same page. The tree does contain a documentation directory of its own, alongside an examples directory with five deployment targets, so the in-repository documentation and the hosted documentation are two separate surfaces maintained alongside each other.

The package summary on the index is an empty string

The packaging metadata describes this project with an empty string. Everything else in that file is filled in carefully: a name, a version matching the newest tag, two authors with named addresses, three maintainers, a readme pointer, and a Python requirement of three ten or newer with a hard ceiling below four. The missing summary is what a package index shows under the title, so a reader browsing the index sees the name and version and nothing about what the thing does, and the deprecation notice does not live in the metadata either, only in the README. The five example directories are more informative than the summary: one for a managed cloud container platform, one for a hosted inference service, one for installing dependencies into a deployment, one for a full stack application, and one quick start.

Editorial conclusion

Treat this repository as a closed project with a readable history rather than something to build on. The deprecation notice is unambiguous about where to go, and the successor is a different package in a differently named repository, so any migration is a code change rather than a version bump. Two things to check before you plan that work. What your deployment target actually needs, because the optional extras decide whether you need a broker at all: Kafka, RabbitMQ and Redis are each behind their own extra, and nothing in the core set implies a queue. And how deep your dependency pinning goes, since the runtime set carries an explicit exclusion of one pydantic version and a patch level pin on a pre-release python multipart package, and neither carries a comment explaining itself. For the record on dates: the repository is not archived, the last push and the last release were both 2026-04-06, and the release before that was eight months earlier. Read the successor's own documentation rather than this page, because this page no longer describes a supported thing.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. run-llama/llama_deploy on GitHub