Build API tests as a graph. Ship them as YAML.

Yes, on Windows and Linux: an early-access release candidate is on the download page now. The macOS build ships as soon as it is signed and notarized, and the early-access list gets that link first. 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. 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 ships only signed and notarized; we won't ask you to bypass Gatekeeper.

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. And the licence is verified offline against a key compiled into the app, so there is no server whose shutdown could disable software you paid for. Nothing you own routes through us, which means there is no version of us disappearing that takes your work with it.

The download is the complete app, with nothing locked, timed, or degraded, and it is free indefinitely for personal, learning, and open-source work. Commercial use is what a licence is for: 30 days to evaluate, then a one-time per-seat licence, priced when checkout opens at launch. If you use it free and want to back the work anyway, there is a Patreon on the download page. It gets you nothing extra, which is the point: nothing is held back from the free build to make an ask work.

Nothing is disabled, degraded, or made read-only. Not at day 31, not ever. You get a dismissible note, at most once a day. That is the entire enforcement mechanism, and a test exists purely to prove an unlicensed install still runs flows.

They start the first time you open the app, and your own machine counts them: the date is stored locally and reported nowhere. There is no account, no activation call, and nothing that resets or expires if you reinstall or work offline.

Not a subscription: one payment, nothing auto-renews, no card on file. It covers every release built in the following 12 months, major versions included. After that, the version you have keeps working unchanged. The boundary is on new builds, never on software you already run. Renewal is optional. Verification is offline against a key compiled into the app, so it survives us. We say perpetual rather than 'lifetime' because there is a real boundary and we would rather tell you where it is.

Commercial use, every release built in the following 12 months, early access to new builds before they go public, and priority support answered by the engineer who wrote the code rather than a first-line queue.

Yes to both. A seat is per person rather than per machine, so one licence covers your laptop and your desktop, and you buy as many as you have people. Paddle is the merchant of record, which means the receipt is a proper VAT invoice with your company name and tax number on it, and a purchase order works too: mail [email protected] with the seat count and you get an invoice back. There is no volume tier and no seat-count enforcement, because there is nothing that phones home to count with.

A page written for exactly that, at /security: the complete list of what crosses the network and when, where flows, credentials and run history are stored, how the desktop app is sandboxed, and the compliance claims we deliberately do not make. It also carries the answers most vendor questionnaires ask, in the order they ask them. Short version: no account, no telemetry, nothing of yours reaches us, and there is no SOC 2 report, which we say outright rather than imply away.

If what you need is a fast, git-native request client, Bruno is genuinely good and you should use it. We are not going to pretend otherwise. Bandura is a different shape: flows rather than requests, with branching, loops, parallel fan-out, subflows and assertions as first-class node types, a visual graph over the same file you edit as code, step-through debugging, gRPC and WebSocket and SSE in one engine, self-healing against OpenAPI drift, and an MCP server so an agent can run your suite. If none of that is worth a licence to you, then it isn't, and Bruno is the better buy at zero. We would rather you reached that conclusion here than after paying.

The full comparison: Bandura vs Bruno →

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.