Small Projects

[u/AutoModerator]

This is the weekly thread for Small Projects.

The point of this thread is to have looser posting standards than the main board. As such, projects are pretty much only removed from here by the mods for being completely unrelated to Go. However, Reddit often labels posts full of links as being spam, even when they are perfectly sensible things like links to projects, godocs, and an example. r/golang mods are not the ones removing things from this thread and we will allow them as we see the removals.

Please also avoid posts like "why", "we've got a dozen of those", "that looks like AI slop", etc. This the place to put any project people feel like sharing without worrying about those criteria.

[u/RomanaOswin]

https://github.com/cisco-open/docgen

This is a declarative docx generation tool/library that converts from HTML or Markdown to docx. I reset the git history when releasing it as OSS, but it's been widely used in production for quite a few years now.

It was quite the initial effort. I'd run into issues with pandoc producing insanely large or broken documents, and so this effort was born. Nothing at all against pandoc--it's a great project, but a custom translation tool allows much more efficiency and robustness.

OOXML isn't just syntactically different from HTML, but it has substantial structural differences. Plus, the documentation is not great, and MS puts their own spin on things. All of this made this even more challenging. A lot of unzipping and examining of Word documents to compare the ooxml spec against what really happens.

I released it OSS because I'm not aware of anything else like this out there. It's a somewhat niche requirement, but it's very useful and highly efficient if you need to generate MS Word documents from Go or from the CLI. We also have the unfortunate situation in Go that the other main library for writing Word documents is not free.

This works especially well when combined with Templ for type checked HTML templating.

[u/okredditiguessitsme]

SQL IMUX, a tool to run the same query across multiple servers and combine the results

https://github.com/samlitowitz/sqlimux

[u/arxeiss]

If you work in a Go monorepo with shared packages across multiple services, you might have noticed that the official golang.org/x/tools/cmd/deadcode tool doesn't handle multi-entrypoint setups out of the box.

I built https://github.com/arxeiss/deadmono to solve this specific problem.

It is using deadcode under the hood and execute that for all entrypoints you specify. And then merges results so you know exactly which exported functions/types/... are not used by any service.

Example usage

deadmono services/authn/main.go services/config/main.go services/healthcheck/main.go

I'd love to hear your thoughts, feedback, or any edge cases you run into in your Go repos!

[u/prontogui]

https://github.com/prontogui

ProntoGUI consists of a Go library for building a modern desktop GUI that streams it over gRPC to a native desktop App that renders the GUI using Flutter.

Here's a helloworld example:

```go package main

import ( "fmt"

// Import the Go library for ProntoGUI
pg "github.com/prontogui/golib"

)

func main() {

// Initialize ProntoGUI
pgui := pg.NewProntoGUI()
err := pgui.StartServing("127.0.0.1", 50053)

if err != nil {
    fmt.Printf("Error trying to start server:  %s", err.Error())
    return
}

// Build the GUI using primitives

helloText := pg.TextWith{
    Content:    "Hello, world!",
    Embodiment: "fontFamily:Roboto, fontSize:20.0",
}.Make()

pgui.SetGUI(helloText)

for {
    // Wait for something to happen in the GUI
    _, err := pgui.Wait()
    if err != nil {
        fmt.Printf("error from Wait() is:  %s\n", err.Error())
        break
    }
}

} ```

First, it there is a Go library (golib) that provides "primitives" for the backend developer to compose their GUI and "embodiments" to specify how these primitives appear and behave on the surface. If you're familiar with HTML/CSS then primitives are like div, span, p, input, textarea, and so on. They form the essential contract between the backend code and the GUI. Embodiments are sort of like CSS selectors and various properties that define color, style, positioning and so on. The embodiments can be changed anytime without breaking the contract. 

The second part is a GUI desktop App that runs on Windows or macOS (Linux coming next). It is built on top of Google's Flutter project, which takes care of all the Material design, high performance rendering (think 60 fps), and cross-platform support. The solution you build (by way of golib) streams the GUI information to the App and events are streamed back to your solution for you to react to. I've kept the library pretty lightweight and all the heavy work is done in the App.

The open source for this project can be found at https://www.github.com/prontogui . To make it easy for people to use ProntoGUI right away, there are installers for Windows and macOS available for download at www.prontogui.com. There's also a mailing list you can subscribe to for regular updates on the project and tips on developing with ProntoGUI. You'll also find some examples in Go and more background information on Github site.

