Quickstart
Embark and get from zero to invoking your first endpoint in five minutes.
In a hurry? Pick your boat and go straight into the water →
Pick your path
Bowire runs two ways — the rest of the steps differ slightly depending on which one you pick.
Pick a path above — the next steps will appear here.
Install Bowire
Pick the package format for your platform. All five paths land at the same bowire CLI plus the embedded browser UI on port 5080.
winget install KuestenLogik.Bowire
One-line install via the Windows Package Manager. bowire lands on PATH; uninstall via "Apps & Features" or winget uninstall KuestenLogik.Bowire.
brew tap kuestenlogik/bowire
brew install bowire
One-time tap, then brew install. The same formula serves both Apple Silicon and Intel Macs — Homebrew picks the right binary at install time.
# Debian / Ubuntu / Mint
sudo apt install ./bowire_0.9.4_amd64.deb
# Fedora / RHEL / openSUSE
sudo dnf install ./bowire-0.9.4.x86_64.rpm
# Arch / Manjaro
yay -S bowire
# Or Linuxbrew (cross-distro)
brew tap kuestenlogik/bowire && brew install bowire
Distro-native packages on every GitHub release. Both x86_64 and aarch64 builds are attached so ARM Linux works out of the box. The Linuxbrew path uses the same formula as macOS.
dotnet tool install -g Kuestenlogik.Bowire.Tool
Cross-platform path that ships every first-party protocol plugin pre-bundled. Requires the .NET 10 SDK on the host. Update with dotnet tool update -g Kuestenlogik.Bowire.Tool.
docker pull ghcr.io/kuestenlogik/bowire:latest
docker run --rm -p 5080:5080 \
-v ~/.bowire:/home/app/.bowire \
ghcr.io/kuestenlogik/bowire:latest \
--url https://api.example.com
Multi-arch image (linux/amd64 + linux/arm64). The volume mount keeps installed plugins, recordings, and environments persistent across container restarts.
Every package ships every first-party protocol plugin bundled (gRPC, REST, GraphQL, SignalR, WebSocket, SSE, MQTT, Socket.IO, OData, MCP). Sibling plugins (Storm, Kafka, DIS, UDP) install separately — see step 5.
Every install path on the downloads page → Configuration options (port, plugin dir, theme) →
Run it against your service
Point Bowire at any URL — your own ASP.NET app, a remote production service, an OpenAPI document on disk, anything.
bowire --url https://api.example.com
Multi-target works too — pass --url repeatedly to connect to several services in parallel:
bowire --url https://users.example.com:50051 \
--url https://orders.example.com/openapi.json \
--url https://chat.example.com/notifications
Bowire tries every installed protocol plugin against each URL and picks the one that responds. gRPC reflects, REST reads OpenAPI, GraphQL introspects, SignalR enumerates hubs, MQTT subscribes — all without configuration.
Open the workbench
Bowire opens a browser tab at http://localhost:5080/bowire (or whichever port you passed via --port).
The sidebar shows every service the plugins discovered, grouped by URL when you connected to several. Click any method, drop in inputs (typed form or raw JSON, toggle with f), hit Ctrl+Enter, response renders in the right pane. Streaming responses show as a Wireshark-style frame list, duplex protocols open persistent channels, and every call lands on the request history for replay.
Full UI guide →Install a sibling plugin optional
For protocols that don't ship with the CLI bundle — Storm, Kafka, DIS, UDP — pull the plugin from NuGet:
bowire plugin install Kuestenlogik.Bowire.Protocol.Kafka
bowire plugin install Kuestenlogik.Bowire.Protocol.Storm
bowire plugin install Kuestenlogik.Bowire.Protocol.Dis
bowire plugin install Kuestenlogik.Bowire.Protocol.Udp
Air-gapped install? Download the plugin and its transitive deps on a connected host into a folder, transfer the folder, install offline:
# On the connected host
bowire plugin download Kuestenlogik.Bowire.Protocol.Kafka --output ./bundle/
# On the offline host (after transferring ./bundle/)
bowire plugin install --file ./bundle/kl.bowire.protocol.kafka.0.9.4.nupkg \
--source ./bundle/
Plugin system docs →
You're afloat
Bowire is running. The sidebar populates with every service the plugins discovered, plus a recent-history strip and the keyboard-shortcut hint band.
From here on it's a regular API workbench: pick a method, fill the form (or hit f for raw JSON), Ctrl+Enter to execute, response on the right. Recordings, environments, performance graphs, the command palette — all one shortcut away.
Add the NuGet packages
Pick the protocol plugins your service speaks. The core Kuestenlogik.Bowire package is always there; protocols are opt-in so you only ship what you need.
dotnet add package Kuestenlogik.Bowire
# plus the protocols your service exposes
dotnet add package Kuestenlogik.Bowire.Protocol.Grpc
dotnet add package Kuestenlogik.Bowire.Protocol.Rest
dotnet add package Kuestenlogik.Bowire.Protocol.SignalR
Every first-party protocol (gRPC, REST, GraphQL, SignalR, WebSocket, SSE, MQTT, Socket.IO, OData, MCP) is its own package — same versioning, same release cadence. Sibling plugins (Storm, Kafka, DIS, UDP) follow the same pattern from their separate repositories.
Every package on the downloads page → Configuration options (mount path, theme, auth) →
Wire it into Program.cs
Two lines: AddBowire() registers the plugin host into DI, MapBowire() mounts the workbench at /bowire.
var builder = WebApplication.CreateBuilder(args);
// ... your existing service registrations ...
builder.Services.AddBowire();
var app = builder.Build();
// ... your existing middleware + routing ...
app.MapBowire();
app.Run();
That's the entire wire-in. Plugin discovery, protocol detection, and the browser UI all run in-process against the live IServiceProvider — no schema files, no parallel proto / OpenAPI to maintain, no second process to keep in sync.
Run your app
Start your service the way you always do, then open /bowire alongside your normal API routes.
dotnet run --project src/MyService
# → Listening on https://localhost:5001
# Open https://localhost:5001/bowire in your browser
Bowire picks up every protocol prerequisite for you: gRPC plugins call AddGrpcReflection() and MapGrpcReflectionService(), REST plugins read your IApiDescriptionGroupCollectionProvider, SignalR plugins enumerate mapped hubs via EndpointDataSource. Side effects scoped to dev / staging environments only — the production path stays untouched.
Add a sibling plugin optional
For protocols that ship from sibling repositories — Storm, Kafka, DIS, UDP — the same dotnet add package path applies.
dotnet add package Kuestenlogik.Bowire.Protocol.Kafka
dotnet add package Kuestenlogik.Bowire.Protocol.Storm
dotnet add package Kuestenlogik.Bowire.Protocol.Dis
dotnet add package Kuestenlogik.Bowire.Protocol.Udp
The plugin host loads each package into its own AssemblyLoadContext, so transitive-dependency conflicts between plugins don't reach your app. No host-side wiring needed beyond AddBowire().
Bowire is mounted
Hit https://localhost:5001/bowire and the workbench is running inside your app. The sidebar already lists every service your DI container exposes — no schema files, no manual registration.
The same shortcuts, the same recordings, the same environments as the standalone CLI — just one URL away from your normal API routes. Ship the same binary to staging or production with the workbench scoped to dev environments by tag, or strip MapBowire() with a feature flag for prod.
From here
A few steps in, and you have a workbench running against any service in your stack. Three branches from here:
Run aground? Get helping hands →