# ApiArk Review: A Tauri v2 API Client That Stores Requests as YAML

> ApiArk is a local-first API client built with Tauri v2 that stores every request as a YAML file and requires no account. It covers REST, GraphQL, gRPC, WebSocket, SSE, MQTT and Socket.IO, and the README claims about 60 MB of RAM.

**berbicanes/apiark** — Privacy-first API platform built with Tauri v2. No login, no cloud, ~60 MB RAM. A lightweight Postman alternative.

- Repository: https://github.com/berbicanes/apiark
- Stars: 1,284 · Forks: 80
- Language: TypeScript
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/berbicanes-apiark

## What ApiArk Solves for API Work Outside the Browser

The README frames ApiArk against three costs that come with hosted API clients: an account requirement, cloud storage of request data, and memory use. The claim printed at the top of the README is that Postman uses 800 MB of RAM while ApiArk uses 60 MB, and the comparison table lists ApiArk at roughly 60 MB with a startup time under two seconds. Those are the project's own figures, not measurements taken here.

The audience is narrow but real. If your requests contain internal hostnames, staging tokens or customer payloads, a client that keeps everything in local files removes a category of review you would otherwise have to do before pasting a request into a cloud workspace. The README states plainly that there is no login and no cloud. Storage is the filesystem, and the format is YAML rather than a proprietary container.

The second audience is anyone who already versions API collections. ApiArk stores each request as a .yaml file and treats collections as directories, so a diff of a pull request shows the request change the same way it shows a code change. That is a workflow decision more than a feature decision, and it is the strongest argument in the README.

## How ApiArk Stores Requests and Runs Scripts

The architecture visible in the repository is a Tauri v2 desktop application with a TypeScript frontend and a Rust backend, organized as a pnpm workspace. The top-level package.json declares the workspace name apiark, marks it private, and delegates every script to a filtered package called @apiark/desktop. The repository layout shows apps/, packages/, packaging/, scripts/ and docs/ alongside turbo.json and pnpm-workspace.yaml, which indicates a monorepo split between the desktop app and shared packages.

Data flow is file-based. A collection is a directory, each request inside it is a YAML document, and the README describes the result as git-diffable. Import paths exist for Postman Collection v2.1 JSON, Insomnia, Bruno, Hoppscotch, OpenAPI 3.x, HAR and cURL, so the YAML files are produced by conversion rather than written by hand on day one.

Scripting runs in TypeScript with type definitions, and the README names the surface as ark.test(), ark.expect() and ark.env.set(). The collection runner executes whole collections with CSV or JSON data files, configurable iterations, and JUnit or HTML reports. Mock servers, scheduled monitoring and proxy capture are described as local, which is a deliberate contrast with cloud-only equivalents in the comparison table.

## Installing ApiArk with Homebrew, Scoop or APT

The README points to the latest GitHub release for direct downloads: an .exe installer or .msi on Windows, Apple Silicon or Intel .dmg on macOS, and .AppImage, .deb or .rpm on Linux. Package managers are also documented. On macOS the Homebrew tap is the shortest path.

```bash
brew tap berbicanes/apiark
brew install --cask apiark
```

On Windows, Scoop uses a bucket added from the repository, then a normal install. The README also notes availability on the Microsoft Store.

```bash
scoop bucket add apiark https://github.com/berbicanes/apiark
scoop install apiark
```

Debian and Ubuntu users run the published install script with sudo, then install the package from APT.

```bash
curl -fsSL https://berbicanes.github.io/apiark-apt/install.sh | sudo bash
sudo apt install apiark
```

Building from source requires Node.js 22 or newer, pnpm 10 or newer, a Rust toolchain and the Tauri v2 system dependencies. The workspace package.json enforces those versions through its engines field. After cloning the repository, install dependencies and run the Tauri build target.

```bash
git clone https://github.com/berbicanes/apiark.git
cd apiark
pnpm install
pnpm tauri build
```

For a first real use, the README's Postman migration path is the fastest way to get data into the app. Export a collection as Collection v2.1 JSON, open ApiArk, press Ctrl+K, choose "Import Collection" and select the file. The requests then exist as YAML files you own. The README does not document what happens to environment variables or scripts during that import, so verify the converted files before deleting the original export.

## Where ApiArk Is the Wrong Tool

The local-first design cuts both ways. There is no cloud sync, so a team that expects a shared workspace where a colleague's collection edit appears automatically will not get that here. Sharing means committing YAML to a repository and pulling it, which is a different coordination model and requires the team to already use Git well.

The README lists local mock servers and local scheduled monitoring as advantages over cloud-only equivalents, and for a single developer that is true. For a team that needs a mock endpoint reachable by a CI runner in another network, or monitoring that keeps running when your laptop is closed, a local process is the wrong shape. The README does not describe a hosted mode, so this is a boundary of the design rather than a missing setting.