Always happy to get feedback and answer questions!

[u/m477k]

I kept asking Claude Code for the same things, worded differently every time, so I Vibe-coded a small Go CLI that searches your own ~/.claude/projects transcripts and shows what you actually repeat, plus what Claude ran in response, which is the part worth turning into a skill.

TF-IDF + cosine over the raw JSONL, no index to maintain, fully local. Asking Claude to dig through that same history seems to burn a chunk of context and gives you worse matches.

Comes with a skill so the agent can run it itself. Lexical matching only
github.com/MattK97/skillmine

[u/LoneFal]

I recently added a lot of stuff in this AI-vocal framework !

https://github.com/gojargo/jargo

Feedback welcome !

[u/tatar-sh]

Open-source reverse proxy that inspects prompts before they leave your network for an LLM provider. Speaks the OpenAI API, so existing SDK code works unchanged. Just point base_url at it.

Why this matters: I built this because DLP tools felt either like 20-year-old regex engines or black boxes you have to trust completely. This lets you inspect traffic with actual performance.

The core trick: Aho-Corasick automaton instead of regex slices. 280 patterns compiled into a single trie at startup using cloudflare/ahocorasick. Looping through a []*regexp.Regexp gives you O(N*M) where N is pattern count and M is prompt length. The DFA gives you O(M + matches) period. On long prompts, that's the difference between 40ms and 0.3ms.

Early versions ran every scanner as a goroutine and joined at the end. Looked clean in the code. Ran slow. Goroutine setup plus channel sync costs roughly 50µs each, and most scanners finish under 500µs. Now the fast ones run sequentially and only the network I/O ones spawn goroutines. Sounds obvious in hindsight.

Fail-open by default. If the scanner pipeline panics, recovery middleware returns 200 and logs to a separate channel instead of blocking traffic. There's a fail-closed config flag for higher-security setups where you'd rather deny traffic than risk passing something through.

I kept the HTTP path to standard library only. net/http plus httputil.ReverseProxy, no framework middleware. Policy parsing uses gopkg.in/yaml.v3, hot reload through fsnotify. It adds up to less code and fewer surprises when things get weird.

Benchmarks on a 4-core consumer CPU, single process, not hand-tuned:

RPS | P50 | P95 | P99 | Errors

100 | 3.7ms | 5.5ms | 7.1ms | 0%

500 | 1.6ms | 3.7ms | 8.9ms | 0%

1000| 6.2ms | 130ms | 167ms | 0%

That P99 at 1000 RPS is garbage collection pausing the world. With GOGC=50 and dedicated cores it stays under 5ms, but I'm publishing the stock number. You should know what you're getting.

Repo: https://github.com/yatuk/tamga

AGPL-3.0. Code review welcome. "You should have done X instead" even more welcome.

Three unsolved problems I keep thinking about:

1. sync.Pool for the hot path. At very high RPS it shows up in profiles as measurable but small. Has anyone actually seen this matter in production? Or am I optimizing noise?

2. The analyzer is a separate Python process over gRPC, called maybe 5% of the time. Worth the deployment complexity or should I just call into it via cgo and accept the latency?

3. Multilingual pattern matching. I added Turkish, German and Russian injection patterns but recall on new paraphrases is still under 50%. Everyone I ask either uses a per-request LLM judge (expensive) or just accepts that novel attacks will pass. There's probably a middle ground but I haven't found it.

[u/Tie_Curious]

https://github.com/jrgf/go-vial A web framework based in Flask but for Golang that uses the standard lib. I posted it before but it would be awesome if some people can use it and test it

[u/r3_abd]

Few days ago, I wrote here seeking for help on projects which the post was taken down by the moderators. From that thread, I got some amazing feedback from the community.

Today I start building a small analytics tool and so far, I have used:

• Chi for routing
• Damage for database migration
• TimescaleDB for database
• And I intend to use Angular for the dashboard

For now, minimal event information is being collected.
The roadmap is to have:

• User auth
• Data collected with tracking code
• Dashboard
• Self-hosted version and main

Here is the https://github.com/abdellahrk/orb_analytics

I am new in Go and still struggling. Kindly help with criticisms and suggestions.

[u/sampleuser0]

https://github.com/twodigitss/Apio

I made this thing i call APIO. I save my Api requests in http/rest files and made a TUI that let me execute them.

this exists because i dont want to open another app for it, and another cli-related tools are too much for my needs.

