# Fastify's main branch is a v6 alpha while npm still hands you v5, and the benchmark table measures v4

> Fastify is a low overhead Node.js web framework built around JSON Schema validation, Pino logging, and an extension model of hooks, plugins, and decorators. It is well run, with a 100 percent line coverage gate and a generated validator checked into the repository, and reading it closely turns up three places where the documentation and the package have drifted apart in ways that matter before you deploy.

**fastify/fastify** — Fast and low overhead web framework, for Node.js

- Repository: https://github.com/fastify/fastify
- Website: https://www.fastify.dev
- Stars: 37,205 · Forks: 3,042
- Language: JavaScript
- License: MIT
- Published: 2026-08-17 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/fastify-fastify

## The main branch is v6, and the published package is still v5

The first thing to know is that the repository and the package are on different versions. The main branch refers to the Fastify v6 release, and the project points you to a separate 5.x branch for v5. The version in the package manifest confirms the main branch is ahead of anything you can install: it reads 6.0.0-alpha.4, a pre-release, and the recent tags are a mix of that alpha and the stable 5.12.x line. So the code you read on the default branch is not the code that `npm i fastify` gives you. That is a deliberate and defensible arrangement for a framework that maintains a stable branch, but it means any behaviour you read about in the repository has to be checked against the branch matching your installed major before you rely on it.

## listen binds to localhost, and a container needs 0.0.0.0

One note in the quick start is a security decision rather than a footnote. The listen method binds to the local host interface by default, which is 127.0.0.1 or ::1 depending on your operating system configuration. The note then says that if you are running Fastify in a container, on Docker or on a cloud platform, you may need to bind to 0.0.0.0 instead, and it warns to be careful when listening on all interfaces because it comes with inherent security risks. The reference is the Server documentation at the listen anchor. The consequence for a deployment is concrete: a container that appears to start and then refuses every connection is usually this default, and the fix is the one carrying the security warning, so it deserves a firewall or a reverse proxy in front of it rather than a shrug.

## The benchmark table measures Fastify 4.0.0, not the current release

The performance table is the most quoted part of the README and the most stale. It lists Express 4.17.3 at 14,200 requests per second, hapi 20.2.1 at 42,284, Restify 8.6.1 at 50,363, Koa 2.13.0 at 54,272, Fastify at 77,193, and the bare http.Server at 74,513. The Fastify row is version 4.0.0, and the Node row is 16.14.2. The stated method is autocannon with 100 connections for 40 seconds at 10 pipelines against localhost, run twice and taking the second average, on a machine described as an Intel Core i7 at 4Ghz with 64GB of RAM. The project is candid about what this is, calling it a synthetic hello world benchmark that aims to evaluate framework overhead, and it says the overhead each framework adds depends on your application and that you should always benchmark if performance matters.

## Publishing requires 100 percent line coverage and a clean git diff

The quality gates are visible in the manifest and they are strict. The coverage check in CI runs borp as the test runner with a line reporter and passes a check-coverage flag with a threshold of 100 lines, meaning not one uncovered line is allowed. The test script itself chains linting, the unit run, and the type tests, and a separate report variant adds a unit report step. The most interesting gate is the validator integrity check, which runs the validation build and then executes git diff --quiet, so the generated error serializer and validation code must be byte identical to what is committed. If you fork this and modify the schema compiler, you cannot publish until you rebuild and commit the output. Two smaller signals are worth noting: markdown has its own linter alongside ESLint, and linting JavaScript is separate from formatting.

## npm init fastify is three projects stacked on top of each other

The scaffolding command is thinner than it looks. Running `npm init fastify` does not generate a project itself; the README explains that it downloads and runs Fastify Create, and that Fastify Create in turn uses the generate functionality of Fastify CLI. So the template you get is the product of a separate repository and a separate CLI tool, and both can move independently of the framework. Adding it to an existing project is a single install:

```sh
npm i fastify
```

Starting from nothing, the quick start is four commands. Create a folder and make it your current working directory:

```sh
mkdir my-app
cd my-app
```

Generate a Fastify project, then install its dependencies:

```sh
npm init fastify
```

```sh
npm i
```

Start it with `npm run dev` for development or `npm start` for production. The repository also ships a Gitpod configuration, so a browser-based environment is one click away if you would rather not install Node locally.