Version skew is worth noting. The releases listed are v0.4.6, v0.4.5 and v0.4.4, all from March 2026, while the root package.json still carries version 0.2.28. The README does not explain how the workspace version relates to the release tag, so do not read the package.json version as the shipped version.

Maintenance is also a consideration. The last push to the default branch was on 2026-03-26, roughly six months before this writing. The repository is not archived, but the README does not document a support commitment or a release cadence, and the recent release history is concentrated in a few days.

## ApiArk Compared with Bruno on Storage Format

Bruno is the closest alternative and appears in the README's own comparison table. Both are desktop clients with no account requirement and filesystem storage, and both are described as git-friendly. The difference is the format. Bruno uses its own .bru file syntax, while ApiArk writes standard YAML.

That distinction matters when tooling touches the collection. YAML has parsers in every language and editors already highlight it, so a script that reads a request URL or rewrites an environment value does not need a Bruno-specific parser. The trade-off is verbosity: YAML is more repetitive than a purpose-built format, and indentation errors are a real failure mode when a file is edited by hand outside the app. The README does not state whether ApiArk validates a hand-edited YAML file or how it reports a malformed one, so that is worth testing on a scratch collection rather than on your main one.

The table also positions ApiArk against Hoppscotch, which the README lists as IndexedDB storage and optional account, and against Postman, listed as cloud storage with a required account. ApiArk's protocol list is broader than Bruno's in the README's table, which marks Bruno as lacking WebSocket and SSE. Treat the table as the project's own positioning, since no independent comparison is provided.

## Licence and the Cost of Keeping Up

ApiArk is released under the MIT licence, and the repository includes a LICENSE file at the top level along with SECURITY.md. MIT is permissive: it allows use, modification and redistribution, including in commercial settings, provided the copyright notice and permission notice are retained. That is the general shape of the licence, not legal advice, and a company with strict open source review should read the LICENSE file directly rather than rely on a summary.

Upgrade cost depends on how you installed it. Homebrew, Scoop and APT installations move with their package manager, so the update path is the same command you used to install. Direct .dmg, .msi, .AppImage and .deb downloads need to be replaced manually. Because requests live in YAML files on disk rather than in an application database, an application upgrade should not touch your collections, but the README does not document a migration step or a schema version field in the YAML, so keep collections in Git before upgrading. If a future release changes the file format, the diff will show it.

The repository contains a LAUNCH_CHECKLIST.md and a packaging/ directory, which suggests release packaging is a maintained part of the project rather than an afterthought. The README does not describe a deprecation policy or a minimum supported version.

## Conclusion

ApiArk fits engineers who keep API collections in Git and want a desktop client that does not require an account or upload request data. It is a poor fit for teams that depend on cloud-synced workspaces, shared hosted mocks or browser-only access, since the README describes local mock servers and local monitoring instead. Before adopting it, check the release page for your platform's installer and confirm the YAML layout of an exported collection matches the directory structure your repository already uses.

## FAQ

### What is ApiArk?

ApiArk is a desktop API client built with Tauri v2 that stores each request as a YAML file and requires no login or cloud account. The README describes it as a privacy-first, local-first API platform covering REST, GraphQL, gRPC, WebSocket, SSE, MQTT and Socket.IO.

### How do I install ApiArk?

The README lists direct installers on the latest GitHub release for Windows, macOS and Linux, plus package managers: a Homebrew cask on macOS, a Scoop bucket on Windows, and an APT repository for Debian and Ubuntu. Building from source needs Node.js 22 or newer, pnpm 10 or newer, a Rust toolchain and the Tauri v2 system dependencies.

### Can I import my Postman collections into ApiArk?

Yes. The README gives the steps: export the collection as Collection v2.1 JSON, open ApiArk, press Ctrl+K, choose "Import Collection" and select the file. The requests become YAML files, and the README also lists Insomnia, Bruno, Hoppscotch, OpenAPI 3.x, HAR and cURL as import sources.

### Does ApiArk require an account or send my requests to a cloud service?

The README states there is no login and no cloud, and that data storage is the filesystem in YAML. Mock servers and scheduled monitoring are described as running locally rather than on a hosted service.

### What is ApiArk written in?

The repository uses TypeScript with a Rust backend through Tauri v2, organized as a pnpm workspace. The root package.json delegates its scripts to a package named @apiark/desktop, and the topics list api-client, desktop-app, rust, tauri and typescript.

## Sources

- [berbicanes/apiark on GitHub](https://github.com/berbicanes/apiark)
- [Issues](https://github.com/berbicanes/apiark/issues)
- [License: MIT](https://github.com/berbicanes/apiark/blob/main/LICENSE)
- [README](https://github.com/berbicanes/apiark/blob/main/README.md)
- [Releases](https://github.com/berbicanes/apiark/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/berbicanes-apiark