rabbitmq/amqp091-go: the RabbitMQ team's own Go AMQP 0-9-1 client

A fork with a new import path and an unguarded API

rabbitmq/amqp091-go is a Go client for AMQP 0-9-1 maintained by the RabbitMQ core team, descended from streadway/amqp, which Sean Treadway originally developed. Choosing it over the original means choosing a fork, and the fork is candid that some things differ while others have not changed at all. Package name is named as the first difference, and the remedy offered is an import alias rather than an edit to every call site:

amqp "github.com/rabbitmq/amqp091-go"

Past the rename, the fork is a real alternative rather than a copy. It retains key API elements as practically possible while explicitly dropping the "no breaking public API changes ever" rule, on the stated grounds that a good client API evolves over time. That is a trade-off worth reading before migrating: a codebase with more than a decade behind it is not a promise of a frozen surface on top.

Go channels, and the ordering they cannot give you

Protocol scope is drawn tightly by design. Negotiation for forward or backward compatibility is a non-goal, on the reasoning that 0.9.1 is stable and widely deployed, and that AMQP 1.0 is a divergent specification belonging to a different library.

Frame ordering is the sharper limit. Certain protocol events travel over Go channels, and ordering between events sent to two different channels generally cannot be guaranteed, which is why support for `basic.return` and `basic.ack` frame ordering sits in the non-goals list. The top-level tree mirrors that structure with a file per moving part: `confirms.go`, `return.go`, `consumers.go`, `delivery.go`, `channel.go`. If your design depends on learning that a message was returned before acting on its confirmation, this client will not sequence those events for you, and the README does not document a workaround.

Authentication stops at PLAIN and EXTERNAL on purpose

Anything other than PLAIN and EXTERNAL authentication is listed as unsupported, and the stated reason is structural rather than ideological: keeping the mechanisms interface modular makes it possible to extend outside of this package, and if other mechanisms prove popular the project says it would accept patches to fold them in. `auth.go` and `auth_test.go` are the only authentication files at the top level, so a broker that requires a different mechanism needs a wrapper outside this module rather than a switch flipped in your service.

Transport configuration is split the same way. `uri.go` handles connection URIs, `certs.sh` sits beside `tls_test.go` for certificate work, and the top-level listing includes a `rabbitmq-confs/` directory the README never describes, so what those configuration files hold cannot be established from the repository documentation.

Bringing up a broker and the tagged test suite from the Makefile

There is no install command in the README; the import path above is the whole installation story, and `go.mod` names the module `github.com/rabbitmq/amqp091-go` at `go 1.20` with a single requirement, `go.uber.org/goleak v1.3.0`. For a first real use, the repository's own Makefile is the guide, and its default goal is list, which prints every target carrying a double-hash comment.

Starting a broker locally is one target:

docker run --detach --rm --name $(CONTAINER_NAME) \
		--publish 5672:5672 --publish 15672:15672 \
		--pull always rabbitmq:4-management

That is what the rabbitmq-server target runs, with `CONTAINER_NAME` defaulting to `amqp091-go-rabbitmq`, and it publishes the AMQP port 5672 alongside the management port 15672 from a `rabbitmq:4-management` image. The suite then expects a server to be listening:

go test -race -v -tags integration $(GO_TEST_FLAGS)

That is the tests target, which the Makefile says requires a running rabbitmq-server and takes extra flags through `GO_TEST_FLAGS`. To skip the manual step, the tests-docker target chains the broker and the suite, handing the broker a control path:

RABBITMQ_RABBITMQCTL_PATH="DOCKER:$(CONTAINER_NAME)" go test -race -v -tags integration $(GO_TEST_FLAGS)

It shuts the container down again with the stop-rabbitmq-server target.

go.mod says go 1.20, the README says two Go series

Two toolchain statements in this repository do not agree, and the gap shows up at build time. The README says the client supports two most recent Go series. `go.mod` declares `go 1.20`. Read together they hand you a far older toolchain floor than the prose states, since the module is still selected by toolchains well outside those two series, and nothing in the repository documents which Go versions CI actually exercises.

Broker support is stated with similar looseness. The project supports RabbitMQ versions starting with 2.0 but is primarily tested against the currently supported broker series, and the README warns that some features and behaviours may be server version-specific. Client version is therefore no proxy for server behaviour: code that compiles against this package can still act differently on a broker from the older end of that range.

The wire types are generated artefacts rather than hand-kept constants, living in `spec091.go` and `spec/`, with `gen.sh` and `gen.ps1` as the generation scripts. Formatting and lint checks are Makefile targets too: `gofmt -l -d .` under check-fmt, and `golangci-lint run ./...` under checks.

Three minor versions in nine weeks inside the v1 line

Movement inside the v1 line is quick: v1.13.0 landed on 2026-07-21, v1.14.0 on 2026-08-18 and v1.15.0 on 2026-09-15. Three minor steps in nine weeks match the stated policy of accepting reasonable breaking public API changes from the community rather than holding a frozen surface, so a minor bump in this dependency is not a routine patch-level upgrade for the code that calls it.

For an adopter the consequence is concrete: exported signatures have to be re-read at each step, because the documentation set points at a Godoc API reference for the current shape of the package and no compatibility table travels with the project. A build against an older v1 line is not protected by the major version number.

Work on the tree itself is current: commits landed on 2026-10-06, so fixes to a decade-old codebase are still arriving. Contributors are asked to open pull requests on a non-main branch and to include a test or example covering the change.

GitHub reports Other, the README reports BSD 2 clause

GitHub's own metadata classifies this repository's licence as Other, a custom licence the site cannot classify, while the README states BSD 2 clause and points readers to the LICENSE file; those two statements cannot both be a precise description, and that file is the only one of the three a vendoring or compliance review can rely on. The README also says the client uses the same 2-clause BSD license as the original project, so leaving streadway/amqp does not by itself alter your obligations.

Beyond that paperwork question, the upgrade cost here is an API cost rather than a configuration one. There is almost no configuration surface to migrate: connection settings travel in the URI that `uri.go` parses, mechanisms beyond PLAIN and EXTERNAL are absent by design, and server-specific behaviour is left to the caller. What you accept is re-reading exported signatures at each version step.

Editorial conclusion

This client fits Go services that must speak AMQP 0-9-1 to a broker they already operate, and it fits them best when the team can absorb exported API movement inside the v1 line, where three minor versions arrived between 2026-07-21 and 2026-09-15. It does not fit AMQP 1.0, authentication beyond PLAIN and EXTERNAL, or any design needing a basic.return ordered against a basic.ack. Verify first that the broker in front of you behaves the way your caller code assumes, since some behaviour is server version-specific.

Frequently asked questions

Official sources

1. Issues
2. rabbitmq/amqp091-go on GitHub
3. README
4. Releases