Why viewbus

A desktop client for Azure Service Bus, built on a local index and non-destructive reads. Here's what that means in practice.

Speed

Nothing waits on the network that doesn't have to.

Local SQLite index: Namespaces, queues, topics and subscriptions are indexed to disk on first sign-in. Browsing is a local read, so the tree stays instant across thousands of resources.
Rust on the hot paths: Indexing, fuzzy matching, AMQP and bulk jobs are compiled. The UI is a system webview through Tauri, not a bundled browser.
System-wide spotlight: Ctrl+I opens a fuzzy search over the whole index from anywhere in the OS, including with the app closed to the tray. Rebindable.
Connection strings are first-class: Namespaces added by connection string land in the same tables as Azure-discovered ones, and behave identically in peek, resend, spotlight and MCP.

The destructive things are the ones worth being explicit about.

Peek, not receive: Messages are read over AMQP with peek semantics. Nothing is dequeued, delivery counts don't move, and session locks are released after the read.
Bulk work runs as a job: Purge, dead-letter, resend and delete preview the matched set before anything happens, then run with progress, an ETA and cancel. Throttling backs off instead of failing, and every run lands in a per-resource history.
Credentials stay in the OS: Tokens and connection strings go to Windows Credential Manager or the macOS Keychain. Never the index, never the log files.
No backend: The app's content security policy limits egress to Microsoft's endpoints, your own namespaces, and two static JSON files for update and notice checks.

The things the Portal and the original explorer can't do.

Body search across a namespace: Search message contents across every queue, topic and dead-letter queue at once, rather than opening entities one at a time.
Diff and resend: Edit a dead-lettered message's body and properties in a side-by-side diff, then send it back. Composing and scheduling new messages uses the same editor.
Background monitoring: Grouped resources, a dead-letter threshold per set, native notifications, and mutes that expire on their own. Samples counts only, never message bodies.
Two automation surfaces: A read-only MCP server over local stdio, and a loopback HTTP API with a per-launch bearer token. Neither opens a network listener.