Browser-Based Service Bus Explorer
Bussin is a browser-native client for Azure Service Bus. By operating entirely within your browser's local sandbox, it delivers a secure administration dashboard without requiring native installation or third-party servers.
Why Choose a Browser-Based Tool?
Traditional messaging utilities often require downloading heavy desktop clients or configuring complex local runtimes. A browser-based approach provides complementary advantages for cloud developers:
Immediate Browser Startup
Navigate directly to the app URL, log in with your Entra ID credentials, and start peeking queues. There are no installer packages to download and no corporate security approvals required.
Cross-Platform Compatibility
Browser execution ensures that developers on macOS, Linux, and Windows have access to the exact same management interface. You can even run it as a Progressive Web App (PWA) for desktop integration.
Secured by Sandbox Isolation
Bussin runs within standard browser isolation boundaries. This prevents cross-origin resource sharing (CORS) access and keeps your connection settings secured locally on your own machine.
The Security of a Direct Connection
Many web-based administration tools function by routing your database credentials, SAS keys, or message payloads through their own intermediate backend API servers. This model poses significant data privacy risks and latency overhead.
Bussin is built differently:
- Direct to Broker: All network traffic flows exclusively between your browser process and your Azure Service Bus endpoints. We do not operate intermediate servers.
- Delegated Permissions: Authentication is handled using standard Microsoft Sign-In. Bussin cannot perform actions beyond what your Entra ID role is authorized to do.
- Local Memory Execution: Message headers, payloads, and search filters are stored strictly in your browser's volatile memory and disappear as soon as you close the tab.
To review the technical connection specs, check out our detailed Architecture and How It Works Guide.
How Proxy-Based Tools Differ
Most web-based administration tools for cloud services follow a standard pattern: your browser talks to the vendor's backend server, which then talks to your cloud provider on your behalf. This means:
- Credential Exposure: Your credentials or tokens pass through a third-party server that you don't control.
- Payload Transit: Your message payloads are decrypted and re-encrypted at the proxy layer, creating a potential data exposure surface.
- Vendor Dependency: The vendor's infrastructure becomes a single point of failure between you and your own cloud resources.
Bussin skips the proxy entirely. Your browser opens a direct AMQP 1.0 connection to Azure over WebSockets. The hosting server only serves the static HTML and WebAssembly files—after that, it's out of the loop.
What Runs in Your Browser
Bussin is a static web application composed of three client-side components:
MSAL.js
Handles Entra ID authentication and token lifecycle directly in the browser. Tokens never leave your local session.
Blazor WebAssembly
Renders the admin UI. The entire .NET runtime executes locally via WebAssembly—no server-side rendering.
Rhea AMQP Engine
Pipes raw AMQP 1.0 frames over WebSockets to Azure Service Bus. This is the same wire protocol that native desktop clients use.
All three components run in your browser's security sandbox. Closing the tab destroys all state—tokens, messages, and search results.
Related Guides
- Alternatives — Compare Bussin's capabilities against traditional utilities.
- Dead-Letter Queue — Understand how DLQs collect failed messages.
- macOS and Linux — Learn about PWA support on macOS and Linux.