Getting Started

Volley is a small Node server and some plain HTML/JS/CSS — clone it, run one command, and you have a full-featured local HTTP client.

Running it

Volley needs its local server — it's what reads/writes data/ and proxies outbound requests.

node server.js

Then open http://localhost:5874. No npm install, no dependencies — server.js only uses Node's standard library.

Install via npm

Prefer not to clone the repo? It's also published on npm:

npx @michaelyagi/volley
npx runs it from a temporary cache, so pass --data-dir=<path> (see below) to keep your collections in a permanent folder across runs — otherwise a fresh npx invocation may start from an empty data/.

Options

Use a different port — pass --port=<port> or set the PORT env var:

node server.js --port=3000

Sharing data/ (local-network sync)

By default Volley reads/writes data/ next to server.js. Pass --data-dir=<path> (or set VOLLEY_DATA_DIR) to point it at a different folder — e.g. a Dropbox/Google Drive folder, a network share, or a separate git repo — so multiple machines or teammates can work from the same collections, environments, and history:

node server.js --data-dir=/path/to/shared/volley-data

There's no real-time sync or accounts — it's the same wipe-and-rewrite-on-save model described in Data Storage, just pointed at a folder that something else (Dropbox, a sync tool, git) keeps in sync between machines. Avoid running two instances against the same data/ at the same time, since the last save wins.

Project structure

volley/
├── server.js               — stdlib-only Node server: static files + API endpoints
├── cli.js                  — headless Collection Runner (CI/CD)
├── lib/
│   └── headless-runner.js  — shared headless-run core, used by cli.js and Monitors
├── data/                   — gitignored; your collections, environments, history
├── config/                 — gitignored; server-side config (git.json, logs.json)
├── volley-sync/             — gitignored; local git clone managed by Git Sync
├── index.html              — markup only, no inline JS or CSS
├── css/                    — base, themes, sidebar, request, response, modals
└── js/                     — one file per concern; state.js loads first, app.js boots last

All JS files share the global scope and load in order — there are no modules, no bundler. See Testing & Development for the no-build-step philosophy.

Data Storage →