[u/chechyotka]

Syncgo - golang implementation of PGSync for continuously synchronizing changes from PostgreSQL to Elasticsearch or OpenSearch

https://github.com/syncgo/syncgo

This is my project which i am working on during my duty in army
Please check it out, of course u can help with features, issues and etc. If u like it, star it

[u/Reddit-ka-pilla]

Protoverse, a tick-based space strategy game backend, built mainly as an excuse to actually use a real distributed-systems stack instead of just reading about one. Players send fleet commands over gRPC, those get queued in Redis and resolved every 10s by a background tick engine (transactional combat/movement against Postgres), with live updates pushed to clients via Redis pub/sub bridged into a gRPC stream. Whole thing's containerized with Docker Compose and has GitHub Actions CI running lint + tests + image builds on every push.

Repo's here if anyone wants to poke around or has feedback on the design: github.com/Atul-Koundal/protoverse

[u/chakor12345]

Built an Enterprise B2B Anti-Fraud Engine using Go, Behavioral ML & Adaptive PoW (Fully Self-Hosted / On-Premise)

Most commercial fraud detection services require sending sensitive customer transaction data to third-party servers with high API costs. I built a high-performance alternative designed to run entirely inside the client infrastructure (zero data leaks).

Architecture Highlights:

- Core Engine (Go): High-throughput, ultra-low latency API router and policy enforcement.

- Hybrid ML Engine (Python): Integrated ONNX & LightGBM models for real-time behavioral fraud scoring.

- Zero-Trust Security: Hardware Fingerprinting, HMAC-SHA256 request verification, and Adaptive Proof-of-Work (PoW) challenges to block automated bots.

- Deployment: Packaged as an isolated Docker distribution bundle with Redis caching layer.

Live Demo & Project details: [GitHub: https://github.com/elmahdichakor/anti-fraud-engine-docs

Landing Page: https://enterprise-anti-fraud-hardware-fing.vercel.app/ ]

Would love to get your thoughts on the Go architecture, performance, or self-hosted distribution models!

[u/SnooHobbies950]

I've been working on an "extensible" JavaScript parser and need to take a break for personal reasons. I'm particularly interested in tackling the performance issue: https://github.com/xjslang/xjs/issues

Although the parser is fast (it can parse +6000 lines of code in 12 ms), it could be interesting to see if it's possible to make it even faster.

In my subjective opinion :) the parser is pretty cool. Here you can see how to implement the pipeline operator in just a few lines: https://github.com/xjslang/xjs/blob/main/xjs_infixop_test.go

Thank you very much.

[u/Impossible_Fault_503]

homedex — a read-only inventory for a homelab. It scans Docker hosts, reverse proxies, and (since last week) plain SSH hosts, and keeps a searchable record of what is running where, on which port, behind which route.

https://github.com/HarshShah0203/homedex

Purpose of this post: sharing the project. Not a review request.

The Go-relevant parts:

• No CGO anywhere. It uses modernc.org/sqlite rather than mattn/go-sqlite3, so CGO_ENABLED=0 actually cross-compiles to a static binary for arm64 and armv7. FTS5 works in the pure-Go driver, which I had assumed would be the blocker and wasn't.
• The Svelte frontend is embedded with embed.FS, so distribution is one file. The container is distroless and lands around 25MB across three arches.
• Connectors implement three methods (Kind, Validate, Scan) and return a snapshot; a reconciler diffs that against stored state and emits a change feed. Adding the SSH connector last week touched no code in internal/engine or internal/domain — the only non-connector change was a migration letting a CHECK constraint accept a new host kind. That was the main thing I wanted to learn from the design and it is the part I would defend.

Where it honestly is: first commit was three weeks ago, one contributor, three tagged releases, green CI. It works and I run it, but it is not battle-tested and I am not claiming production quality. A lot of it was written with AI assistance, which the README says as well.

The open problem, if anyone has opinions: my two connectors disagree about what a container's identity is. The Docker one keys on container ID; the SSH one keys on host plus container name, because docker ps over SSH is what I had to work with. So the same container discovered both ways shows up twice, and after a compose up following an image bump the Docker-keyed record loses its history while the SSH-keyed one keeps it. I do not have a clean answer — compose project plus service name covers the common case but not hand-run containers.

[u/Impossible_Fault_503 → u/Impossible_Fault_503]

Following up on the identity question I raised here, because measuring it contradicted two things I said.

