DEV Community: Nicolas Keller

How we built a RabbitMQ desktop client with Electron, tRPC and SQLite

Nicolas Keller — Thu, 05 Nov 2026 14:00:11 +0000

Introduction

RabbitGUI is a desktop client for RabbitMQ that runs on macOS, Windows and Linux. It is built with Electron, and this article explains how the pieces fit together. The main process talks to RabbitMQ, exposes everything to the UI through a typed tRPC API, and stores messages in a local SQLite database. The renderer is a plain React app that never touches the network or the disk itself.

If you are building a developer tool on Electron, most of this applies to you too. None of it is specific to RabbitMQ.

Why a desktop app at all?

RabbitMQ already ships a web UI, the management plugin. We could have built another web app on top of the same HTTP API. We didn't, for three reasons:

A browser can't speak AMQP. The management HTTP API is fine for listing queues and reading stats, but the interesting features need a real AMQP 0-9-1 connection over a raw TCP socket: consuming a whole queue, spying on live traffic, republishing thousands of messages with throttling. Browsers only get TCP through WebSockets, which would need an extra plugin on the broker. A Node.js process gets TCP sockets out of the box.
No server in the middle. A hosted web app would need a backend that holds your broker credentials and can reach your private network. A desktop app connects from your machine directly to your broker, the same way your own services do. Credentials never leave your computer (more on that in how security is built into RabbitGUI).
Local storage that can handle real volumes. Debugging a dead-letter queue often means looking at tens of thousands of messages. We wanted to copy them once and then search, filter and group them as often as needed without loading the broker again. That calls for a real database on disk, not localStorage.

Electron gives us all three while keeping a single language, TypeScript, from the AMQP socket down to the React components.

The architecture in one picture

┌──────────────────────────── Electron app ────────────────────────────┐
│                                                                      │
│  Renderer process (Chromium)          Main process (Node.js)         │
│  ─────────────────────────            ──────────────────────         │
│  React 19                             tRPC router                    │
│  TanStack Router + Query   ── IPC ──▶ ├─ fetch  ──▶ Management API   │
│  tRPC client (ipcLink)     ◀───────── ├─ amqplib ─▶ AMQP 0-9-1       │
│  Monaco, React Flow,                  └─ Kysely + better-sqlite3     │
│  Recharts, Tailwind                        │                         │
│                                            ▼                         │
│                                    user-data.db (SQLite, WAL)        │
└──────────────────────────────────────────────────────────────────────┘
                                   │
                                   ▼
                         Your RabbitMQ broker(s)

The rule is simple: the renderer only renders. Anything that touches the network, the file system or a secret lives in the main process, and the renderer reaches it only through typed tRPC procedures.

The main process speaks two protocols

The management HTTP API

Most of what you see in RabbitGUI comes from the RabbitMQ management API: queues, exchanges, bindings, policies, users, vhosts and the message rate time series. In the main process it is just fetch with basic auth:

export const api = async <T>(path: string, { method = 'get', credentials, body }) => {
  const response = await fetch(credentials.baseUrl + path, {
    method,
    headers: {
      Authorization:
        'Basic ' +
        Buffer.from(`${credentials.username}:${credentials.password}`).toString('base64'),
      'Content-Type': 'application/json',
    },
    body: JSON.stringify(body),
  })

  if (!response.ok) {
    // Map RabbitMQ errors to typed tRPC errors (404 => NOT_FOUND, etc.)
  }

  return (await response.json()) as T
}

Since the request comes from Node.js and not from a web page, there is no CORS to configure on the broker. You point RabbitGUI at the same URL you would open in your browser, and it works.

The API is paginated, so the main process walks every page before returning. The renderer always receives the full list and can sort and filter it instantly:

const data = await queues(credentials, { page: 1, pageSize: 100 })

while (data.page_count > data.page) {
  const next = await queues(credentials, { page: data.page + 1, pageSize: 100 })
  data.items.push(...next.items)
  data.page = next.page
}

AMQP 0-9-1 with amqplib

The management API has a "get messages" endpoint, but the RabbitMQ docs describe it as a diagnostics tool for sysadmins: it does not implement reliable delivery and pulls messages one HTTP request at a time. For anything involving many messages we open a real AMQP connection with amqplib, still from the main process.

