DEV Community: Joffrey Mischler

I Built a Self-Hostable MQTT Dashboard in Go + React — Here's How It Works

Joffrey Mischler — Mon, 29 Jun 2026 12:19:18 +0000

If you've ever worked with IoT devices over MQTT, you know the tooling situation is... acceptable at best. MQTT Explorer is great for inspecting traffic, but it's a desktop app with no dashboard capabilities. Tools like Node-RED can do dashboards, but they're heavy, opinionated, and not exactly what you'd call a developer tool.

So I built MQTT Dashboard — a self-hostable, single-binary web app that combines an MQTT topic explorer with a fully customizable drag-and-drop dashboard. Here's why I built it, what's inside, and how you can run it in 30 seconds.

The Problem

Existing MQTT tools tend to fall into one of two buckets:

Pure clients (like MQTT Explorer, MQTT.fx): great for debugging, no persistence, no dashboards.
Full platforms (like Node-RED, Home Assistant): powerful, but heavy and not focused on the developer debugging workflow.

What I wanted was something in between — a lightweight self-hosted tool where I could connect to a broker, explore topics in real time, and build a control panel for testing my device without switching apps.

What It Does

🧩 Drag & Drop Dashboard

The dashboard is built around a grid layout engine (react-grid-layout). Panels are resizable and reorderable. You configure them per broker/topic, and the layout is persisted in SQLite so it's there when you come back.

Functional panels available:

Panel	What it does
Button	One-click publish a preset payload to a topic
Input	Type and send ad-hoc messages to any topic
Log	Live message stream with history and wildcard subscriptions
Cron	Scheduled publishing with a visual cron builder and countdown
Stats	Topic activity chart with configurable time window

Visual panels:

Panel	What it does
Image	Display an image from URL or file
Separator	Horizontal/vertical divider
Text	Markdown text for documenting your dashboard

🌳 Topic Explorer

The topic explorer lets you browse a real-time tree of all topics active on the broker. Subscriptions support + (single-level) and # (multi-level) MQTT wildcards. Message history is persistent with configurable retention.

🔌 Multi-Broker Support

You can connect to multiple MQTT brokers simultaneously and switch between them from a single interface. Each broker can be configured with:

Plain TCP or TLS/SSL
Username & password authentication
Client certificate authentication (mTLS)
QoS and retain flags

Architecture

The whole thing ships as a single Go binary that embeds the compiled React frontend. No separate web server needed.

┌──────────────────────────┐         ┌──────────────────────┐
│   React Frontend (SPA)   │◄──WS──► │    Go Backend        │
│   Vite + Tailwind +      │◄──API─► │    Single Binary     │
│   DaisyUI                │         │                      │
└──────────────────────────┘         └──────────┬───────────┘
                                                │
                                     ┌──────────┴───────────┐
                                     │                      │
                              ┌──────▼──────┐    ┌──────────▼──────────┐
                              │   SQLite    │    │  MQTT Brokers (N)   │
                              │  (layouts,  │    │  TCP / TLS / Auth   │
                              │   configs,  │    └─────────────────────┘
                              │   history)  │
                              └─────────────┘

The Go backend uses Eclipse paho.mqtt.golang for MQTT connections, SQLite for persistence, gocron for the scheduled publishing feature, and WebSockets for pushing live data to the frontend.
The React frontend is built with Vite + TypeScript + Tailwind + DaisyUI, and uses react-grid-layout for the dashboard grid.

In production, the Go binary serves the embedded React build directly — no Vite dev server in the loop. Everything runs on a single port (:8080).

Tech stack at a glance:

Layer	Technology
Frontend	React, Vite, TypeScript, Tailwind CSS, DaisyUI
Grid engine	react-grid-layout
Backend	Go (Golang)
MQTT lib	Eclipse paho.mqtt.golang
Database	SQLite (embedded)
Scheduling	gocron
Realtime	WebSocket
Container	Docker (Alpine)

Getting Started

Option 1: Docker Compose (Recommended)

services:
  mqtt-dashboard:
    image: ghcr.io/jmischler72/mqtt-dashboard:latest
    container_name: mqtt-dashboard
    ports:
      - "8080:8080"
    volumes:
      - data_volume:/app/data

