# fasthttp/websocket keeps the Gorilla protocol code alive on a faster HTTP server

> fasthttp/websocket is a WebSocket implementation for the fasthttp server, forked from the last version of gorilla/websocket and continued independently. It carries the Gorilla API and the Autobahn compliance story, but it depends on fasthttp and offers no general purpose net/http path.

**fasthttp/websocket** — WebSocket implementation for fasthttp.

- Repository: https://github.com/fasthttp/websocket
- Stars: 599 · Forks: 60
- Language: Go
- License: BSD-2-Clause
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/fasthttp-websocket

## A fork of the library everyone used, with a different server under it

The project describes itself as a Go implementation of the WebSocket protocol for fasthttp, and the lineage explains most of what follows. It is a fork of the latest version of gorilla/websocket that continues its development independently. The README even keeps the Gorilla logo image, a leftover from the fork point that tells you how direct the copy was.

That matters for anyone arriving with existing Gorilla code. The package provides what the documentation calls a complete and tested implementation of the WebSocket protocol, and states that the package API is stable. In practice that means the client, the upgrader and the connection types are the ones Gorilla users already know, and a codebase written against gorilla/websocket can mostly be repointed at this module.

The difference is what sits underneath. The module path is github.com/fasthttp/websocket, and the go.mod file requires github.com/valyala/fasthttp at v1.58.0 alongside golang.org/x/net at v0.33.0, klauspost/compress at v1.17.11 and savsgio/gotils. The fasthttp dependency is not optional, which is the whole point and also the main constraint: you are adopting a second HTTP stack along with the WebSocket code.

The repository layout shows the split cleanly. There is client.go, conn.go, server.go and the fasthttp specific server_fasthttp.go, alongside compression.go, prepared.go, proxy.go, join.go, json.go, mask.go, util.go and errors.go. The prepared.go file is the Gorilla pattern for sending a message without allocating a new frame for each one, and proxy.go is for relaying between connections.

## Protocol compliance is checked with the Autobahn suite

For a WebSocket implementation, correctness is not a matter of taste, so the project points at an external test suite. The documentation states that the WebSocket package passes the server tests in the Autobahn Test Suite, using the application in the _examples/autobahn subdirectory.

The Autobahn suite is the closest thing the WebSocket world has to a conformance suite. It exercises the framing, the fragmentation, the control frames, the close handshake and the edge cases that separate a working implementation from one that works on Chrome. Claiming the server tests pass is a specific claim, and the reference to a particular example directory means you can reproduce it rather than take it on trust.

What the documentation does not say is which Autobahn version, which test cases, or whether the pass applies to every configuration the package offers. Compression, for instance, is a separate negotiation, and the compression.go file plus the brotli dependency in go.mod suggest per-message deflate support exists alongside the standard scheme.

The practical instruction for an adopter is to run that example yourself against the build you intend to ship. The suite is a black box that speaks the protocol, so it does not care whether your server is fasthttp or net/http, and a passing run gives you evidence rather than a claim.

## Install it by module path, and pin something

Installation is the standard Go module fetch:

```bash
go get github.com/fasthttp/websocket
```

The documentation attaches a warning to that command that is worth reading in full. It says this will fetch the latest commit of the master branch, which is never purposely broken but usually not considered stable anyway. That is the maintainer telling you the default branch is a development branch.

The remedy is not spelled out in the README, but the release list makes it obvious. Tags exist at v1.5.12 from 2025-01-01, v1.5.11 from 2024-12-04 and v1.5.10 from 2024-07-04, and the module version scheme follows the usual major.minor.patch convention for a package that has not yet reached v2. Pinning a tag in your go.mod is the way to get the behaviour other people tested.

The build environment is modest by modern Go standards. The go.mod declares go 1.21 with a toolchain directive of go1.23.4, so the language floor is a year and a half behind the newest release, which is what you want from a library that other services depend on.

## Four example programs that show the intended shapes

The examples directory is where the API becomes concrete, and the documentation links four of them.

The chat example is the one most people read first, because a bidirectional text exchange is the smallest thing that exercises the connection type, the read loop and the write path together. The command example is different in kind: it is a request and a response rather than a stream, which suits a client that wants one answer per request over a persistent connection.

The client and server example, named echo, shows both ends in one place, which is the fastest way to see how the upgrader and the client dialer relate. The file watch example is the one that shows the protocol being used for something other than chat: it watches a path and pushes changes, which is a common shape for build notifications and log tailing.