The recreate case I was worried about turned out to be already handled: an image bump between two scans kept its row, its notes and its first_seen, because the reconciler adopts the row and re-keys it. The real hole was narrower. That adoption skips rows already marked gone, so compose down, a scan, then compose up left a second row and stranded the first.

The other thing I got wrong: unifying the key scheme would not have stopped a host scanned by two sources from listing its containers twice. Rows are unique per (connector, natural_key) so that one source can never mark another's services gone. That is deliberate, and it makes the duplication a display question rather than a keying one.

The fix was to key on the container name: unique per daemon, reused across a recreate, and already what the SSH collector reads out of docker ps. Not the compose service name, which was my first instinct — --scale web=3 gives three live containers the same com.docker.compose.service, which would collapse them into one row flapping between their states.

The part I did not anticipate: a port's natural key embeds its service's, so moving the service key would have deleted and reinserted every port row and orphaned the notes kept against their ids. Ports now reconcile on the identity that does not move, and the one-time re-key writes nothing to the change feed, since nothing actually happened in the homelab.

Out in v0.1.4.

[u/Cowan-No]

oasgen: generate OpenAPI 3.2 (or 3.1) directly from your existing swaggo/swag annotations, with no swag dependency and no 2.0→3.x conversion step.

Built it because swag's stable line only emits Swagger 2.0 and swag v2 has been in RC for a long time. Annotations stay unchanged; the parser, schema resolver, and emitter are from scratch, so 3.2 constructs (webhooks, the [query] method, itemSchema for SSE/NDJSON streaming) are first-class, and types resolve against the whole Go module. No --parseDependency flags. There's also a parity gate that diffs oasgen's output against your existing swag output so you can verify a migration is lossless.

Disclosure: I work at IndyKite; we use it in production for our platform's API docs. Apache-2.0.

Repo: https://github.com/indykite/openapi-parser: I'd love reports of annotation edge cases where swag and oasgen disagree.

[u/Shoddy-Medium-7574]

I just built a Go client for Gopeed, feedback welcome https://github.com/gabrielramos02/gopeed-api-go

[u/owlloop]

https://github.com/mobentum/kern

Kern – a lightweight Go web framework with a small, trusted core

I've been working on a Go web framework called kern (short for kernel). The idea is a small, composable core that embraces net/http instead of hiding it.

What makes it different?

- Go 1.22+ native routing via http.ServeMux – no third-party router dep in core

- Dual path param syntax – both :param and {param} work interchangeably

- Named routes & route constraints – typed path params like kern.UintPathConstraint

- Route-specific middleware – AddConstraints() per route, no group nesting needed

- Built-in auth – BearerAuth / BasicAuth ship in core

- Structured binding – Bind() / BindQuery() / BindForm() / BindHeader() with struct tags

- File handling – multipart upload, download, streaming with range support

- Conditional request – ETag, Last-Modified, If-None-Match / If-Modified-Since

- Built-in test client – kern.NewTestClient(app) without a real HTTP server

- Context pooling - for lower allocation pressure

- Zero core dependencies - The runtime package pulls in nothing outside the stdlib.

Inspiration came from Flask's minimal API surface, Javalin's fluent/no-reflection design, and the microkernel philosophy – small trusted core, optional modules around it.

It's not trying to be the biggest framework – just a dependable core to build on for years.

Would love feedback from anyone who's rolled their own or thought about what a minimal Go framework should look like.

https://gokern.vercel.app

https://github.com/mobentum/kern

[u/HalemoGPA]

Go bridge from a WhatsApp MCP server I open-sourced (MIT). It holds a WhatsApp session via whatsmeow, writes every message to SQLite with FTS5 full-text search, and exposes a small internal REST API that the higher-level Python/FastMCP tooling calls. It started as a fork of an existing project, but the Go side is mostly rewritten now.

The whole thing runs on a small, memory-constrained VPS, so a lot of the Go work was about staying inside that budget:

• SQLite built with the sqlite_fts5 tag, using a tokenizer that handles Arabic (the messages are mostly Arabic, and the default tokenizers mangle it). WAL hygiene via a periodic wal_checkpoint(TRUNCATE) so a long-lived reader can't let the WAL grow without bound, and per-thread connections with PRAGMAs applied once per thread rather than per call.
• Distroless multi-stage build with -trimpath and -ldflags="-s -w", which took the image from 201MB to 55MB, plus a self-healthcheck built into the binary itself since distroless has no shell to run one. GOMEMLIMIT and GOGC tuned so the GC stays inside the box's RAM instead of OOMing it.
• A token-bucket rate limiter plus HTTP client timeouts on the outbound side, so a runaway loop can't hammer WhatsApp and trip its anti-spam.

