Memphis.dev: a self-hosted streaming broker that Superstream no longer supports

What Memphis.dev actually removes from a backend team's queue

The pitch in the README is a claim about adoption cost, not about throughput. It states that large-scale event ingestion and processing used to take months to adopt and was reserved for the top 20% of mega-companies, and that Memphis opens the door for the other 80%. Read that literally and the product is a packaging layer: a broker plus the operational furniture that teams usually build themselves before they can ship a first consumer.

The intended user is a backend developer who needs event-driven or real-time features without standing up a Kafka cluster and writing the surrounding tooling. The README lists the furniture explicitly: a UI, CLI and SDKs; data-level observability; a dead-letter queue with automatic message retransmit; schema management; functions for real-time processing; graph visualization; storage tiering; and Kubernetes-native deployment. Each of those is a component a team would otherwise assemble from separate projects and glue code.

That framing also sets the boundary. If your team already has a streaming platform, a schema registry and a dead-letter pipeline in production, Memphis.dev is not replacing a gap. It is replacing something that works, and the README offers no migration path.

The Go control plane around NATS, and what the repository layout shows

Memphis.dev is written in Go and its dependency graph is the clearest statement of its architecture. The go.mod file requires github.com/nats-io/nats.go v1.31.0, along with nats-io/jwt/v2, nats-io/nkeys and nats-io/nuid. The Dockerfile confirms the relationship at the binary level: it builds the Go module and then copies the resulting binary into the image as /bin/nats-server, with ENTRYPOINT ["/bin/nats-server"]. The broker process in the container is the NATS server binary produced from this repository's own source.

So the data plane is NATS, and Memphis.dev is the management and developer-experience layer on top: accounts and JWT-based credentials, the HTTP surface, the schema validation, the dead-letter logic, the UI assets. The repository layout matches that reading. There are separate top-level directories for http_server, server, models, middlewares, memphis_cache, db, analytics, ui_src and ui_static_files, plus a test directory and a Jenkinsfile. The HTTP layer uses gin-gonic/gin and gin-contrib/cors. Persistence and messaging metadata touch jackc/pgx/v5 and the AWS SDK v2, including the S3 manager package, which is consistent with the storage tiering feature that the README links to documentation for.

Schema handling is not hand-rolled. The dependency list includes jhump/protoreflect for Protobuf, santhosh-tekuri/jsonschema/v5 for JSON Schema, hamba/avro/v2 for Avro and graph-gophers/graphql-go for GraphQL, which lines up with the README's Schemaverse feature covering Protobuf, JSON, GraphQL and Avro. Caching uses allegro/bigcache/v3, and there is a Kubernetes client (k8s.io/client-go, k8s.io/api, k8s.io/metrics) for the Kubernetes-native story. None of this is unusual, and that is the point: the design is a conventional Go service wrapping a proven broker, and the value is in the integration, not in novel storage engineering.

Installing Memphis.dev with Helm or Docker Compose

The README gives two installation paths. The Kubernetes path is a Helm chart hosted at k8s.memphis.dev. The command adds the repository and installs a release named my-memphis into a namespace called memphis, creating the namespace if it does not exist.

helm repo add memphis https://k8s.memphis.dev/charts/ --force-update && \
helm install my-memphis memphis/memphis --create-namespace --namespace memphis

After this runs, the chart's resources are created in the memphis namespace. The README does not document the services, ports or default credentials that the chart exposes, so the next step is to read the chart's own values rather than guess. The project points readers at docs.memphis.dev for getting-started tutorials.

The second path is Docker Compose, which downloads a compose file from the project's GitHub Pages site and starts it under the project name memphis.

curl -s https://memphisdev.github.io/memphis-docker/docker-compose.yml -o docker-compose.yml && \
docker compose -f docker-compose.yml -p memphis up

The README states this produces a production-ready message broker in under 3 minutes, which is a marketing figure rather than a measured one, and it is worth treating as such. What you can verify is that the compose file is fetched from a GitHub Pages URL, so the file is only as available as that Pages site.

For application code, the README lists SDKs for Node.JS, Go, Python, Typescript, NestJS, REST, .NET and Kotlin. It does not include a producer or consumer example in the README itself. The package.json at the repository root is an empty object, so it is not the source of the Node SDK; that lives in a separate package. The README's npm badge references memphis-dev, which is the name to look for when installing the Node client.

The support statement is the first thing to read

The top of the README carries a notice: Memphis.dev is no longer supported officially by the Superstream team (formerly Memphis.dev) and was released to the public. That sentence changes what kind of decision this is. You are not evaluating a product with a vendor behind it. You are evaluating a released codebase that you would operate yourself.

