See where your API test breaks.

Yes, on macOS, Windows and Linux: an early-access release candidate is on the download page now. macOS builds are unsigned early access; the download page explains how to approve the first launch. The CLI, which runs the same engine, is already public on npm as @bandura/cli.

macOS (Apple Silicon and Intel), Windows, and Linux (AppImage and .deb), each built natively. macOS, Windows and Linux are downloadable today. The Windows build is unsigned until a certificate lands, so expect a one-time SmartScreen warning there; SmartScreen is a Windows thing, so Linux installs run without one. macOS builds are not Developer ID-signed or notarized. First launch requires approval in System Settings → Privacy & Security.

Not today, but there is no lock-in by design. .aether is documented plain YAML, readable by any tool. Your tests live in your Git history, never in our database.

They keep working, and that is a design constraint rather than a promise. Your flows are plain YAML in your own repository, in a format documented in full, so they are readable and editable with no Bandura installed at all. The runner is a published npm package you already hold a copy of. No activation server controls whether you can run the application. Nothing you own routes through us, which means there is no version of us disappearing that takes your work with it.

Yes. The complete application is free for personal and commercial use. No trial, paid seat, activation key or subscription is required.

You can contribute through Patreon. Support is optional and unlocks no extra application features.

Support on Patreon →

Try it on one scenario with dependent requests: login, capture a token, create an object and verify it. The graph shows the dependency chain and the failing step; the same files can run in CI. You do not need to migrate your whole workspace.

No. The free-use permission also covers earlier official releases. Older builds may still show the retired reminder; no payment is required. See the download page for the latest available build.

One flow, as plain YAML with embedded JavaScript: an ordered, branching set of nodes. Routing lives on each node, so there is no separate graph state to drift out of sync.

No. Nothing shells out. Requests run inside a sandboxed execution engine with its own scheduler, so a flow can branch on a response, loop over a dataset, fan out in parallel, call another flow, hold a WebSocket open, collect an SSE stream, and carry captured variables between nodes with per-run isolation. The same engine binary runs in the desktop app, the CLI, and the MCP server, which is why a run in CI behaves identically to the one you just watched on the canvas.

All four are shipped. GraphQL and SSE ride the request node as optional blocks; gRPC (unary and server-streaming, via .proto or reflection) and WebSocket are their own node types. All run identically in the desktop app, the CLI, and the MCP server.

Attach a CSV or JSON dataset and the flow runs once per row, that row in scope as `data`. Each row is an independent test case, and a captured value never leaks into the next.

Which node failed and why: an assertion's expected value against the actual one, the HTTP status, or the unwrapped transport cause, so a DNS or TLS fault reads as itself rather than as a generic `fetch failed`. Each one carries a jump to the matching log line. Repeated identical notifications collapse into one row with a count instead of stacking up.

The bandura CLI runs any flow or glob headlessly and exits non-zero on failure. Reporters: pretty, JSON, JUnit XML, and GitHub annotations.

Yes, and it is the most common migration. No account, no cloud sync: your tests are plain-text .aether files in your own Git repository, and one-click Postman Collection v2.1 import is shipped.

Yes, all shipped: Postman Collection v2.1, OpenAPI 3.0/3.1 and Swagger 2.0, pasted curl, Bruno, Insomnia v4, HAR captures, and Postman environment files.

Yes. Import shows a review step first: the detected format, each flow it found with its node count and the requests it makes, the environment variables it picked up, checkboxes to import only the flows you want, an editable destination folder, and a flat option. Nothing is written to disk until you press Import.

Fully. Editing, running, importing, drift detection, the CLI: all local, no account, no network. Two things call out, and nothing else does. AI generation and chat reach whichever provider you configure, and if that is a local Ollama or LM Studio, nothing leaves your machine at all. Separately, the app asks our public releases list once a day whether a newer version exists so it can tell you: it sends no identifier, it fails silently when you are offline, and one switch in Settings turns it off. Nothing is fetched or installed unless you press the button that does it.

Settings live in a hand-editable `settings.json` next to the app's data, following VS Code's model, with a typed schema: theme, a custom hex accent, font, density, line height, per-token colour overrides, and the AI provider block. Comments are allowed, deleting a key restores its default, an invalid value degrades to the default with a warning instead of breaking the app, and writes are atomic so an interrupted save can't corrupt it. API keys are deliberately not in that file. They stay in the OS-encrypted secret store. The licence key is kept separately too, so hand-editing settings can never invalidate it.

Whatever your own provider costs you. No markup, no credits, no metering. Run it on a local model and it costs nothing. Most of the intelligence needs no key at all either: import, drift detection, and self-healing are deterministic and offline.

Yes. There are three providers: Anthropic and Google Gemini natively, and OpenAI-compatible, meaning any /chat/completions endpoint, which covers OpenAI, Groq, OpenRouter, Together, Ollama, and LM Studio. Point the base URL at http://localhost:11434/v1 and a local model powers chat, the agentic tool loop, flow generation, and ai-action nodes with no API key at all and no traffic leaving your machine. A Test connection button confirms it before you rely on it, and the CLI and MCP server read the same provider, base URL, and model from the environment.

That is what the local-model path is for. With the provider pointed at an Ollama or LM Studio endpoint on your machine, no prompt, request payload, or response body leaves it, and the deterministic half of the intelligence (import, drift detection, self-healing, mock generation) never calls a model at all.