The Evolution of FastAPI, Part 2: A Paid Team, FastAPI Cloud, and vLLM

Part 1 traced FastAPI’s technical evolution from its creation to maturity. Part 2 tackles a more contentious question: When an open-source project grows into global infrastructure with 100,000 stars, what costs does it incur in governance and architecture?

By September 2026, FastAPI had surpassed 102,000 GitHub stars and held the top spot in the JetBrains Python Developers Survey with a 38% usage rate. It is also the default HTTP serving layer for large language model (LLM) inference servers such as vLLM.

Yet beneath those record adoption figures, FastAPI has never released a stable 1.0. Decision-making remained highly concentrated in its founder for years, and more recently, the project established a commercial company and began bundling its own cloud service into the standard installation.

This article examines changes in governance, commercial bundling, the competitive landscape, the gap between performance claims and reality, and FastAPI’s new role in the AI era. It then offers concrete versioning and architecture guidance for operations teams.

Governance and Single-Maintainer Risk: From Individual Stewardship to a Paid Team

From day one, FastAPI has been a project led by Sebastián Ramírez (tiangolo). Its historical contribution data makes that clear.

As of September 2026, of the 3,709 human-authored commits in the FastAPI repository, tiangolo alone had contributed 2,258, or 60.9%. The top five contributors together accounted for 68.0%.

The project’s open issue count on GitHub has long remained exceptionally low—usually in single digits—because community questions and feature proposals were moved entirely to GitHub Discussions early on. This approach kept the issue list tidy, but it also moved the community’s frustration into the discussion forums.

2021–2022: Community Bottlenecks and the Founder’s Account

In late 2021, frustration over stalled development came to a head. On October 1, 2021, a developer opened a GitHub discussion titled “Frustrated about the slow development of FastAPI,” pointing out that many pull requests (PRs) had gone unanswered for long periods:

Thanks a lot for what you did @tiangolo but you should find additional mainteners to help. Please!

On December 8 that year, another developer opened issue #4263, “Finding maintainers for FastAPI,” proposing a multiple-maintainer model like those used by Flask and Django. The discussion accumulated 87 reactions and 36 comments, and was not formally closed until February 2023.

Responding to criticism of slow reviews, tiangolo posted a lengthy reply on January 7, 2022, explaining his approach to quality and the standards he would not compromise:

An important reason FastAPI has succeeded is that I have handled everything myself, very carefully, doing the best I can. I can’t give that up now, at least not yet, without putting code quality at risk.

He explained that most PRs required substantial revisions from him to meet his quality standards. Sometimes, reimplementing a change would be faster than reviewing it. Still, he chose to retain the original PR and revise it incrementally, slowing throughput. Faced with a choice between consistent quality and faster merges, he explicitly chose the former.

2026: A Paid Core Team and the Distribution of Merge Authority

The turning point came after commercial funding arrived. The official FastAPI People page now lists a seven-person core team—tiangolo, YuriiMotov, svlandeg, alejsdev, patrick91, luzzodev, and Kludex—and states that most maintenance work is performed by paid team members.

 PR Processing Times (2025–2026)

 +-----------------------+
 | Team PRs (87.3%)      |  Median: 1.0 hour
 +-----------------------+
 +-----------------------+
 | Community PRs (12.7%) |  Median: 327.6 hours (~13.7 days)
 +-----------------------+

 Source: Merged PR data over 12 months (fastapi/fastapi)

Among the seven, Starlette’s primary maintainer, Kludex, has formally joined the team, and Starlette’s official repository has moved to Kludex/starlette. The primary maintainer of FastAPI’s most fundamental dependency is now a member of the FastAPI team, reducing the risk described in Part 1 as “someone else builds the foundation.”

As of September 2026, PR merge data from the previous 12 months showed a clear shift in governance: the median time from opening to merging an internal team PR was just 1.0 hour, and the number of open PRs fell to 79. However, paid team members authored 87.3% of merged PRs, and tiangolo still personally merged more than 56%.

This means “single-maintainer risk” took a different form in 2026. It is no longer a bottleneck in the founder’s personal time; it has shifted to the commercial company’s operational health and financial staying power.

Forever 0.x: ZeroVer’s Flexibility and Operational Costs

After eight years of development, FastAPI’s version number remains in the 0.x series. Its official About FastAPI Versions documentation explicitly states that, under semantic versioning conventions, every minor version change, such as 0.115 to 0.116, may include breaking changes. Only patch versions guarantee compatibility.

