A workbench inside your binary

AddBowire() + MapBowire() in Program.cs, and the workbench is part of your service. Not a sidecar, not a companion container, not a cloud service that proxies your traffic.

Every endpoint browsable at /bowire next to your normal API routes. Zero account walls. Ships with your binary, no separate distribution. Same DI container, same [Authorize] gates, same logging providers as the rest of your app.

Two lines — the entire wire-in

AddBowire() registers the plugin host into DI. MapBowire() mounts the workbench at /bowire. No further configuration required.

Plugin discovery, protocol detection, 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. Protocol prerequisites that you'd normally wire by hand are added automatically: gRPC plugins call AddGrpcReflection() and MapGrpcReflectionService(), REST plugins read the existing IApiDescriptionGroupCollectionProvider, SignalR plugins enumerate mapped hubs via EndpointDataSource.

Side effects are scoped to dev / staging environments only — the production path stays untouched. Strip MapBowire() with a feature flag for prod, or leave it on behind an authorization policy if you want the workbench available against the prod surface for the on-call team.

Embedded setup docs →
csharp Program.cs 
var builder = WebApplication.CreateBuilder(args);

// ... your existing service registrations ...

builder.Services.AddBowire();

var app = builder.Build();

// ... your existing middleware + routing ...

app.MapBowire();
app.Run();

Inherits the host's DI, auth, logging, config

Bowire reads from the same IServiceProvider your app already builds. Every behaviour that's wired in elsewhere is honoured automatically.

  • [Authorize] gates still apply. A method locked behind a policy needs the same token when invoked from the workbench. The workbench's auth-helper panel picks up the token the user already authenticated with; no parallel credentials store.
  • Feature flags still toggle. If a flag flips a code path off in your service, the workbench sees it off too. No phantom “available in the docs, not available at runtime” drift.
  • Logging providers receive Bowire diagnostics. Workbench-side discovery, invocation, and error traces flow into whatever Serilog / OpenTelemetry / built-in logging your service already has — next to your normal request logs, not in a separate file.
  • IOptions<T> picks up the same values. Plugins that consume IOptions<T> read the same appsettings.json + environment variables your service does. One config tree, one source of truth.

Nothing parallel, nothing bypassed. The workbench surface is the surface your service exposes; the difference is just which client is calling.

sequenceDiagram
    autonumber
    participant Host as Program.cs
    participant DI as IServiceProvider
    participant Bowire

    Note over Host,DI: Boot
    Host->>DI: AddAuthentication · AddLogging · ...
    Host->>DI: AddBowire()
    Host->>Bowire: MapBowire()

    Note over Bowire,DI: Request time
    Bowire->>DI: resolve [Authorize] policy
    DI-->>Bowire: same policy as the host's
    Bowire->>DI: resolve ILogger / IOptions
    DI-->>Bowire: same providers · same config
Bowire reads from the same IServiceProvider the host already built. [Authorize] gates, logging providers, IOptions<T> all resolve to the host’s values — no parallel pipeline, no second credentials store, no separate log file. The workbench surface is the service surface.

When embedded is the right deployment shape

Three concrete cases where the embedded path beats the standalone CLI.

  • You ship a binary; users need a debug UI. Postman-class workflow inside your distribution, behind your auth, no extra Electron install for the user.
  • Internal-tools teams want the workbench scoped to the service it tests. No company-wide Postman license, no shared workspace to keep in sync — the workbench is the service.
  • Discovery needs in-process metadata. Embedded mode reads endpoint sources (gRPC reflection, OpenAPI document provider, SignalR hub registry) directly via DI — faster, no network round-trip, no schema-version drift between the workbench and the live service.

For the cases where in-process isn't the right shape — air-gapped scans, contracts-only browsing, MCP-driven CI agents — the standalone bowire CLI covers the same surface from outside.

Mount it in your app

Two lines in Program.cs. The workbench is part of your binary, runs with your auth, ships with your release.

Backend-dev workflow Quickstart (embedded path) Embedded setup docs

A different lane fits better? All solution lanes →