The Idea: Why I Built MistPulse

It starts with a familiar itch for anyone who has spent time in the field: I've spent most of my career on the two sides of the same coin: keeping networks running and keeping them safe. Long before MistPulse existed, I worked for a managed service provider, and a huge part of that job was driving from site to site with a laptop bag, plugging into switches, and troubleshooting almost entirely through the CLI. Different clients, different vendors, different topologies, and in most of those environments, there was no unified dashboard at all. Just SSH sessions, show commands, and whatever notes I'd kept from the last visit.

That's really where this idea was born, not in a Mist environment, but in parking lots and server closets, wishing I had something faster than pulling out a full laptop and re-establishing a CLI session just to answer a simple question like "is this AP even up?" Even a rough, read-only mobile companion to that CLI workflow would have saved me an enormous amount of time back then. The specific platform didn't matter. The pattern did: quick answers, in the field, without the ceremony of a full laptop session.

The idea resurfaces, years later

That MSP chapter ended a while ago, but the itch never fully went away. Years later, working with Juniper Mist as part of my day-to-day at HPE Networking, the same pattern showed up again, just in a much better environment. Mist's cloud portal is genuinely one of the best network management platforms I've used: the SLE metrics, the site and device visibility, the API surface underneath all of it are excellent, and I mean that as someone who works with it professionally, not as a sales line.

But even a great portal is still, fundamentally, a big-screen tool. Even with something as capable as Mist, I kept noticing the same old craving from my MSP days: a fast, mobile-native way to check a site's health, glance at a device, or run a quick diagnostic without opening a laptop first. Mist didn't need to be replaced or improved on the desktop; it just felt like there was real room for a mobile-first companion built around the handful of checks I run constantly.

The Mist portal is excellent on a laptop. I just kept feeling like a mobile companion to it would be extremely useful too.

The Mist platform, to its credit, exposes almost everything through a documented REST API. Sites, devices, WLANs, SLE metrics, NAC and PSK details, templates, webhooks: it's all there if you're willing to call the endpoints yourself. That was the opening I'd been missing back in my MSP days: if the data is reachable over HTTPS, there's no reason it can't live in a small, fast, native mobile app built around the handful of workflows I actually repeat: check site health, look at a device, glance at recent client counts, run a quick ping or traceroute from the field.

Why I decided to build my own, rather than stop there

I wanted something narrow and personally opinionated: a tool shaped around the exact troubleshooting loop I run dozens of times a week, with room to add the one-off checks that matter to how I personally work an incident. I also wanted a project I could evolve on my own schedule: add something the day I need it, rather than waiting on someone else's roadmap. None of that is a knock on Mist or on Juniper's own app; it's just a different, more personal itch than any general-purpose tool is built to scratch.

There was a second motivation, just as strong as the convenience angle: I wanted to prove to myself, end to end, that a security-conscious engineer could build a mobile client against a sensitive infrastructure API without taking shortcuts on how credentials are handled. That constraint shaped nearly every architectural decision that came after it, and it's a thread that runs through this entire series.

Setting the scope before writing a line of code

Before opening an editor, I wrote down the boundaries of what MistPulse would and wouldn't try to be. It would not try to replace the Mist portal for configuration-heavy work: building out a new site from scratch, designing WLAN policies, or writing switch templates from zero. Those workflows benefit from a big screen and deserve careful, unhurried attention. What MistPulse would own was the read-heavy, time-sensitive side of operations: status checks, live troubleshooting tools, quick lookups, and, over time, a small set of safe, well-scoped write actions like renaming a device or restarting an AP.

• In scope: site and device health, SLE metrics, client visibility, ping/traceroute/ARP tools, WLAN status, quick device actions
• Out of scope (at least for v1): full topology design, switch/gateway template authoring, org-wide policy changes
• Non-negotiable from day one: the app itself would never hold a raw Mist API token

That last point deserves its own emphasis, because it's the decision that everything else in the architecture flows from. Mist API tokens are powerful: depending on scope, they can read and write configuration across an entire organization. Shipping a mobile app that embeds or caches that token on-device, even encrypted, felt like an unacceptable risk surface for something that would live on a phone that could be lost, stolen, or simply have its local storage inspected. I decided early that whatever I built would need a server-side relay standing between the app and Mist's API, which meant this was never going to be a client-only weekend project. It was going to need a backend, from the very first commit.

What came next

With the scope written down and the non-negotiable security boundary set, the next problem was purely architectural: how do you build a backend relay that's simple enough to maintain solo, cheap enough to run indefinitely, and secure enough to trust with real infrastructure credentials? That's where Supabase entered the picture, and it's the subject of the next post: the foundation the rest of MistPulse was built on.

Coming up next: Laying the Foundation: the architecture and the security-first API relay that keeps Mist tokens off the phone entirely