If you've used Postman lately, you've probably noticed the pattern: sign in to sync, workspaces in the cloud, your collections living on someone else's servers. For a lot of day-to-day API work — especially in QA and backend development — that's more machinery than the job needs, and for some teams it's a compliance problem.
Here's the workflow I've landed on: collections as plain JSON files on disk, versioned with git.
Why local-first?
- Your requests are code. If collections are plain, readable JSON files, they belong in the same repo as the API they test. Branch, diff, review, merge — the tools you already use.
- No account, no sync, no lock-in. Nothing leaves your machine. If a tool disappears tomorrow, your files are still there and still readable.
- QA and dev share one source of truth. The collection travels with the codebase, so "works on my machine" applies to test suites too.
What the workflow looks like
- A collection is just a folder. Each request is a small
*.rr.jsonfile; subfolders are folders.git initand you're done. - Environments (dev/staging/prod) are JSON files too, with
{{variable}}interpolation everywhere. - Pre/post-request JavaScript handles auth chaining and assertions:
// Post Response
rr.test('status is 200', () => rr.expect(rr.response.status).toBe(200));
rr.variables.set('token', rr.response.body.token); // flows to the next request
- For data-driven testing, a runner takes a CSV/JSON file and repeats the sequence once per row — each column becomes a
{{variable}}.
Tools
I build RestRuno (Windows/macOS/Linux), which is designed around exactly this workflow — plus Postman/Bruno/cURL import so you don't start from zero. Bruno shares the same local-first philosophy with a different file format. Whichever you pick, the point is the same: your API tests deserve version control, not a cloud account.
Disclosure: I'm the author of RestRuno. The core app is free; a couple of power features (AI assistant, data-driven runner) are a one-time purchase.
