fasthttp: a Go HTTP stack built for thousands of small requests per second

The workload fasthttp is actually built for

The README opens with a warning rather than a pitch. fasthttp was designed for high performance edge cases, and unless a server or client needs to handle thousands of small to medium requests per second with consistent low millisecond response time, the README states that fasthttp might not be for you and that for most cases net/http is much better. That sentence sets the whole evaluation. The target user is not a team writing a first Go API. It is a team that has already measured a request-rate ceiling, or that runs a proxy, a gateway, an ad-serving endpoint, or a scraping client where a single physical server holds a very large number of concurrent keep-alive connections. The README cites VertaMedia serving up to 200K rps from more than 1.5M concurrent keep-alive connections per physical server. That is the shape of the problem: many connections, small payloads, tight latency budget. If your service spends most of its time waiting on a database, fasthttp removes an allocation cost that was never your bottleneck, and you pay for it in API friction.

Why the hot path allocates nothing

The mechanism behind the benchmark table is object reuse. The repository layout shows args.go, header.go, http.go and bytesconv.go sitting next to a dedicated allocation_test.go, and the benchmark output in the README reports 0 B/op and 0 allocs/op for the fasthttp server while the net/http server reports 21 to 36 allocations per operation depending on the case. That gap comes from fasthttp reusing request and response objects across connections instead of building a fresh net/http.Request per request. The consequence is the rule that governs every fasthttp codebase: a *fasthttp.RequestCtx and the values hanging off it are valid only for the lifetime of the handler call. You may read from them, you may write the response through them, and you must not keep a reference to them, hand them to a goroutine that outlives the handler, or store them in a map. Copies are cheap and expected. The same pooling logic applies on the client side, where fasthttp reports up to 4 times the throughput of net/http. The README also notes the bytebufferpool and klauspost/compress dependencies in go.mod, which is consistent with a design that borrows buffers rather than allocating them.

Installing fasthttp and serving a first request

The module path is github.com/valyala/fasthttp and the package requires Go 1.25.0 according to go.mod. Add it to an existing module with go get; the README's Install section points at the same import path used throughout the documentation.

go get github.com/valyala/fasthttp

The README links a helloworldserver example from the repository's examples directory, alongside client, fileserver, host_client, letsencrypt and multidomain examples. The README does not print the handler source itself, so read the example directory before copying anything, and note that the handler signature and the ListenAndServe call are the parts you will need to match to your own package.

The client side follows the same shape: the README documents a fasthttp client with its own request and response types, and reports it as up to 4 times faster than net/http. The pooling rule applies there too, so a request object acquired for a call is released after the response is read.

The pooling rule is also the main failure mode

The most common way to break a fasthttp service is to treat the context like a net/http.Request. Spawning a goroutine from a handler and referencing ctx inside it produces responses that are correct under light load and corrupt under production traffic, because the context has already been returned to the pool and handed to another connection. The same applies to storing ctx in a struct field, appending it to a slice, or capturing it in a closure that outlives the handler. This is not documented as a bug; it is the direct cost of the zero-allocation design, and it is why the README's advice against adopting fasthttp casually is worth taking literally. The second limitation is ecosystem shape. net/http is the interface that middleware, routers and instrumentation libraries are written against, and fasthttp defines its own request and response types. The repository ships fasthttpadaptor, which exists precisely to bridge net/http handlers into fasthttp, and fasthttputil for connection-level helpers, but anything you depend on has to be checked for a fasthttp path. If your service is mostly CRUD endpoints behind a database, fasthttp is the wrong tool: you take on the pooling discipline and the adapter layer to save allocations that were never the constraint.

How fasthttp differs from Fiber and from net/http routers

Fiber is the comparison most people reach for, and the difference is architectural rather than cosmetic. Fiber is a web framework built on top of fasthttp, so it inherits the pooling model and the performance characteristics, but it adds routing, middleware and a request-context API that borrows conventions from Express. Choosing Fiber means accepting a framework's abstractions on top of fasthttp's constraints; choosing fasthttp means you assemble routing yourself, or use one of the tools listed under the fasthttp organization. Against net/http the trade is the reverse. net/http gives you the standard library's request and response types, the entire middleware ecosystem, and an API that a new Go developer can read without a warning about object lifetimes. fasthttp gives you the benchmark table in the README, where the server is described as up to 6 times faster and the client as up to 4 times faster, at the cost of a non-standard handler signature. Against Gin or Echo, which sit on net/http, the same split applies: you keep the standard types and lose the allocation profile. The README's own framing is the honest summary. Unless you are in the thousands-of-requests-per-second case, you will not notice the difference.

Maintenance, releases and the MIT licence

fasthttp is not archived, and the last push to the master branch was on 2026-09-20, one day before this writing. Releases are frequent and versioned: v1.74.0 on 2026-09-07, v1.73.0 on 2026-07-27, and v1.72.0 on 2026-06-29. That cadence matters for upgrade cost, because a library this close to the wire format accumulates fixes in header parsing, compression and edge-case handling, and the repository carries files like header_regression_test.go and fuzz_test.go that exist to catch exactly those. The module is licensed under MIT, which permits commercial and closed-source use with the licence and copyright notice retained; this is a description of the licence text, not legal advice, and your own counsel should confirm obligations for your distribution model. The dependency set in go.mod is small and well-known: klauspost/compress, bytebufferpool, golang.org/x/crypto, golang.org/x/net and golang.org/x/sys, plus go-brrr and an indirect golang.org/x/text. A small dependency graph keeps the upgrade surface narrow, but note that go.mod declares go 1.25.0, so adopting fasthttp pins your toolchain floor to that Go release.

Editorial conclusion

Adopt fasthttp when you can point at a workload of thousands of small to medium requests per second and consistent low-millisecond latency, and when you are willing to write handlers against fasthttp's pooled request and response types instead of net/http's. Do not adopt it for a typical CRUD service, for code that depends on net/http middleware, or for anything that stores a *fasthttp.RequestCtx beyond the handler's return. Before committing, verify three things in your own code: that no handler retains a request or response object after it returns, that your routing and middleware needs are met outside the core package, and that the HTTP/2 and WebSocket paths you need are covered by the fasthttp ecosystem rather than assumed from the core module. The README's own sentence, that for most cases net/http is much better, is the boundary this package is drawn against.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. valyala/fasthttp on GitHub