The live queue spy is a good example. To watch a queue without stealing messages from your consumers, RabbitGUI declares a temporary, exclusive queue and copies the bindings of the queue you are watching onto it. RabbitMQ then delivers a copy of each matching message to both queues:

const connection = await amqp.connect(amqpUrl)
const channel = await connection.createChannel()

// Server-named, exclusive, deleted when the connection closes
const { queue: tempQueue } = await channel.assertQueue('', {
  exclusive: true,
  autoDelete: true,
})

// Same bindings as the queue we are spying on
for (const binding of await queueBindings(credentials, { vhost, queue })) {
  if (binding.source) {
    await channel.bindQueue(tempQueue, binding.source, binding.routing_key, binding.arguments)
  }
}

await channel.consume(tempQueue, async (msg) => {
  if (!msg) return
  channel.ack(msg)
  await db.insertInto('consumed_messages').values(toRow(msg)).execute()
})

Because the spy queue is exclusive and auto-delete, closing the app or the connection removes it. Nothing is left behind on your broker.

The same idea powers browsing a queue without consuming it. RabbitGUI consumes the queue, writes every message to SQLite, and either requeues them or removes them, depending on the mode you pick. Requeued messages come back with the redelivered flag set, and on quorum queues with an incremented x-delivery-count. So we strip those headers and hash the body plus the remaining headers. If you extract the same queue twice, you don't get duplicates in the local database.

tRPC over Electron IPC

Electron's IPC is untyped. You ipcRenderer.invoke('some-channel', args) and hope the main process handles that string. With a few dozen features, that gets fragile fast. So we put tRPC on top of it with trpc-electron.

The main process defines ordinary tRPC routers, validated with zod:

export const queuesRouter = router({
  list: publicProcedure.input(z.string()).query(async ({ input: connexionId }) => {
    // management API + local SQLite counts
  }),
  purge: publicProcedure
    .input(z.object({ connexionId: z.string(), vhost: z.string(), queue: z.string() }))
    .mutation(async ({ input }) => {
      await purgeQueue(getCredentials(input.connexionId), { name: input.queue, vhost: input.vhost })
    }),
})

export const appRouter = router({
  connexions: connexionsRouter,
  queues: queuesRouter,
  exchanges: exchangesRouter,
  localMessages: localMessagesRouter,
  spy: spyRouter,
  // ...
})
export type AppRouter = typeof appRouter

It is wired to the window with a single call:

createIPCHandler({ router: appRouter, windows: [mainWindow] })

The preload script exposes the bridge (exposeElectronTRPC()), and the renderer creates a client with an IPC link instead of an HTTP one:

export const trpcClient = createTRPCClient<AppRouter>({
  links: [ipcLink()],
})

export const trpc = createTRPCOptionsProxy<AppRouter>({
  client: trpcClient,
  queryClient,
})

What we get out of this:

End-to-end types. The renderer imports only the AppRouter type. Renaming a procedure or changing an input breaks the renderer build, not the app at runtime.
TanStack Query for free. Every procedure becomes useQuery(trpc.queues.list.queryOptions(connexionId)), with caching, refetch intervals, loading states and invalidation after mutations. Live dashboards are just a refetchInterval.
Typed errors. The main process maps RabbitMQ failures to TRPCErrors. The renderer can, for example, skip retries on a NOT_FOUND when a queue was deleted under your feet.
No channel names to maintain. There is not a single hand-written ipcMain.handle for app features.

Long-running jobs, like extracting 50,000 messages, don't block a request. The mutation starts the job in the main process and returns. The renderer polls a status query that reports progress until the job is done.

SQLite as the local source of truth

Messages you extract, spy on or publish go into a SQLite database in Electron's userData folder. We use better-sqlite3 with Kysely as a type-safe query builder:

const sqlite = new SQLite(path.join(app.getPath('userData'), 'user-data.db'))
sqlite.pragma('journal_mode = WAL')

export const db = new Kysely<DB>({
  dialect: new SqliteDialect({ database: sqlite }),
})

Schema changes ship as Kysely migrations defined in code and run at startup with migrator.migrateToLatest(), so a user who skips a few versions still ends up with the right schema. In development, kysely-codegen regenerates the DB type from the real database after each migration. Queries stay typed without maintaining types by hand.