The community calls this versioning strategy ZeroVer: the major version stays at zero forever. For tiangolo, it preserves the freedom to restructure the architecture at any time. Removing default dependencies in 0.112.0 or dropping Pydantic v1 support in 0.126.0, for example, does not require waiting for 2.0 under semantic versioning.

For operations teams, however, the founder keeps that flexibility while passing on to users the cost of full regression testing at every upgrade.

The inference engine vLLM, for example, explicitly defines a narrow version range in its dependency file:

 fastapi[standard] >= 0.133.0, < 0.137.0

Its comments explain that 0.133.0 is the minimum version supporting Starlette 1.0. The upper bound of < 0.137.0 avoids a specific internal routing-tree change that would break the handler override mechanism used by Model Hosting Container Standards.

Commercialization: FastAPI Cloud and Venture Capital

Open-source projects that rely on unpaid individual work or sponsorship platforms struggle to sustain a full-time maintenance team. FastAPI’s turning point began with venture capital funding.

From the Sequoia Fellowship to FastAPI Labs

In 2023, Sebastián Ramírez became the first recipient of Sequoia Capital’s Open Source Fellowship. On May 5, 2025, Sequoia formally announced that it was leading the seed round for FastAPI Labs. Ramírez founded the company and serves as its CEO, with FastAPI Cloud as its core commercial product.

In its investment announcement, Sequoia cited adoption by organizations including BMW, American Express, Roche, and NASA’s Space Telescope Science Institute. It argued that while FastAPI had greatly simplified API development, cloud deployment and operations remained major obstacles for developers.

In a heartfelt post on X, Ramírez wrote that he had noticed as a child that the best technology companies were backed by Sequoia: “I never imagined that one day I myself would build a company backed by the same Sequoia.”

This commercialization path closely follows the playbook of FastAPI’s core dependency, Pydantic. In February 2023, Pydantic founder Samuel Colvin established Pydantic Services and raised a $4.7 million seed round led by Sequoia. Within two years, these two closely intertwined open-source foundations had both become commercial entities backed by the same venture capital firm.

CLI Bundling and the Default-Dependency Controversy

The most direct effect of commercialization on users shows up in changes to the framework’s standard installation.

Since 0.116.0 in July 2025, installing the officially recommended fastapi[standard] automatically includes fastapi-cloud-cli, which provides the fastapi deploy command for one-command deployment from the terminal. Developers who do not want the commercial CLI installed in their environment must explicitly specify:

pip install "fastapi[standard-no-fastapi-cloud-cli]"

The official homepage also identifies FastAPI Cloud as the project’s “primary funder and sponsor.”

FastAPI retains its permissive MIT license, and there is no indication of a planned license change. Still, with license changes occurring frequently across open source—such as HashiCorp’s switch to the Business Source License (BSL) for Terraform—the boundary between the open-source core and the commercial cloud service has become an ongoing concern for architects responsible for production operations.

The Competitive Landscape: Which FastAPI Pain Points Does Each Framework Address?

The pattern established by FastAPI—“type hints + decorator-based routing + automatic OpenAPI”—has become a standard feature set for modern Python frameworks. The competitors that followed each target specific pain points in FastAPI’s architecture.

          Python Modern Web Frameworks

 +-----------------------------------------------------+
 |                       FastAPI                       |
 |       Type-Driven API King (ASGI / Starlette)       |
 +-----------------------------------------------------+
       |                   |                   |
       v                   v                   v
 +-------------+     +-------------+     +-------------+
 | Litestar    |     | DjangoNinja |     | Robyn/Other |
 | Multi-Gov   |     | Django ORM  |     | Rust Core   |
 | Unbound Val |     | & Admin     |     | Multi-Core  |
 +-------------+     +-------------+     +-------------+

1. Litestar: Breaking Dependency Ties and Adopting Committee Governance

Litestar, originally named Starlite, published its first version on PyPI on December 6, 2021—just two days before the community opened issue #4263 seeking more maintainers. It released version 2.0 and changed its name in 2023, with a complete rewrite that removed its dependency on Starlette.

Litestar primarily addresses two pain points:

• Decoupled data validation: It does not require Pydantic. It natively supports msgspec, attrs, the standard library’s dataclasses, and TypedDict, and allows Pydantic v1 and v2 to coexist in the same project.
• Architectural extensibility: It provides a mechanism for registering standalone route functions without binding them to an app object, eliminating the circular import problems common in large projects.

2. Django Ninja: Preserving Existing Investments in Django

The Django Ninja homepage opens with an explicit acknowledgment: “This project was heavily inspired by FastAPI, developed by Sebastián Ramírez.”