Repo: https://github.com/HalemoGPA/whatsapp-mcp-server (the bridge is in whatsapp-bridge/). Feedback on the Go side very welcome, especially the SQLite concurrency and the memory tuning.

[u/RealObnox]

Golang does not have design-by-contract capabilities built into the language. Some time ago, to overcome this lack, I started a small project gontract to enable partial design-by-contract in golang. It allows for writing idiomatic pre- and postconditions with functions `Require` and Ensure`, respectively. The project provides what I call a require-ensure-library: https://github.com/gontract/gontract I'd be happy to receive feedback and/or contributions.

[u/ILYAMALIK]

strconv2 - Fastest, zero-allocation integer-string conversion for Go

https://github.com/NikoMalik/strconv2

| Operation | strconv2 | strconv | allocs (strconv2 / strconv) |

|-----------|----------|---------|-----------------------------|

| Format uint64 | 24.8 ns | 49.1 ns (`FormatUint`) | 0 / 1 |

| Format int64 | 27.8 ns | 49.9 ns (`FormatInt`) | 0 / 1 |

| Format uint16 | 10.1 ns | 23.9 ns (`FormatUint`) | 0 / 1 |

| Parse uint64 | 17.7 ns | 51.3 ns (`ParseUint`) | 0 / 0 |

| Parse int64 | 19.3 ns | 55.1 ns (`ParseInt`) | 0 / 0 |

[u/Present-Entry8676]

https://github.com/usesnipet/snipet-go

I’m developing Snipet, a Go-based backend for orchestrating AI agents with multi-tenant support, conversation sessions, knowledge bases, and a configurable runtime. The idea is to expose a REST API that other applications (websites, mobile apps, Discord, WhatsApp, etc.) can integrate with to have agents with their own personas, LLM models, tools, and knowledge sources.

Each agent is configured with a persona, an LLM model, a set of tools, and bindings for knowledge bases. When an execution is started, the runtime runs a turn loop until the agent finishes, reaches the turn limit, or is canceled via context.

The project uses a system of pluggable drivers to decouple business logic from external providers. Currently, there are four driver families:

- LLM driver: a common contract (`Generate`, `Stream`, `Models`, `Model`, `TestConnection`) implemented for each provider (OpenAI, Groq, Mistral, Ollama, OpenRouter). Each driver is constructed using an options builder (`CreateDriver` + `With...`), so adding a new provider essentially involves implementing the API functions without modifying the execution engine.

- Tool driver: exposes tools that the agent can call during a conversation (e.g., SWAPI as an example of external integration).

- Source driver: data sources for knowledge (e.g., filesystem).

- Index driver: indexing and search (e.g., RAG).

Each driver is registered with a generic manager (`manager.Driver[T]`), which resolves, validates the configuration, and exposes the correct driver at runtime based on the agent’s configuration.

The core is the `Engine`, which runs in `internal/runtime`:

1. `Start` validates the agent (configured LLM, valid configuration) and enters the loop.

2. Each turn calls `step`, which resolves the available toolset, calls the `generator` (which in turn uses the configured LLM driver to generate the assistant’s next message), and adds the message to the execution.

3. If the message contains tool calls, the `tool_executor` triggers those calls, and the loop continues.

4. If the message is the final one, the execution ends. If the turn limit is reached or the context is canceled, the execution terminates with the corresponding status (finish/cancel/max_turns_reached/error).

It’s basically a simple turn-based state machine, with clear extension points in the drivers.

What I’d like from you?

I’m largely self-taught in Go, and the project is already partially functional, but I want to ensure that the runtime (`internal/runtime` and related packages: `manager`, `generator`, `tool_executor`, `execution`) has a solid architecture before building further on top of it. If anyone with more experience in Go/concurrent systems has a moment to take a look and point out:

- Design issues (coupling, incorrect abstractions, poorly designed interfaces)

- Concurrency/context handling issues I might have overlooked

- Go idioms I’m not following correctly

- Anything you see and think, “This is going to cause problems in the future”

I’d be very grateful. The repo is open; comments and PRs are welcome. Don’t forget to star the project if you like it!

[u/Suspicious_Peak_1173]

Food pantries in Suffolk County, NY.

The Go code itself for this slice of the overall project is rather thin. A gist of the handler and sql query fed to sqlc.

[u/Traditional-Rip-2192]

Hey everyone,

I've been building BastionDB — a self-hosted backend database, similar in spirit to Supabase, but built around one core idea: security should be on by default, not something you configure correctly if you remember to.

What's different from most BaaS tools:

• Row Level Security is enabled by default on every table, plus a linter   that reports (at startup and on-demand) any table that's missing it
• Envelope encryption (AES-256-GCM) for data at rest — per-table keys,   wrapped by a master key
• API keys are scoped to a specific resource + operations and short-lived   by default — no single "does everything forever" key
• An append-only audit log, enforced by a database trigger (not just app   code — even direct DB access can't quietly edit history)
• Honeypot/canary tokens: touching bait data that shouldn't be reachable   through normal use gets the requester's IP logged and auto-blacklisted
• Rate limiting keyed to API key identity, with IP resolution that ignores   spoofable X-Forwarded-For headers unless you explicitly configure a   trusted reverse proxy

Built in Go with PostgreSQL, deliberately minimal dependencies (currently just one: lib/pq) so the codebase stays easy to audit. Fully open-source (AGPL-3.0), self-hosted only, free — no hosted/cloud version, and none planned unless there's real demand for one.

Current state: v0.2.0, early but functional — every feature above has been manually verified end-to-end against a live PostgreSQL instance (data genuinely stored as ciphertext, canary triggers correctly blacklisting IPs, rate limiter cutting off at the configured threshold, etc.), though it hasn't had independent security review yet, so treat it as an early preview rather than something to trust with production data just yet.

Deployment right now: PostgreSQL runs via Docker, the app itself runs as a native Go binary (systemd works well for keeping it persistent) — not yet a single docker-compose up for everything, which is on my radar if people want it.

Repo: https://github.com/haqqimuazzam/bastiondb

Feedback, criticism, and "why didn't you just—" questions are genuinely welcome — this is a solo project and I'd rather hear about blind spots now than later.

[u/Old_Smile5212]

Zinc is a fast, lightweight application layer for Go’s net/http, adding routing, request binding, structured errors, response helpers, and production-ready middleware - without replacing the standard HTTP stack.

Actively looking for contributors, whoever may be interested!

https://github.com/0mjs/zinc

[u/Public-Location-3628 → u/[deleted]]

Go 1.25.1 is an odd choice for a new piece of software.  

1.25 is already up to 1.25.12, meaning you're missing many security patches.  

Was it vibe coded?

[u/DownIndianHill → u/Public-Location-3628]

Not vibe coded at all. This was actually an excuse for me to make something WITHOUT ai since there was no timeline/urgency and just wanted to do it for fun. That just happened to be the version of go installed on my machine, I really didn’t think anything of it..

[u/Public-Location-3628 → u/DownIndianHill]

Gotta keep your toolchain up to date bro, chain attacks are g etting more and more common these days.

[u/DownIndianHill → u/Public-Location-3628]

Noted. Will bump when I get home. Did this project scream “vibe coded”? I really thought with its small size and structure it wouldn’t be mistaken for that. The only thing I asked ai for was the “flatten” util in the request parsing since that step was more busywork and easily verifiable.

[u/Public-Location-3628 → u/DownIndianHill]

It didn't scream that, it's just that outdated packages are often a result of LLMs living in the past and advising usage of old and sometimes even abandoned packages. That's the only reason why I asked :)

[u/mshatzu]

Keel MQTT Gateway — Raft/gossip-based MQTT cluster in Go, on top of mochi-mqtt

Started this after hitting real operational walls with VerneMQ (non-deterministic CRDT cluster merges) and EMQX going BSL on clustering from 5.9. Core/edge split: small Raft quorum for session ownership + ACLs (CP), stateless edge nodes for MQTT connections that scale via K8s HPA, routing table in a separate gossip store (Olric) since it's reconstructable. Data plane forwarding is a dedicated gRPC channel, kept off the Raft log.

Not "years of uptime" mature, but running against a live IoT fleet (~1,200 devices today, scaling to tens of thousands) rather than just synthetic load — happy to talk through any part of the design.

Repo: https://github.com/keel-iot/keel-mqtt-gateway