The _examples directory also holds the autobahn application referenced earlier. Four examples plus the conformance runner is a small, purposeful set, and it tells you the library expects to be used for event streaming and command style calls rather than for anything exotic.

The server_fasthttp.go file at the repository root is the piece to read when you are wiring this into a fasthttp server, since it is where the handshake and the connection handoff live. There is also a server_utils.go and a server_utils_119.go pair, which by naming convention suggests build-tagged variants for different Go versions.

## Where this is the wrong tool, and what to use instead

The limitation is structural. This package only works with fasthttp. If your service already runs on net/http, the natural choice is gorilla/websocket, which this project was forked from and which speaks to the standard library server directly. That is a different amount of code in your process: fasthttp replaces the standard library's HTTP handling and brings its own connection and buffer management along with it, and that is a decision about your whole server, not just about WebSocket support.

So the comparison is not between two WebSocket libraries on equal footing. It is between adding one dependency to a net/http service, and adding a second HTTP stack plus a WebSocket implementation to a fasthttp service. The second option pays off if fasthttp was already the plan.

There is a second consideration about the fork itself. This project is a fork of the latest version of gorilla/websocket that continues its development independently. That is a reasonable thing for a maintainer to do, and the documentation is upfront about it, but it does mean there is no upstream to send a security patch to and no large community reviewing changes. The presence of a SECURITY.md file and a GitHub Actions test workflow badge suggests the project takes that responsibility on itself.

For a project where the WebSocket code is incidental to the main service, that maintenance question is reason enough to look elsewhere. For a project where WebSocket is the product, the fork plus the Autobahn compliance is a reasonable place to be.

## BSD-2-Clause, and a release cadence that has slowed

The licence is BSD-2-Clause, the same permissive family the Gorilla code carried, and the LICENSE file sits at the repository root alongside an AUTHORS file that preserves the original contributors. BSD-2-Clause allows commercial use and redistribution with the notice intact, and it does not carry the patent grant that Apache-2.0 includes, which is the practical difference to keep in mind if you are relicensing downstream code.

Upkeep is the part to look at carefully. The last push was on 2026-07-02, and the tagged releases are v1.5.12 on 2025-01-01, v1.5.11 on 2024-12-04 and v1.5.10 on 2024-07-04. The gap between the newest tag and the newest commit is more than six months, which means there are commits on master that no release has captured and that your build will pull if you follow the documented go get command.

The repository is not archived, and there is a CI workflow that runs tests on the master branch, so the code is being checked. But a project whose releases stopped in early 2025 while commits continued into mid 2026 is a project where you are effectively tracking master whether you meant to or not.

The version number itself has stayed at 1.5.x, so there has been no breaking API change since the fork. That is a genuine benefit of the fork approach: the code did not have to diverge from what Gorilla users knew.

## Conclusion

fasthttp/websocket suits a team that has already committed to fasthttp for its HTTP throughput and now needs a long-lived WebSocket connection on the same server, and that is comfortable maintaining a fork of a formerly canonical library. It is the wrong choice for a service built on net/http, where gorilla/websocket or another standard library path fits without a second HTTP stack, and the wrong choice if you want a dependency with an active upstream rather than an independent continuation. Before adopting it, run the Autobahn application in _examples/autobahn against your own build, and pin a tagged release rather than the master branch, since go get github.com/fasthttp/websocket pulls the latest master commit by default.

## FAQ

### How do I install the fasthttp WebSocket package?

Run go get github.com/fasthttp/websocket. The documentation warns that this fetches the latest commit of the master branch, which is never purposely broken but usually not considered stable, so pinning a tagged release such as v1.5.12 is the safer choice.

### Is fasthttp/websocket a fork of gorilla/websocket?

Yes. The documentation states it is a fork of the latest version of gorilla/websocket that continues its development independently, and it provides a complete and tested implementation of the WebSocket protocol with a stable package API.

### How is fasthttp/websocket tested for protocol correctness?

The package passes the server tests in the Autobahn Test Suite, using the application in the _examples/autobahn subdirectory. You can run that same application against your own build to check conformance rather than relying on the claim.

## Sources

- [fasthttp/websocket on GitHub](https://github.com/fasthttp/websocket)
- [Issues](https://github.com/fasthttp/websocket/issues)
- [License: BSD-2-Clause](https://github.com/fasthttp/websocket/blob/master/LICENSE)
- [README](https://github.com/fasthttp/websocket/blob/master/README.md)
- [Releases](https://github.com/fasthttp/websocket/releases)

---

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