volumes:
  data_volume:

docker compose up -d

Done. Open http://localhost:8080.

Option 2: Docker Command

docker run -d \
  --restart=always \
  -p 8080:8080 \
  -v mqtt-dashboard-data:/app/data \
  --name mqtt-dashboard \
  ghcr.io/jmischler72/mqtt-dashboard:latest

Option 3: Build from Source

Requirements: Go 1.22+, Node.js 20+

git clone https://github.com/jmischler72/mqtt-dashboard.git
cd mqtt-dashboard

# Build frontend
cd frontend && npm ci && npm run build && cd ..

# Build backend (embeds the compiled frontend)
cd backend
cp -r ../frontend/dist ./dist
go build -o mqtt-dashboard .
./mqtt-dashboard

What's Next

A few things I'm working on or thinking about:

Custom panels — let users build and share their own panel types
More configuration options for built-in panels

The full roadmap is in TODO.md and the docs/PRD/ folder.

Wrapping Up

This project was heavily inspired by MQTT Explorer — if you haven't used it, check it out. MQTT Dashboard tries to extend that exploration-focused experience with persistence and a customizable control interface, all packaged in a self-hostable single binary.

If you find it useful, a ⭐ on GitHub goes a long way. And if you run into bugs or have feature ideas, issues and PRs are very welcome!

Built with Go + React · GPL-3.0 · github.com/jmischler72/mqtt-dashboard

You should really use react-grid-layout, it's awesome !

Joffrey Mischler — Fri, 05 Jun 2026 11:11:15 +0000

If you do any self-hosting, home automation, or IoT projects, you know all about the MQTT protocol. It’s ultra-lightweight and robust. But on the UI side, you often end up either scripting your own custom interfaces or building dashboards by hand from scratch.

That’s exactly why I developed mqtt-dashboard, a self-hostable dashboard featuring a Go backend and a React frontend. The goal? To easily create custom panels, subscribe to MQTT topics, and display that data cleanly.

But very quickly, I hit a classic UX problem: how do I let the user organize their panels however they want? I wanted them to be able to drag, drop, and resize every single widget on the fly—true drag-and-drop—without breaking the layout or making the codebase a total nightmare to manage.

Enter React-Grid-Layout.

The Problem with Static Dashboards

At first, you think, "Easy, I'll just set up a CSS grid or use Flexbox, add some 'Move Up / Move Down' buttons, and call it a day." But in the real world, that user experience is awful. A real dashboard needs to feel alive. You want your CPU monitoring panel big and bold in the top left, and your light switch tucked away in a small corner.