## Schemas are compiled into functions, which is why validation is only a recommendation

The schema story is the technical centre of the framework. JSON Schema is recommended rather than required, for validating routes and for serializing outputs, and the stated reason it is fast is that Fastify compiles the schema internally into a highly performant function rather than interpreting a document at request time. That has a consequence people miss. If you skip the schema, you do not get a slower version of the same feature, you get a different code path entirely, and serialization in particular is where the payoff is, since a schema tells the framework which fields to emit instead of walking an object at runtime. The examples directory makes the pattern concrete with shared-schema.js for reusing a schema across routes, route-prefix.js for grouping, and a whole set of parsers, streams, HTTP/2, and HTTPS variants.

## The package is CommonJS with a checked-in declaration file

Look at the manifest rather than the examples and you find a detail that catches people out. The package declares type as commonjs and main as fastify.js, both sitting at the repository root next to a hand-maintained fastify.d.ts for types. The quick start examples show both module systems side by side, importing Fastify from fastify under ESM and requiring it under CommonJS, so the dual support is deliberate at the documentation level even though the package itself ships as CommonJS. The typescript-server.ts example is the reference for typed usage, and the type tests are a separate script in the test chain, which means type regressions are caught by the same command that runs the unit tests rather than by a separate type-only job.

## Encapsulation is documented as a concept, not discovered by accident

The documentation list is arranged in a way that tells you what the framework considers fundamental. Server, Routes, Encapsulation, Logging, Middleware, Hooks, Decorators, Validation and Serialization, Fluent Schema, Lifecycle, Reply, Request, Errors, and Content Type Parser are each given their own reference page. Encapsulation sitting that high in the list is the tell. The extension model is built on plugins that carry their own scope, so a hook or a decorator registered inside a plugin is visible to that plugin's routes and not to its siblings, which is a different contract from the middleware chain most Node developers arrive with. There is a Getting Started guide, a broader Guides index, and a separate official demo repository, and the project also publishes governance documents including a project charter, an expense policy, and a sponsors file.

## Conclusion

Fastify suits a team that wants low framework overhead, schema-driven validation and serialization as the default rather than an add-on, and an extension model built on plugins and encapsulation instead of a middleware chain it has to accommodate. It does not suit you if you need the current documentation to describe the code you actually installed, because main is a v6 alpha while the published package follows the stable 5.x line, and it does not give you a reason to believe the numbers in the README apply to your workload, which the project itself says. Before you adopt it, work from the 5.x branch if you want what npm installs, read the Server reference on listen before you put it in a container, and run your own benchmark rather than quoting the table.

## FAQ

### What is Fastify used for?

Fastify is a Node.js web framework for building HTTP servers and APIs. It is built around JSON Schema based validation and serialization, Pino for logging, and an extension model of hooks, plugins, and decorators, and the project describes it as inspired by Hapi and Express.

### how to install fastify

In an existing project, `npm i fastify`. For a new one, run `npm init fastify`, which downloads and runs Fastify Create using the generate functionality of Fastify CLI, then run `npm i` and start with `npm run dev` or `npm start`. Node.js 18 or newer is the practical floor for recent versions.

### Is Fastify better than Express?

The published table puts Fastify at 77,193 requests per second against Express at 14,200, measured with autocannon on an Intel Core i7. The project itself calls this a synthetic hello world benchmark aimed at framework overhead, states that the overhead depends on your application, and advises you to always benchmark if performance matters.

### how to use middleware in fastify

The documentation gives Middleware its own reference page alongside Hooks, Decorators, Encapsulation, and Lifecycle. The example files include hooks.js, plugin.js, and use-plugin.js, which show the extension points the framework expects you to reach for rather than a middleware chain.

### how to use fastify with typescript

The package ships a type declaration file, fastify.d.ts, and the repository includes an example named typescript-server.ts. Note that the package itself is CommonJS, with a main entry of fastify.js and a type field of commonjs, while the quick start shows both ESM import and CommonJS require side by side.

## Sources

- [Official documentation](https://www.fastify.dev)
- [Official README](https://github.com/fastify/fastify#readme)
- [Project repository](https://github.com/fastify/fastify)
- [Release notes](https://github.com/fastify/fastify/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/fastify-fastify