Vapor's README badge points at version 4 while version 5 is in beta

The documentation badge in the README points at version 4

Look at the badges rather than the prose. The documentation link in the README goes to `docs.vapor.codes/4.0/`. Not the unversioned documentation, and not a 5.0 path. The repository's own front door points at version 4 documentation while version 5 is in beta.

That is not an oversight so much as a statement of where the project is. A beta means the API is still moving, and pointing new readers at beta documentation would mean publishing tutorials against a surface that will change again before it is called stable. Pointing them at 4.0 documentation means everything they read describes software that exists and works today.

The cost falls on whoever wants version 5. There is no documentation link in this README for the beta line, so adopting it means finding the migration notes or release notes yourself, and reading them rather than following a guide. That is a real difference in effort between the two lines, and it is the main practical reason the stable line is still the default choice.

The framework itself is described in one sentence: an HTTP web framework for Swift, providing a foundation for a website, an API, or a cloud project. The site is vapor.codes and the package home is the same domain's documentation tree.

4.122.2 and 5.0.0-beta.3 are both current, and only one is finished

The three most recent releases are the whole story of where this project is. Version 4.122.3 was published on 2026-10-21. Version 5.0.0-beta.3 was published on 2026-10-01 and 5.0.0-beta.4 on 2026-10-13. The last push to the repository was on 2026-11-02, after all three.

So the stable line is being maintained while the next major version walks through its beta cycle, which is the healthiest and also the most confusing state a framework can be in. A dependency constraint that says 4 gets a maintained line with a very high minor version number and finished documentation. A constraint that says 5 gets the current API and a beta.

The minor version number is itself a signal worth reading. 4.122.3 means a hundred and twenty-two minor releases on the fourth major version, which is a project being extended and patched for a long time rather than a new one. That is a good thing for stability.

The repository is not archived and the last push was on 2026-11-02, so this is an active project in a transition, not one winding down. If you are starting something new, the decision is whether to start on a documented stable line or on a beta and absorb the churn.

The README is short, and that is a signal rather than a gap

The entire substantive description is that Vapor is an HTTP web framework for Swift, expressed as a foundation for your next website, API or cloud project, plus a link to a community collection of projects built with it, a Discord invitation, contribution instructions, a sponsor list and a long list of backers.

There is no install command, no configuration file, no routing example, and no middleware or concurrency explanation anywhere in it. That is worth being blunt about rather than filling in: the README does not document how to start a Vapor application, what its routing model is, how it handles async work, or how you deploy it.

What that tells you is where the project's centre of gravity is. The repository is where the source and the tests live, and the documentation site is where the teaching material lives. For a framework at this stage that is a normal division.

The tree supports that reading. `Sources/` holds the implementation and `Tests/` the test suite, which is a small top level for a project of this size and means most of what a reader needs is deliberately not in the repository. There is an `AGENTS.md` for tooling, which is a newer convention and suggests the project is being worked on with coding agents alongside people.

Two performance directories, and no published numbers

The repository has both a `Benchmarks/` directory and a `Performance/` directory, and no results file in either that the README points you at.

Two separate directories is the interesting part. A project that maintains both is a project that treats performance as something it watches continuously rather than asserts once.

What is absent is the published conclusion. There is no table in the README, no comparison against another framework, and no claim about throughput or latency. So if performance is your criterion, this repository will tell you the project measures it and will not tell you what it found.

The honest way to use that is to run the benchmarks yourself against the version you intend to deploy, on the hardware you intend to deploy on. Framework performance claims are unusually sensitive to both, and a number measured on a developer laptop on macOS with an arm64 processor tells you very little about a small Linux instance.

The other measurement surfaces are ordinary: a GitHub Actions test workflow, referenced by a badge, and a codecov badge, so test coverage is tracked.

NOTICES.txt and .spi.yml are the compliance surface you should check

Two small files answer questions that framework adopters ask and rarely find answered.

`NOTICES.txt` sits at the root. In a Swift package that is where third-party attribution is recorded, and its presence means the project tracks what it depends on and under what terms. For anyone shipping a Vapor application as a binary, that file and the licences of your own dependencies are what a compliance review will ask for. The framework being MIT is not the whole answer, and this file is where the rest of it starts.

`.spi.yml` is the manifest for the Swift Package Index. Its presence means the package is indexed there, which is where most Swift developers discover and read version metadata for a dependency before adding it. That is mostly good news, and it also means the version list, platform requirements and declared dependencies are public in a place your own build tooling can read rather than something you have to scrape from a repository.

`Package.swift` is the package manifest, which for Swift means the dependency graph and the platform floors are declared in code and resolved by SwiftPM rather than pinned by hand. `.swift-format` means the project formats its own source with Apple's formatter, so a contribution arrives already formatted.

None of this is exotic, and all of it is the sort of thing worth confirming exists before you depend on a framework rather than after your first compliance review.

Security reports have their own address, and ideas start on Discord

The contribution section separates three kinds of contact, and the split is a small sign of how the project is run.

A bug goes to the public issue tracker. A feature or an idea also goes to the issue tracker, or can be raised on Discord instead, which is a lighter place to propose something before committing to a written proposal. And a security vulnerability goes to `[email protected]`, with the instruction to make contact as soon as possible rather than opening a public issue.

That third channel is the one to remember. A framework sits underneath your authentication, your session handling and whatever untrusted input reaches it, so a vulnerability in the HTTP layer is a vulnerability in every application built on it. A project with a named address and an expectation of prompt contact has a disclosure process; one without does not.

The community itself is a Discord server, and the project also points at an `awesome-vapor` repository for examples of what people have built. Funding runs through GitHub Sponsors, with named sponsors including Emergetools and MacStadium, and a long list of individual backers on Open Collective. Several of the sponsors are infrastructure and hosting companies, which is a reasonable thing for a server framework's sponsor list to contain.

For an adopter, the practical summary is that this is a commercially sponsored, community-run project with a functioning disclosure path, currently between major versions.

Editorial conclusion

Vapor fits a team that has decided to write a server in Swift and wants the HTTP layer handled rather than assembled from SwiftNIO directly. It does not fit a project that needs one obvious stable version today, because the stable line and the beta line are both moving and the documentation link points at the older one. Verify first which line your dependency constraint resolves to and read the documentation for that line, not the newest tag, since the two are a major version apart in behaviour and only one of them has finished its beta cycle.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. vapor/vapor on GitHub