The core pain point it addresses is enterprise migration cost. Many teams already have substantial Django projects. Django Ninja gives them type validation and automatic API documentation comparable to FastAPI without abandoning Django’s mature ORM, database migration tools, or admin interface.

3. WSGI’s Transition and Frameworks Built for Async Performance (Flask / Robyn)

As ASGI gained ground, established frameworks and newer frameworks bridging Python with other languages offered their own answers:

• Flask 2.0+: Although it added async def support, its underlying architecture remains WSGI, and each request still occupies a worker process. The official documentation acknowledges that this design does not increase concurrent throughput and recommends Quart for applications with substantial async requirements.
• Robyn: Its underlying asynchronous event loop is built in Rust, emphasizing very high throughput and multicore scaling in direct response to the community’s demands for faster Python execution.

Each competitor makes gains in a specific area, but none has yet displaced the ecosystem advantage FastAPI has built through comprehensive documentation, a large community, and its head start.

Performance Claims and Engineering Reality: Marketing Language and Actual Bottlenecks

One of the most famous claims on FastAPI’s official homepage is:

Fast: Very high performance, on par with NodeJS and Go (thanks to Starlette and Pydantic). One of the fastest Python frameworks available.

The “On Par with Go” Debate and the Limits of Benchmarks

This marketing claim has prompted heated community debate since 2020.

In GitHub Discussion #7320, developers cited data from TechEmpower, an HTTP framework benchmarking project: in plaintext response tests, Go’s fasthttp could reach nearly 6 million requests per second, Node.js roughly 880,000, and FastAPI around 160,000. Since FastAPI’s figure amounted to less than 3% of the Go benchmark’s throughput, they questioned whether the two were even in the same league.

FastAPI’s official Benchmarks documentation offers a measured explanation: Uvicorn is the leanest server layer, followed by Starlette. FastAPI, which adds full validation and serialization, naturally has the most computational overhead. Performance comparisons should be made against frameworks that also provide data validation and OpenAPI generation, such as NestJS, rather than against pure HTTP forwarders.

With the long-running TechEmpower repository announcing in March 2026 that it had been archived, general-purpose third-party benchmarks have gradually faded as a point of reference. Engineering attention has shifted toward practical bottlenecks at the application layer.

Three Major Performance Bottlenecks in Production

In day-to-day backend operations, the framework’s own microsecond-scale overhead rarely becomes the bottleneck. Severe performance collapses most often arise from three issues:

1. Performing synchronous blocking I/O inside async def: FastAPI dispatches ordinary def routes to an external thread pool to avoid blocking the event loop, while async def routes run directly on the main event loop. Calling a synchronous database driver or requests inside an async route can freeze the event loop completely, collapsing concurrency across the entire server.
2. I/O latency obscuring validation gains: The 0.100.0 release notes explain that database queries and third-party network requests account for most latency in real applications. Even a 20-fold improvement in Pydantic v2’s core validation speed typically translates into only a two- to three-fold improvement in end-to-end API response time.
3. JSON serialization overhead: After shedding the legacy burden of Pydantic v1 compatibility in 0.126.0, FastAPI began using Pydantic’s Rust core to serialize JSON responses directly in 0.130.0 for routes with a Pydantic return type or response model, more than doubling JSON output speed. Version 0.140.0 further optimized memory allocation for dependency injection.

A New Role in the AI and LLM Era: Inference Interfaces and an MCP Tool Hub

Amid the rapid growth of generative AI and large language models, FastAPI has unexpectedly become one of the biggest beneficiaries.

The JetBrains survey and reporting by The Register show FastAPI’s usage rate jumping from 29% to 38%. Analyst Michael Kennedy called it the “biggest winner” among Python web frameworks.

At the same time, the Python community saw a large influx of newcomers: 50% of respondents had less than two years of professional experience, and 39% had started using Python within the past two years. Kennedy suggested that these newcomers had no existing investment in Flask or Django. Combined with the many machine learning developers who needed to expose models through APIs, that made FastAPI—the most popular option—the natural choice.

The survey itself does not directly establish that AI drove this growth, but the following examples provide substantial support for that interpretation.

                 AI Workload Integration

 +--------------------------------------------------------+
 |                 OpenAI Compatible API                  |
 |                    (vLLM API Server)                   |
 +--------------------------------------------------------+
                            |
                            | from fastapi import FastAPI
                            v
 +--------------------------------------------------------+
 | FastAPI App Core                                       |
 | - StreamingResponse (SSE)   - Lifespan (Model Loading) |
 | - Depends (Auth / Limits)   - OpenAPI JSON Schema      |
 +--------------------------------------------------------+
                            |
                            | fastapi-mcp Bridge
                            v
 +--------------------------------------------------------+
 |              Model Context Protocol (MCP)              |
 |          Expose Endpoints as LLM Agent Tools           |
 +--------------------------------------------------------+