The main table, consumed_messages, stores the payload, the AMQP properties, and a few columns lifted out of the headers for fast filtering: delivery count, and the first and last death exchange, queue and reason from x-death. Composite indexes on (connexionId, vhost, queue, …) keep filters and facet counts fast on large extractions.

Having the messages in SQL is what makes the dead-letter workflow possible:

Filters, full-text search and facets ("how many messages per routing key or death reason?") are SQL queries, not something RabbitMQ can answer.
You can republish a hand-picked subset, to its original queue or anywhere else, with throttling.
The queue list joins live stats from the management API with local counts, so you can see which queues have messages saved on your machine.

The spy view keeps the newest 1,000 messages per queue and deletes older rows, so a busy queue can't fill your disk.

Small settings, like connections, saved table views and appearance, live in a JSON config file managed by electron-conf and not in SQLite.

The renderer: just a React app

Because everything heavy happens in the main process, the renderer is a regular single-page React app:

React 19 with TanStack Router for file-based routes, and TanStack Query through the tRPC proxy.
Tailwind CSS and Radix UI primitives for the interface.
Monaco, the editor behind VS Code, for the JSON message editor.
React Flow with elkjs for automatic layout of the routing graph of exchanges, bindings, queues and dead-letter paths.
Recharts for the message rate charts and the drain-time forecast.

There is no API base URL to configure, no auth token to refresh, no CORS. The renderer could run in a browser tab against a different link without code changes, which also makes it easy to iterate on with hot reload through electron-vite.

Building and shipping

electron-vite builds the main, preload and renderer bundles with Vite.
electron-builder packages the app for macOS (Apple Silicon and Intel, signed and notarized), Windows and Linux. Linux builds run in the electronuserland/builder Docker image.
better-sqlite3 is a native module, so it has to be compiled against Electron's Node ABI and not your system Node. electron-builder install-app-deps runs on postinstall to take care of that. It is the one part of the stack that occasionally needs attention after an Electron upgrade.
electron-updater checks for a new version a few seconds after launch and installs updates in the background.

Trade-offs we accepted

Electron isn't free. The download is bigger than a native app's, and an idle window uses more memory than a terminal tool would. For a tool you open to debug a broker, we think it's the right trade:

One language and one type system from the AMQP consumer to the button that triggers it.
Mature Node.js libraries for exactly what we need (amqplib, better-sqlite3), running in-process with no sidecar.
The same codebase and UI on macOS, Windows and Linux.

Start your own app from a boilerplate

Wiring all of this by hand takes days: the IPC bridge, native module rebuilds, migrations, code signing, notarization and auto updates. If you want the same architecture for your own desktop app, start from a boilerplate instead.

We extracted the stack behind RabbitGUI into Electron AppStack, a free, production-ready Electron + TypeScript starter. It ships with React, tRPC over IPC, SQLite, auto updates and signed releases, plus documentation for each piece:

npx degit nick-keller/electron-appstack/template my-app
cd my-app
npm install
npm run dev

You get the main process / renderer split described in this article on day one, and can spend your time on the features that make your app different.

If you are curious what this architecture adds up to in practice, RabbitGUI is available for macOS, Windows and Linux, or have a look at what it does compared to the management UI.

Originally published on the RabbitGUI blog.

A Better RabbitMQ UI: What the Management Plugin Gets Wrong

Nicolas Keller — Thu, 05 Nov 2026 13:58:29 +0000

RabbitMQ comes with a UI, and it does the job. But if you use RabbitMQ every day, the small frictions add up: logging in again for every environment, "getting" messages that you then have to requeue, typing JSON into a plain text area. This is the story of why we built RabbitGUI, a desktop RabbitMQ UI for Mac, Windows and Linux, and what we changed.

The built-in RabbitMQ UI

Yes, RabbitMQ comes with a built-in UI, the management plugin. This is what 99% of people using RabbitMQ use today. And to be frank, it is an incredibly useful piece of software. It might be old and not the most user-friendly tool you've used, but it gets the job done. It lives at http://localhost:15672 (see RabbitMQ ports for why 15672 and not 5672), and on a fresh install you log in with the RabbitMQ default login, guest / guest.

The interface is also incredibly stable. It has barely changed in a decade, and it never breaks on you as a result. If you are new to it, our complete guide to the RabbitMQ Management UI walks through every tab.

