Deployment

Bowire is one workbench with several places to put it. Every mode supports every protocol plugin — the choice is about how Bowire reaches the target API and who starts it, not about what it can talk to.

Mode How it reaches the API Use case
Standalone CLI / browser UI pointing at any remote URL Testing third-party APIs, QA sessions, CI one-liners
In your editor The standalone CLI, hosted in a VS Code panel Working on a service with the workbench next to the code
Embedded Mounted at /bowire inside your ASP.NET app Dev-time browser UI for your own service
Container Sidecar next to a non-.NET service Teams running Go / Rust / Python / Node services

Standalone

The CLI and the browser UI in one executable. It ships with every protocol plugin built in and points at any URL you pass:

bowire --url https://your-server

Best when the target service isn't yours or you don't want to modify it. Also works offline against a schema file (.proto, OpenAPI, GraphQL SDL) when no server is reachable.

Installing it. Four routes, all producing the same bowire on your PATH:

winget install KuestenLogik.Bowire        # Windows
choco install bowire                      # Windows (Chocolatey)
dotnet tool install -g Kuestenlogik.Bowire.Tool   # any platform with the .NET SDK

Or take a native installer or a self-contained archive from the Downloads page: MSI for Windows, DEB for Debian / Ubuntu, RPM for Fedora / RHEL / SUSE, and zip / tarball bundles for anywhere you want an xcopy deployment. The self-contained bundles carry their own runtime, so they need no .NET installed at all. (A Homebrew tap is still pending.)

See Standalone tool for the CLI command set, how to restrict loaded plugins, and how another program can start Bowire and learn which port it bound.

After installing: how to start it

Every installer puts Bowire in the place your desktop already looks:
Windows (MSI, winget, Chocolatey) Start menu → Bowire, and a desktop icon. Add DESKTOPSHORTCUT=0 to msiexec if you would rather not have the desktop one.
Linux (DEB, RPM, AUR) Application menu → Bowire, under Development. Pin it to your dock like any other app.
macOS (Homebrew, tarball) Bowire.app, in the tarball and in the Homebrew prefix. brew install prints the one command that links it into /Applications, after which it is in Launchpad.
Anywhere bowire in a terminal — every install puts it on your PATH.

Clicking any of those starts the workbench and opens your browser at it. There is no separate app window: the browser tab is the UI.

On Windows a console window opens alongside it. That window is Bowire — closing it stops the workbench, and so does Ctrl+C in it. (#687 replaces it with a tray icon, which is what gives you a way to quit once the window is gone.) On Linux and macOS a menu launch has no terminal at all.

After a reboot

Nothing is running. Bowire is not a service and does not start with your machine — it runs only while you have it open. Start it again the same way: Start menu, application menu, Launchpad, desktop icon or bowire.

Clicking again while it is already running does not start a second copy: Bowire notices the first one and opens your browser at it.

The workbench that comes back is the same one you left. Workspaces, collections, environments and recordings live on disk (see storage locations), not in the running process.

In your editor

The VS Code extension opens the workbench in an editor panel beside your code.

ext install kuestenlogik.bowire-vscode

It does not bundle Bowire — it drives one. The extension uses a CLI you configured, one your repository pins in a tool manifest, or one on your PATH, and offers to fetch a verified copy when it finds none. That matters because it means the workbench in your editor, the bowire in your terminal and the one in CI are the same binary reading the same collections.

Collections, environments and recordings stay plain JSON on disk, so a repo that opts into project-scoped storage keeps them beside its code and they commit, diff and review like any other file.

Embedded

Add Bowire directly to an ASP.NET application. The discovery pipeline reuses the host's service provider and endpoint metadata, so every protocol plugin you have installed works automatically.

dotnet add package Kuestenlogik.Bowire

app.MapBowire();

Best when you own the service and want a zero-config UI available during development.

See Embedded mode for configuration options, custom authentication, and per-plugin settings.

Container

Bowire is published as a multi-arch (linux/amd64 + linux/arm64) OCI image on every tagged release:

docker pull ghcr.io/kuestenlogik/bowire:latest

Best as a sidecar next to a service that isn't .NET, or anywhere you'd rather not install anything on the host.

See Containers / OCI for the registries, tag policy and a compose example.

Requirements

  • Nothing at all for the native installers and the self-contained archives — they carry their own runtime.
  • .NET 10 SDK for dotnet tool install, for the embedded package, and for a repository that pins Bowire in a tool manifest.
  • Any modern browser for the UI.
  • For gRPC targets: the server must expose Server Reflection, or you drop a .proto file into Bowire.

Next

  • User Guide — once Bowire is running, how to drive the UI
  • Protocol Guides — per-protocol behaviour and setup
  • Features — workflows (recording, flows, performance, environments, …)
  • Storage locations — where your collections and recordings end up
Edit this page