Trying to build that yourself in React (handling mouse events, recalculating X/Y coordinates in pixels, managing object collisions so panels don't overlap...) is a one-way ticket to wasting three weeks of dev time just to end up with pure spaghetti code.

Why React-Grid-Layout?

React-Grid-Layout (RGL) is a grid layout library built specifically for React. It handles responsive design, drag-and-drop, and resizing natively out of the box.

What I love about this tool is how it abstracts away all the math. Instead of dealing with pixels, you think in grid coordinates (columns and rows).

Here’s a look at the core structure I used in mqtt-dashboard to display the widgets:

import RGL, { WidthProvider } from "react-grid-layout";
import "react-grid-layout/css/styles.css";
import "react-resizable/css/styles.css";

const ResponsiveReactGridLayout = WidthProvider(RGL);

function Dashboard({ widgets, onLayoutChange }) {
  // The layout defines the position and size of each panel
  const layout = widgets.map(widget => ({
    i: widget.id,      // Unique widget ID
    x: widget.x,       // X position on the grid
    y: widget.y,       // Y position on the grid
    w: widget.w,       // Width (number of columns)
    h: widget.h,       // Height (number of rows)
    minW: 2,           // Safety check so widgets don't shrink into unreadability
    minH: 2
  }));

  return (
    <ResponsiveReactGridLayout // 12-column Callback Dragging Height Standard a around className="layout" cols="{12}" draggableHandle=".widget-drag-handle" header in is layout move of onLayoutChange="{onLayoutChange}" pixels restricted row rowHeight="{50}" single split the things to when>
      {widgets.map(widget => (
        <div key={widget.id} className="widget-container">
          <div className="widget-drag-handle" aria-label="Drag handle for widget">:: Grab me</div>
          <MQTTWidgetContent topic="{widget.topic}" type="{widget.type}"/>
        </div>
      ))}
    </ResponsiveReactGridLayout>
  );
}

Pitfalls to Avoid (The Reality Check)

On paper, you import the package and bam, it works. But as usual, once you move into production, reality kicks in. If you're planning to use it, keep these things in mind:

1. The React `key` Trap

It’s written in bold in the documentation, but we all fall for it the first time: the key of the child component must perfectly match the i property in your layout object. If you use a randomly generated string or a different identifier, React-Grid-Layout loses track, the drag mechanics go crazy, and your panels start randomly teleporting across the screen.

2. Saving State (Without Spamming Your Backend)

The component provides an onLayoutChange callback. This fires every single time a panel moves even one grid unit. If you send a fetch or an HTTP request to your API for every millisecond of dragging, your backend is going to absolutely choke.

The Fix: Update your local React state immediately to keep the UI smooth, but use a debounce function before sending the final layout payload to your Go server.

3. Fighting with Widget Content

If your panel contains interactive elements like charts (Chart.js or Recharts) or text that users need to highlight, the global drag-and-drop layer can block interactions inside the widget.

The Fix: Make good use of the draggableHandle option. This restricts the dragging capability to a specific area (like a small title bar at the top of the panel), leaving the rest of the widget free for clicking buttons or scrolling.

Verdict

If you need to build a dashboard, a monitoring SaaS, or any tool where the user needs full control over their workspace, React-Grid-Layout saves you an insane amount of time. It runs smoothly, feels incredibly responsive, and when paired with a lightweight backend, gives you a genuinely dynamic app.

If you want to see exactly how I wired this up with state management, the full code is open source here: jmischler72/mqtt-dashboard. Drop by the repo, check out the code, fork it, or hit me up in the comments if you have any questions!

What are you guys using to handle dynamic grid layouts in React?

Take care, Ciao!

Just build your react frontend into your Go Backend !

Joffrey Mischler — Mon, 01 Jun 2026 13:19:37 +0000

The typical approach to full-stack web development involves two independent pieces: a frontend development server (or an Nginx instance in production) delivering your UI assets, and a separate backend server handling API requests.

That works fine for massive corporate systems, but it adds unnecessary deployment friction for lightweight applications, internal tools, or self-hosted dashboards.

While building my open-source project, MQTT Dashboard, I wanted a zero-dependency deployment flow. I wanted users to download a single file, execute it, and immediately have both the UI and backend running on port 8080.

Here is the exact setup I used to pack a Vite + React single-page application (SPA) straight into a statically linked Go binary—without sacrificing hot-reloading during local development.

1. Why would I want that?

Shipping a Single Binary

By embedding your static assets directly into your Go backend, you eliminate the need for an external web server like Nginx or a Node runtime in production. The Go binary serves the compiled JavaScript, CSS, and HTML natively out of memory. If a user wants to run your tool, they don't need to configure reverse proxies or manage frontend paths; they just run the executable.

Making the Dockerfile Simpler

This architectural choice heavily simplifies your production container deployment. Instead of orchestrating multiple containers or configuring complex multi-stage setups that copy code into separate runtime environments, your production Dockerfile drops down to a featherweight, secure layer.

You build the React app, pass the static dist/ directory to Go, compile a statically linked binary, and toss it into a raw, non-root Alpine image. The final production container drops to around 25-30MB, consumes minimal RAM, and runs effortlessly on low-power hardware like a home server or a Raspberry Pi.

💡 Bonus Advantage: Because the Go binary serves both the UI and your backend endpoints from the exact same port (:8080), you completely bypass CORS configuration headaches and WebSocket handshake path friction.

2. How to use the embed directive

Go lets you read files and folders at compilation time and bake them straight into your application binary using the standard library's native embed package.

Our directory layout looks like this:

.
├── backend/
│   ├── dist/             # Where the React production build will land
│   ├── main.go
│   └── go.mod
└── frontend/
    ├── package.json
    └── dist/             # Vite's production output

The Go Asset Layer

Inside the backend/ directory, create a file called assets.go. This acts as the bridge that reads your compiled frontend assets and exposes them to your router:

package main

import (
    "embed"
    "io/fs"
    "net/http"
)

//go:embed dist/*
var frontendAssets embed.FS

func getFrontendFileSystem() http.FileSystem {
    // Strip the "dist" prefix so files are served relative to the build root
    strippedFS, err := fs.Sub(frontendAssets, "dist")
    if err != nil {
        panic("Failed to initialize embedded filesystem: " + err.Error())
    }
    return http.FS(strippedFS)
}

Note on fs.Sub: By default, the embedded filesystem keeps the dist/ prefix in its pathing. Stripping it ensures that when a browser requests /index.html, Go maps it straight to the root instead of breaking your asset resolution.

Handling SPA Routing

If you serve static assets traditionally, hitting the refresh button on a React Router path like /dashboards/edit throws a 404 Not Found because the Go server looks for a physical directory named /dashboards/edit on disk.

To make an embedded SPA function properly, your HTTP router needs a fallback mechanism: If a requested file doesn't exist on the embedded filesystem, automatically serve index.html and let React Router handle the path rendering client-side.

package main

import (
    "errors"
    "net/http"
    "os"
)

func setupRoutes() *http.ServeMux {
    mux := http.NewServeMux()

    // 1. Register API/WebSocket endpoints first
    mux.HandleFunc("/api/v1/health", func(w http.ResponseWriter, r *http.Request) {
        w.Write([]byte(`{"status":"healthy"}`))
    })

    // 2. Setup the SPA Embedded File Server fallback
    fileServer := http.FileServer(getFrontendFileSystem())

    mux.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        fsys := getFrontendFileSystem()

        // If the file physically exists in the embedded assets, serve it
        file, err := fsys.Open(r.URL.Path)
        if err == nil {
            file.Close()
            fileServer.ServeHTTP(w, r)
            return
        }

        // Fallback: If file doesn't exist, serve index.html for React Router
        if errors.Is(err, os.ErrNotExist) {
            r.URL.Path = "/"
            fileServer.ServeHTTP(w, r)
            return
        }

        http.Error(w, "Internal Server Error", http.StatusInternalServerError)
    })

    return mux
}