1. The Standard HTTP Gateway for Model Inference Servers

Consider the open-source inference engine vLLM. Its OpenAI-compatible API server directly uses from fastapi import FastAPI and manages startup and shutdown through lifespan. This means that when many teams deploy large language models, FastAPI forms the outermost layer of their inference service even if they have never written a line of FastAPI code. The upgrade risks of its 0.x versioning apply to them, too.

FastAPI’s modern features closely match the requirements of AI inference:

• Lifespan management: Introduced in 0.93.0, it has become the standard way to load tens of gigabytes of model weights at service startup and precisely release GPU memory at shutdown.
• Native SSE streaming support: The Server-Sent Events (SSE) mechanism added in 0.135.0, together with the streaming resource cleanup fix in 0.118.0, provides an out-of-the-box foundation for LLM token streaming.

2. The Natural Advantage of “Types as Specifications” for MCP Tool Calls

Introduced by Anthropic, the Model Context Protocol (MCP) aims to let AI agents safely call external tools. FastAPI’s design—automatically generating OpenAPI specifications from strongly typed declarations—gives it a natural advantage in the MCP ecosystem.

The community-developed fastapi-mcp extension can turn existing FastAPI routes into MCP-compliant agent tools in one step, while fully preserving their existing Depends authentication and authorization mechanisms. In the AI era, OpenAPI schemas originally prepared for frontend engineers become a common specification through which AI agents understand and call external tools.

FastAPI has also actively embraced the AI ecosystem—for example, by introducing Agents Skill in 0.133.1 and Library Skills in 0.140.0 to help AI assistants understand the framework’s syntax more accurately.

AI also adds maintenance work, however. The FastAPI People leaderboards, once used to recognize community contributors, stopped updating after large volumes of AI-generated junk contributions attempted to manipulate the rankings. They remain only as a tribute. The more popular a project becomes, the more likely it is to become a target for automatically generated PRs, leaving maintainers to bear the review costs.

Taking Stock: Practical Guidance for Operations Teams

Over eight years, FastAPI has evolved from one person’s experimental project into a critical component funded by venture capital, maintained by a paid team, and deeply embedded in AI inference infrastructure.

Five Key Indicators to Watch Over Time

1. When version 1.0 arrives: With a paid team and commercial entity in place, its willingness to commit to long-term stability under semantic versioning is the ultimate measure of governance maturity.
2. FastAPI Cloud’s profitability: The future size of the project’s full-time workforce will depend directly on revenue from its cloud business.
3. The neutrality of standard installations and documentation: Watch whether fastapi[standard] continues bundling commercial products and whether deployment documentation maintains a general-purpose, open-source stance.
4. Integration with Python 3.14’s underlying typing machinery: As PEP 649—the proposal to defer evaluation of type annotations—becomes Python’s default behavior, watch for compatibility issues in edge-case behavior of the underlying type resolution.
5. Open-source maintenance amid AI-assisted development: Faced with large volumes of automatically generated AI PRs, how will the open-source community establish effective filtering and boundaries for collaboration?

Practical Recommendations for Production Operations

For operations and DevOps engineers responsible for deploying and managing FastAPI services, this article identifies five key practices:

• Strictly pin minor-version ranges: Follow the official recommendation and always specify a minor-version range in requirements.txt or pyproject.toml, such as fastapi[standard]>=0.133.0,<0.134.0. Never allow the installed version to float freely.
• Declare installation extras explicitly: Select the required extra explicitly in CI/CD pipelines—for example, fastapi[standard-no-fastapi-cloud-cli] if you prefer a lean environment—to avoid container packaging failures caused by changes to default packages.
• Rigorously inspect async def routes for blocking calls: Add checks to code reviews and linter rules that prohibit direct calls to synchronous I/O drivers inside asynchronous functions.
• Keep one worker process per container: When deploying on Kubernetes, run a single Uvicorn worker process in each Pod’s container and leave load balancing and horizontal scaling (HPA) entirely to the Kubernetes cluster’s scheduling.
• Actively track Starlette security patches: Most FastAPI security fixes originate in the underlying Starlette layer. Track Starlette CVEs and security advisories separately for compatibility. vLLM’s dependency file has previously set a minimum version to address a Starlette CVE.

FastAPI’s story began with someone who did not want to write a framework and has led to a venture-backed company. It now faces a question every successful open-source project eventually encounters: when a project becomes large enough to serve as infrastructure, who is responsible for it, and to whom are they accountable?