What the management plugin gets wrong

None of these are bugs. They are design choices that made sense for a web admin panel bundled with the broker, but they hurt when the UI is your daily debugging tool.

One broker per tab, one login per broker

The management UI is served by each broker. Local, staging and production are three URLs, three logins, and three tabs that look exactly the same. Sessions expire, so you log in again. Most teams end up with a folder of bookmarks and a password manager doing the work a connection list should do.

Reading a message means consuming it

There is no way to look at a message without taking it off the queue. "Get messages" consumes messages and, depending on the ack mode you pick, either requeues them (which sets the redelivered flag and can change their order) or drops them. You also read them one long list at a time, with no search and no filter. That is fine for one test message. It is painful for a dead-letter queue with 4,000 messages, and the wrong ack mode deletes data. We wrote more about this in how to browse RabbitMQ messages without consuming them.

Large payloads are truncated

The UI cuts payloads off at 50,000 characters, so big JSON documents show up incomplete (see RabbitMQ max message size).

Publishing is a text area

To send a test message you type the payload into a plain text box and the headers into key/value fields. No syntax highlighting, no validation, no formatting. One missing comma and your consumer rejects the message.

Routing is spread across pages

Bindings live on the exchange page and on the queue page. Dead-letter exchanges and alternate exchanges are hidden in arguments and policies. Names are mostly plain text, so following a message from an exchange to its queue and on to its dead-letter queue means a lot of copy, paste and filter.

No search across the broker

The list pages have a filter box, but there is no global "jump to" that finds a queue, exchange or vhost from anywhere.

Why we needed something better

When you use a tool every day, those frustrations add up. Combine that with the addiction of building tools, and the spark goes off pretty quickly. After fighting the urge to stop everything and build the tool I wished existed, I ended up writing the first lines of code for what would become RabbitGUI.

It was a tedious start, since the management HTTP API is only lightly documented, so there was a lot of reverse engineering at first. Once the first bricks were in place, I could finally focus on the experience I had in mind. If you are curious about the internals, we wrote about how we built RabbitGUI with Electron.

Our proudest improvements for RabbitGUI

Here are the features I am the most proud of, the ones that really motivated me to get RabbitGUI started. They are not just a polished version of something you could already do, but a rethink of how to get the job done much, much faster.

All your connections in a single place

This is the most common complaint about the management UI: switching environments means switching tabs and logging in again. Can you imagine doing that for database connections?

This is the welcome screen of RabbitGUI. Just like a database tool, you add as many connections as you need and never see a login screen again. Your credentials are stored encrypted on your machine, see how security is built into RabbitGUI for how encryption and offline use work.

To switch environment later, a quick access menu at the top lets you jump to any connection instantly while keeping your context.

Finally, a way to manage dead-letter queues

This could be an app of its own, given how bad the problem is. RabbitMQ has no way to explore the messages sitting in a queue, which makes dead-letter management tedious and painful.

RabbitGUI consumes the queue locally and stores the messages in a database on your machine. With every message local, you can search and filter at will, without the constraints of RabbitMQ.

Explore, search and filter messages, select the ones you are interested in, and republish only those, either to their original queue or to any queue you choose.

If you want to know more about how RabbitGUI handles dead letters, we wrote a dedicated article: dead-letter queue introspection with RabbitGUI.

Watch live traffic without touching consumers

To see what is flowing through a queue right now, RabbitGUI creates a temporary shadow queue with the same bindings and captures a copy of every message. Your consumers keep working as if nothing happened. The details are in how to spy on real-time queue traffic.

An actual JSON editor to send messages

This one is so obvious, I do not understand why the management plugin does not have it. Writing JSON by hand in a text area is painful, and the chance of making a mistake is high. For RabbitGUI, I took the editor from VS Code and put it right into the app.

We have a dedicated article that goes more in depth about publishing messages to RabbitMQ. As a bonus, it also compares it with the publish form of the management plugin.

Buttery-smooth navigation

Navigation was a big focus for RabbitGUI. I didn't see it as a single feature, but as a set of principles that make the user's life much easier.

The first thing users expect is a reliable quick search from anywhere. So we implemented the classic CMD+K to search for anything (queue, exchange, vhost...) using the same string matching and highlighting algorithm as WebStorm.