3. How to still dev correctly with hot-reload

Baking your assets into a binary is incredible for production, but rebuilding your entire Go binary every single time you change a pixel or a CSS class in React is a developer experience nightmare.

To maintain an instant Hot Module Replacement (HMR) workflow during development, you run your tools in a decoupled dev mode, utilizing Vite's dev server for the frontend and Air for backend live-reloading.

The Development Architecture

Frontend: Run npm run dev in your /frontend directory. Vite fires up on http://localhost:5173.
Backend: Run air in your /backend directory. Air watches your .go files and live-reloads your API on http://localhost:8080.

Pointing Vite to the Go Backend

To bypass CORS issues locally and make sure your frontend API fetches seamlessly hit your Go server, configure Vite’s built-in proxy.

Update your frontend/vite.config.ts (or .js) file to automatically proxy API and WebSocket requests back to your running Go port:

import { defineConfig } from 'vite'
import react from '@vitejs/react-swc'

export default defineConfig({
  plugins: [react()],
  server: {
    proxy: {
      // Proxy standard API HTTP requests
      '/api': {
        target: 'http://localhost:8080',
        changeOrigin: true,
      },
      // Proxy live WebSocket traffic
      '/ws': {
        target: 'ws://localhost:8080',
        ws: true,
      }
    }
  }
})

The Result

When working locally, you open your browser to http://localhost:5173 (Vite). Any changes you make to your React components reflect instantly in the browser via HMR. When your React components make a fetch request to /api/v1/health, Vite transparently routes it back to your Go server running on :8080.

When you are ready to ship to production, you run your production build script: Vite compiles down to static optimized files inside backend/dist/, and your go build pipeline locks those files permanently inside your deployable executable.

If you want to see this layout working in a live codebase, check out the full implementation over at MQTT Dashboard on GitHub.

Drop a comment below if you run into any issues mapping your embedded file handlers or configuring Air for your hot-reload stack!