Vayu vs Postman - an open source Postman alternative that load tests¶
Postman is the API client most teams start with, and it is good at that job. The two questions that usually send people looking for an alternative are the same two every year: what happens to my requests once they live in someone else's cloud, and what do I reach for when I need to know the endpoint holds up under traffic. Vayu answers both by staying on your machine and shipping a native C++ load engine in the same app.
| Vayu | Postman | |
|---|---|---|
| Execution engine | C++ (native) | Node.js / Electron |
| API client + load test | Both, one app | Client only |
| Load test throughput | Tens of thousands of req/s | Requires a separate tool |
| Privacy / offline | 100% local, no account | Cloud-heavy (optional local) |
| Scripting | QuickJS (pm.* syntax) |
JavaScript |
| MCP / agent control | Built in, local, drives the load engine | Yes, via the cloud workspace |
| SSE streaming | Live Events view, scriptable, load-tested | Client-side inspection |
| Mock servers | Collection mock + OAuth issuer + webhook inbox | Yes (cloud tier) |
| Data-driven runs | CSV / TSV / JSON / JSONL | CSV / JSON |
| Proxy / custom CA / client certs | In Settings - four proxy modes, additive CAs, per-host certs* | In Settings - proxy, CA file, per-domain certs |
| Postman collection import | Yes (v2.0 + v2.1) | Native |
| OpenAPI import | Yes (3.1 / 3.0 / 2.0) | Yes |
| Open source | Yes (dual-license) | Partial |
* One asterisk that row has earned. system proxy mode resolves a PAC
script once, against a probe URL, applying that one answer engine-wide
rather than per URL; a headless engine with nothing resolved falls back to
environment-variable pickup rather than to no proxy. Client certificates carry
no qualification any more - they are proven on a wire on all three platforms,
in both PEM-pair and PKCS#12 form. Detail:
proxy settings,
TLS trust and
client certificates.
One app instead of two¶
The workflow Postman does not cover is the one that starts the moment a request works: does it still work at a thousand a second? That is a second tool - k6, JMeter, or the Postman collection runner at a fraction of the throughput - which means a second config, a second copy of the endpoint, and a context switch every time. In Vayu the load tester points at the request you already built. The engine is a multi-worker libcurl event loop in C++23, running as a sidecar process so the UI never shares a thread with the request load, and it sustains tens of thousands of req/s while the dashboard streams percentiles live. The numbers, the method, and a one-command reproduction are on the benchmarks page.
Local by construction, not as a setting¶
Vayu has no account, no sign-in, and no cloud sync, because there is no server component to sync with. Collections, environments, secrets, and run history live in a SQLite database in your home directory, and the app contacts no external service during normal use - no telemetry, no license check. That is what makes it usable behind a corporate firewall or on an air-gapped network, where a client that wants to reach a workspace API simply cannot work. The firewall half of that is now true in both directions: the engine goes through the proxy your company runs, verifies against the CA it injects, and presents the client certificate its APIs ask for - configured once in Settings > Network & connectivity, applied to every outbound path. The trade is real and stated plainly below: nothing syncs itself between machines either.
Your agent can drive it¶
Vayu hosts an MCP server inside the app on
127.0.0.1:9877, so Claude Code, Cursor, VS Code, Codex or Zed can use the same
engine the UI does - send a request, start a load run, read the report, compare
two runs. Postman also exposes MCP, but against its cloud workspace; Vayu's runs
locally and hands the agent the load engine itself. Because that is a real
capability, it is gated: network tools refuse any host outside an allowlist that
starts empty, load runs are capped on RPS, concurrency and duration, and the
tools that write to saved data sit behind a toggle that ships off - while it is
off those tools are not offered to the agent at all, and calling one by name
answers with the setting to turn on rather than an unknown-tool error.
When to choose Postman¶
Vayu does not replace Postman for everyone, and pretending otherwise would waste your afternoon:
- You need team collaboration. Shared workspaces, role-based access, comments on requests, and forking a collection are Postman's core product. Vayu is single-user and local; sharing means committing an export.
- You depend on cloud sync across machines. Your Postman workspace follows you to a new laptop. A Vayu workspace is a local database you move yourself.
- You run monitors or scheduled checks. Postman runs collections on a schedule from its own infrastructure. Vayu runs when you or your CI runs it.
- You publish public API documentation or use the Postman API Network to discover other people's collections. There is no equivalent here.
- Your team already lives in it. Familiarity is a real cost to spend.
Bringing your collections across¶
Postman Collection v2.0 and v2.1 exports import with the folder tree,
collection and folder variables, auth, pre-request and test scripts, query
parameters, and raw, JSON, URL-encoded, form-data and GraphQL bodies. Postman
exports environments and globals as separate files; drop those in too and
they import as a Vayu environment and into the globals scope respectively.
Binary and file bodies are dropped with a count rather than silently, and
Digest / AWS / NTLM auth imports as data but will not execute. Most pm.* test
scripts run unmodified - what is covered, and
what carries over per format.
Try it¶
Windows:
macOS and Linux: