ApiArk: a Tauri v2 API client that stores every request as a YAML file

The problem ApiArk targets: API collections locked inside someone else's account

Postman's own model puts collections behind a login and, in the default configuration, in Postman's cloud. That is fine for individuals and awkward for teams whose repositories, review process and audit trail live in Git. The README states the position plainly: no login, no cloud, no bloat, and a comparison table that lists Postman at 300 to 800 MB of RAM against ApiArk at roughly 60 MB. Treat that number as a vendor claim rather than a measurement, because the repository does not ship a reproducible benchmark harness that I could find in the supplied material. The audience is narrower than the tagline suggests. It is for engineers who already treat API definitions as source files, who want a colleague's request changes to arrive as a diff, and who are willing to give up the collaborative features that only a hosted service can provide. A solo developer testing a webhook endpoint is not the target; a backend team maintaining forty endpoints across three environments is.

How the local-first storage model actually works

The mechanism is the part that distinguishes ApiArk from Hoppscotch and Postman. Each request is a .yaml file on disk, and a collection is a directory of those files. The README calls the format standard YAML, which matters because it means the files are readable and editable without ApiArk, and a merge conflict is resolved the same way any other text conflict is. Bruno takes a comparable approach with its .bru format, but that format is specific to Bruno and requires Bruno tooling to interpret. The trade-off runs the other way too: plain YAML has no schema enforcement, so a hand edit that renames a key will not be caught until the app tries to load the request. The application itself is a Tauri v2 shell, which is why the memory figure is plausible. Tauri uses the operating system's webview rather than bundling Chromium the way Electron does, so the runtime footprint is closer to a native app than to a browser. The repository is TypeScript-heavy with a Rust component under apps/desktop/src-tauri, which matches the standard Tauri split: Rust for the native shell and filesystem access, TypeScript for the interface.

Protocol coverage and where the breadth comes from

ApiArk lists REST, GraphQL, gRPC, WebSocket, SSE, MQTT and Socket.IO in one application. The comparison table in the README puts MQTT and Socket.IO in a column no other named tool occupies, and marks WebSocket and SSE as absent from Bruno. That breadth is the strongest argument for the project, because it removes the need to keep a separate MQTT client open beside your HTTP client. The screenshots in the repository show separate views for REST GET, POST, PUT, PATCH and DELETE, plus GraphQL, WebSocket and SSE, so the protocol support is at least reflected in the interface rather than only asserted in a table. What the README does not describe is how connection state is managed across protocols, or whether a WebSocket session survives a collection run. Those are the questions to answer by opening the app, not by reading the feature list.

Installing ApiArk and importing an existing collection

Package manager installation is documented for three platforms. On macOS the README gives brew tap berbicanes/apiark followed by brew install --cask apiark. On Windows it gives scoop bucket add apiark https://github.com/berbicanes/apiark and then scoop install apiark. On Debian and Ubuntu the route is a shell script from the project's GitHub Pages host, curl -fsSL https://berbicanes.github.io/apiark-apt/install.sh | sudo bash, followed by sudo apt install apiark. Direct downloads cover .exe and .msi on Windows, Apple Silicon and Intel .dmg on macOS, and .AppImage, .deb and .rpm on Linux. Note that the APT path pipes a remote script into a root shell, which is a normal pattern for third-party repositories but worth reading before you run it. Building from source requires Node.js 22 or newer, pnpm 10 or newer, a Rust toolchain and the Tauri v2 system dependencies, after which pnpm install and pnpm tauri build produce the binary. Migration is a four-step flow in the README: export a Postman Collection v2.1 JSON file, open ApiArk, press Ctrl+K and choose Import Collection, then select the file. The same importer accepts Insomnia, Bruno, Hoppscotch, OpenAPI 3.x, HAR and cURL.

Scripting, the collection runner and what the test API exposes

Pre-request and post-request scripts are written in TypeScript with type definitions shipped alongside. The README names three entry points: ark.test(), ark.expect() and ark.env.set(). That is a small surface compared with Postman's pm.* namespace, and the README does not document the full API, so anyone with a large existing Postman test suite should expect to rewrite assertions rather than port them. The collection runner supports data-driven runs from CSV or JSON files, configurable iteration counts, and JUnit or HTML report output. JUnit output is the piece that matters for CI, because most runners already parse that format. Scheduled monitoring is described as cron-based with desktop notifications and webhook alerts, and the README is explicit that it runs locally rather than on a hosted server. That is a real constraint: a local monitor only fires when the machine is awake and the application is running. If your team needs an alert at 3 a.m. from a machine that is not yours, this is the wrong tool, and a hosted monitor is the right one.

The plugin system and mock servers, and where the documentation thins out

Two features get a single line each. Mock servers are described as generated from your collections with Faker.js data, latency simulation and error injection, all local and without usage limits. The plugin system is listed as JS plus WASM, with no further detail in the README. That second one is the gap. A plugin system with no documented loading mechanism, no manifest format and no example plugin is a claim rather than a feature you can plan around. If extensibility is why you are considering ApiArk, open an issue asking for the plugin authoring guide before you commit. The mock server entry is more actionable because the inputs and the generated data source are named, but the README still does not say how a mock server is started, which port it binds, or how it is stopped.

Release cadence, maintenance cost and the MIT licence

The project is not archived and the last push is dated 2026-03-26. The three most recent releases are v0.4.6 on 2026-03-25, v0.4.5 on the same day, and v0.4.4 on 2026-03-24. Three releases inside two days at version 0.4.x suggests active development, and it also suggests that patch releases are frequent and small. For an adopter that means upgrade cost is low per release but the cadence is fast enough that pinning a version and reviewing changes before upgrading is sensible. The version number itself is a signal: 0.4.x is pre-1.0, so breaking changes to the YAML format or the scripting API are possible without a major version bump. Because collections are plain files, a format change would show up as a diff in your repository rather than as silent data loss, which is a meaningful safety property of the storage model. The licence is MIT, which permits commercial and closed-source use and modification. That is permissive, but MIT also disclaims warranty, and an API client that stores credentials in local YAML files puts the responsibility for secret handling on you. The README does not describe encryption at rest or a secret store, so check how environment variables and tokens are written before committing real credentials to a repository.

ApiArk against Bruno, and who should pick which

Bruno is the closest comparison because it shares the filesystem-first premise. Both store collections as files you can commit. The difference is the file format and the runtime. Bruno uses its own .bru format and an Electron shell; ApiArk uses standard YAML and Tauri v2. Standard YAML means other tools can read your collection without Bruno or ApiArk installed, which is an advantage if you generate requests from a script or want to lint them. Tauri means a smaller memory footprint and faster startup, at the cost of depending on each platform's webview, which can behave differently across operating systems. On protocol coverage the README marks Bruno as lacking WebSocket, SSE and MQTT, and ApiArk as supporting all three. If your work is HTTP and GraphQL only, that difference is irrelevant and Bruno's longer track record may be the better bet. If you are testing an MQTT broker and a REST API in the same session, ApiArk is the one that keeps both in a single window.

Editorial conclusion

Adopt ApiArk if your team already reviews code in Git and you want API collections to travel through the same pull-request flow, or if you need MQTT or Socket.IO in the same window as REST. Do not adopt it if you depend on cloud-hosted monitors, shared team workspaces with role management, or a Postman-style marketplace of published collections, because none of those appear in the README. Before committing, install the v0.4.6 build, import one real Postman Collection v2.1 export, and confirm that the resulting YAML files diff cleanly in your repository. Then check whether the collection runner's JUnit output plugs into your existing CI.

Official sources

1. berbicanes/apiark on GitHub
2. Issues
3. License: MIT
4. README
5. Releases