The repository is not archived, and the last push was on 2026-03-02, so there has been activity after the last tagged release. But the release list ends at v1.4.4 from 2024-05-27, and the README's key-features section is anchored to that version. Commits after a final release are not the same as a supported release line, and the README does not describe a maintenance commitment, a security response process or a deprecation policy. The repository does contain MAINTAINERS.md, CONTRIBUTING.md and CODE_OF_CONDUCT.md, so the community scaffolding exists; what is absent is a statement about who fixes what.

This is the honest trade-off. Memphis.dev is free to run and free to read, and the source is all there. In exchange, you own the upgrade path, the security patches and the bug triage. For a team that already runs its own infrastructure and treats vendor support as a nice-to-have, that is a reasonable exchange. For a team that needs a support contract to get a change approved internally, it is a blocker that no amount of feature list will clear.

Where Memphis.dev is the wrong tool

The clearest failure mode is operational, not technical. Because the README states official support has ended, an incident that requires a fix in the broker or control plane becomes your team's problem. If the bug is in the NATS layer, you have upstream NATS to work with. If it is in the Memphis-specific control plane, the schema enforcement path, the dead-letter retransmit logic or the HTTP API, there is no vendor to escalate to. That asymmetry matters when you are choosing between this and a broker whose upstream project is still releasing.

The second limitation is scope. Memphis.dev is a streaming platform, not a general-purpose queue with exactly-once semantics across arbitrary sinks, and the README does not claim otherwise. Teams that need a workflow engine, a connector ecosystem with hundreds of maintained source and sink plugins, or a managed control plane with an SLA are looking at a different category of tool.

The third is documentation depth. The README is a landing page: feature bullets, screenshots and two install commands. Concrete operational details such as the Helm chart's default resource requests, the ports the UI binds to, how to rotate credentials, how to back up metadata, and what happens during a broker upgrade are not in the README. The links point to docs.memphis.dev, and any evaluation has to go through those pages rather than the repository front page. If a feature is described in a bullet and nowhere else, treat it as unverified until you have read the corresponding documentation page.

Memphis.dev against running NATS with your own tooling

The most useful comparison is not against another streaming platform. It is against running NATS directly, because that is what Memphis.dev wraps. The Dockerfile makes the relationship concrete: the container's entrypoint is /bin/nats-server, the binary built from this repository. Underneath the Memphis UI, schemas and dead-letter handling, you are operating a NATS server.

Running NATS on its own gives you a smaller surface and a project with its own release cadence. You get the broker, its client libraries and its documentation, and nothing else. What you give up is exactly the list in the README: the web UI, the embedded schema management for Protobuf, JSON, GraphQL and Avro, the automatic dead-letter retransmit, the graph visualization and the storage tiering configuration. If your team would build those anyway, or if you have already built them, Memphis.dev is duplicated effort with an unsupported control plane on top.

If those pieces are the reason you are looking, Memphis.dev is the shorter path to a working system, and the trade is that you accept the support statement at the top of the README. The difference in approach is not about performance or protocol. It is about how much integration work you want to own versus how much maintenance risk you are willing to absorb.

Licence, upgrade cost and what the repository tells you

The repository metadata reports the licence as NOASSERTION, which means the automated classifier could not map the LICENSE file to a recognised identifier. That is not a statement about what the licence permits; it is a statement that you have to open the LICENSE file in the repository root and read it yourself. Nothing in the README describes the licence terms, and the README's own notice says the software was released to the public, which is not a licence term. Treat the licence as an open question to resolve before you deploy anything, and get your own legal read if the answer affects a commercial deployment.

Upgrade cost is the other thing the repository makes visible. The last tagged release is v1.4.4 from 2024-05-27, preceded by v1.4.3 on 2024-01-22 and v1.4.2 on 2024-01-03. There is no published cadence to plan against, and the README does not document a rollback procedure or a version compatibility matrix for the SDKs. Because the broker binary and the control plane ship from the same Go module, an upgrade moves both at once, and the SDKs listed in the README are separate packages with their own versioning. If you adopt Memphis.dev, pin the chart version and the SDK versions explicitly rather than tracking a floating tag, and keep the compose file you downloaded under version control so you are not depending on a GitHub Pages URL at deploy time.

Editorial conclusion

Adopt Memphis.dev only if you are comfortable running a codebase whose README states the Superstream team no longer supports it officially, and only for workloads where a NATS-based broker with a Go control plane, an embedded schema layer and a dead-letter queue fits. Do not adopt it if you need a vendor to escalate to, a published support contract, or a roadmap you can hold someone to; the last release in the repository is v1.4.4 from 2024-05-27. Before committing, verify three things yourself: that the Helm chart at k8s.memphis.dev/charts/ still resolves, that the Docker Compose file at memphisdev.github.io/memphis-docker/docker-compose.yml still downloads, and that the licence file in the repository root grants you the rights you need, because the repository metadata reports the licence as NOASSERTION rather than a recognised identifier.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. superstreamlabs/memphis on GitHub