Once you can jump to anything, the next cornerstone of navigation is hopping from one entity to another by clicking on it. Anytime you see the name of an entity, whether in bindings, settings, a dead-letter exchange, an alternate exchange or a policy, you can click on it.

The last piece of the puzzle is managing routing in a single place. It builds on clickable names, but most importantly it groups bindings, dead-letter queues and alternate exchanges in one view. We wrote an entire article on exploring RabbitMQ bindings if you are curious.

Management plugin vs RabbitGUI at a glance

Task	Management plugin	RabbitGUI
Switch between brokers	New tab and login per broker	Saved connections, one click
Read messages in a queue	"Get messages", consumes then requeues or drops	Browse, search and filter locally
Replay dead letters	Shovel or a script	Select messages, republish, throttle
Watch live traffic	Not available	Spy via a temporary shadow queue
Publish a JSON message	Plain text area	VS Code editor
Find a queue or exchange	Filter box per list page	`CMD+K` from anywhere
Follow routing	Bindings split across pages	Clickable names, one routing view
Where it runs	In the broker, in your browser	Desktop app for Mac, Windows and Linux

The management plugin still wins on one thing: it is already there, on every broker, for free. RabbitGUI talks to the same management API, so you keep the plugin enabled and use whichever fits the task.

Compared with other tools

RabbitGUI is not the only alternative. If you are evaluating options, we keep sourced, side-by-side comparisons up to date:

The best RabbitMQ GUI clients, an overview of every desktop, web and CLI option
RabbitMQ Management UI alternatives
RabbitGUI vs the Management UI, feature by feature
RabbitGUI vs QueueExplorer

Wrapping up

Those are only the features we are the most proud of. RabbitGUI is built with love, and a lot of small details went into it. For backlog ETAs, see queue drain time. If you want to know what is coming next, check out our public roadmap. And if there is something you've always wanted in a RabbitMQ UI, give us some feedback to shape what we build next.

You can download RabbitGUI and connect it to your local broker in a minute.

Originally published on the RabbitGUI blog.

After 10 years of frustration, I finally built the perfect RabbitMQ IDE

Nicolas Keller — Thu, 21 Aug 2025 16:39:14 +0000

I’ve been working with RabbitMQ for about ten years now. Over that time, I’ve relied heavily on its web UI. It’s useful, but I’ve always found it frustrating to work with day to day.

Back then, many of us shared little scripts to improve the experience: adding JSON formatting, quick filters, and other small tweaks that made it a bit more practical. These scripts helped, but they always felt like band-aids.

At one point, I even proposed a redesign of the web UI on the RabbitMQ Slack. The response I got was: “don’t fix what is not broken.” Looking back, that was fair. RabbitMQ itself works as it should, and its maintainers are right to keep things stable.

So instead of trying to push changes upstream, I decided to build the tool I wished existed: a desktop IDE for RabbitMQ.

What it does

The main goal is to make working with RabbitMQ more productive and less frustrating. Here are the key features I focused on first:

Dead letter queues management: allows you to explore, search, filter, drop, and re-publish messages as needed, even in the middle of the queue
Multi-connection support: quickly switch between local, staging, and production environments.
JSON editor: both for publishing messages and displaying them.
Search across everything: queues, exchanges, vhosts, all searchable from one place.
Interactive charts: with automatic level-of-detail adjustments when zooming.
Unified routing view: Bindings, dead letters, alternate exchanges, all in a single screen.
Built-in docs and formatted inputs, no more raw, hard-to-read argument lists.

Why a desktop app?

I decided to make it a standalone app instead of another web UI. That way it can integrate better with the desktop environment, work offline, and handle multiple connections more cleanly.

It’s available for Mac (Windows comming soon) as a one-time purchase of $29. A SaaS subscription model didn’t make sense for this kind of tool.

You can check it out here.

What’s next

The roadmap is mostly driven by feedback from users and is publicly available on our roadmap page for those interested.

I’d also like to hear from other RabbitMQ users:

What’s your biggest frustration with RabbitMQ today?
What features would you like to see in tooling around it?

Your feedback would help me refine the app in next versions.

Thanks for reading, and if you’ve been hacking around the RabbitMQ web UI for years like I have, I hope this project is something you’ll find useful.