Top lightweight CLI tools for development

Most of a backend developer’s day is small, fast loops. Fire a request at an endpoint, read the JSON, tweak, repeat. Reach for a heavy GUI for that and you spend more time waiting for it to load than doing the work.

Lightweight CLI tools flip that. They ship as a single binary or an npx-able package, start in well under a second, and do one job without a config wizard. You wire them into shell scripts and CI jobs, and they stay out of your way. For API and backend work, a small kit of these covers most of the loop: sending requests, parsing responses, exposing a local port, and running your test suite.

This guide picks ten that earn a spot on a backend developer’s PATH. Each section shows the one command that proves it working. The theme is footprint: what installs fast, starts fast, and asks for almost nothing before it’s useful. For the bigger picture of how these fit together, the guide to API development sets the context.

What makes a CLI tool “lightweight” for development

Lightweight is about footprint and friction, not how many features a tool crams in. When you’re deciding what belongs in your kit, weigh four things:

• Install size and shape. A single static binary or a small npx package beats anything that pulls a runtime and a lockfile behind it.
• Startup speed. The tool should be running before you’ve switched back to your editor. Rust and Go binaries cold-start in milliseconds, which matters when you call them in a loop.
• Config to first result. Zero config to a useful default is the bar. If it needs a project file, an account, and a dashboard first, it’s not lightweight.
• Composability. It reads stdin, writes stdout, sets a real exit code, and pipes into the next tool. That’s what makes a small tool worth more than its size.

The tools below run roughly from smallest and most single-purpose to the fuller ones. curl is already on your machine; the rest are a quick install away.

curl

curl is the baseline every other HTTP tool measures against. It’s on nearly every machine already, speaks every protocol you’ll touch, and does exactly what you tell it. For a quick check that an endpoint is alive, nothing is faster to reach for.

curl -s -X POST https://api.github.com/repos/curl/curl/issues \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"title":"Test issue"}'

The -s silences the progress meter so the response pipes cleanly. Add -i to see headers, -w '%{http_code}' to print just the status code, and --fail to make curl return a non-zero exit on a 4xx or 5xx, which is what you want inside a CI check.

Best for: scripting, CI health checks, and any request you want to copy-paste and share. A curl command works on any teammate’s machine.

Honest limits: the flag syntax is dense and JSON body handling is manual. For quick interactive requests, the next two tools are friendlier.

HTTPie

HTTPie (http) is curl with the sharp edges filed off, built for humans typing requests by hand. JSON is the default, output is colorized and formatted, and you build a request from simple key=value items instead of remembering flags.

http POST httpbin.org/post name=apidog role=api-tool active:=true

That sends a JSON body of {"name": "apidog", "role": "api-tool", "active": true}. The = sets a string, := sets a raw JSON value, and header:value sets a header. No quoting a JSON blob, no -H and -d bookkeeping. The response comes back pretty-printed.

Best for: interactive API exploration where readability wins.

Honest limits: it’s a Python package, so it cold-starts slower than a native binary and needs Python on the machine. If startup speed matters, use xh.

xh

xh is HTTPie’s syntax in a single Rust binary. It reimplements HTTPie’s request-item style, so name=value and := work the same, but it ships as one statically-linked file with no runtime and starts about 30% faster. It also supports HTTP/2 and HTTP/3.

xh POST httpbin.org/post name=apidog age:=24

Same ergonomics as HTTPie, near-instant startup. Because it’s a single binary with no dependencies, it drops into a slim CI image or a container without pulling Python along. The xh project on GitHub ships prebuilt binaries for Linux, macOS, and Windows.

Best for: developers who like the HTTPie feel but want native speed and a zero-dependency install for scripts and containers.

Honest limits: it covers the common HTTPie surface, not every last plugin. For nearly all request work that gap never shows up.

jq

jq makes every other HTTP tool more useful. It’s a single binary that filters and reshapes JSON on the command line, so you can pull one field out of an API response instead of eyeballing the whole blob.

curl -s https://api.github.com/repos/stedolan/jq | jq '.stargazers_count'

That prints just the star count. jq has a full query language: .items[] | .name maps over an array, select(.active) filters, and -r gives raw output with no quotes so you can pipe it into a shell variable. It’s the glue between an API call and the rest of your script.

Best for: extracting and transforming fields from JSON responses in scripts and CI.

Honest limits: the query syntax has a learning curve, and deeply nested transforms get cryptic. For simple field access it’s trivial.

gh (GitHub CLI)

gh brings GitHub’s API to your terminal without you writing a single curl call against it. It handles auth once via gh auth login, then wraps pull requests, issues, releases, and repos in plain commands. For backend teams whose deploy and review flow lives on GitHub, it removes a browser tab from the loop.

gh pr create --title "Add rate limiting" --body "Closes #42" --base main

That opens a PR from your current branch. gh pr checks watches CI, gh run watch follows a workflow live, and gh api gives you an authenticated, paginated client for any endpoint the wrapped commands don’t cover.

Best for: scripting GitHub itself: opening PRs from CI, cutting releases, and querying the API without managing tokens by hand.

Honest limits: it’s GitHub-only, so a GitLab or Bitbucket shop gets nothing from it.

ngrok

ngrok exposes a local port to a public URL over a secure tunnel. Building a webhook handler, or need someone to hit your dev server from outside your network? It turns localhost into a shareable link in one command. The agent is a zero-dependency binary that runs anywhere.

ngrok http 8080

That forwards a public https:// URL to your local port 8080 and prints it in the terminal. It also runs a traffic inspector at http://127.0.0.1:4040 where you can replay every request that came through, which is a real time-saver when you’re debugging a payment or Git webhook you don’t control.

Best for: webhook development, sharing a work-in-progress with a teammate, and testing third-party callbacks against local code.

Honest limits: it’s a commercial service with a free tier; the free plan rotates your URL each session and rate-limits it. For steady local HTTPS with a fixed name, use mkcert instead.

mkcert

mkcert makes locally-trusted HTTPS certificates with zero config. Written in Go by Filippo Valsorda, it’s a single binary that creates a local certificate authority, installs it into your system trust stores, and issues certs your browser accepts without a warning. That’s how you run https://localhost locally without the scary red padlock.

mkcert -install
mkcert localhost 127.0.0.1 myapp.local

The first line sets up the local CA once. The second issues a cert and key for the names you list, ready to hand to your dev server or reverse proxy. No OpenSSL incantations, no self-signed certificate you click past every reload. Testing OAuth redirects, secure cookies, or anything that behaves differently over HTTPS gets a lot easier.

Best for: getting real, trusted HTTPS on a local dev environment so it matches production.

Honest limits: it’s for development only. Never use mkcert certs in production, and guard the root CA key it generates; it can sign for any name on your machine.

watchexec

watchexec re-runs a command whenever files change. It’s a single Rust binary that watches a directory and restarts your server or reruns your tests the moment you save. It respects .gitignore by default, so it won’t fire on build artifacts.

watchexec -e py -r 'pytest tests/'

The -e py filters to Python files, and -r restarts a long-running process instead of stacking new ones. Point it at any command: watchexec -r 'go run .' for a Go server, watchexec 'npm test' for a JS suite. It’s language-agnostic, so one tool covers every project instead of a per-stack watcher.

Best for: tight edit-run loops on a local server or test suite, without a framework-specific watch mode.

Honest limits: it watches and reruns; it doesn’t do hot-module reload or preserve in-process state.

Docker CLI

The Docker CLI is the heaviest tool here, and it earns the spot. When you need a real Postgres, Redis, or a whole dependency for local development, one docker run gives you a disposable instance to throw away when you’re done. No system-level install, no leftover services.

docker run --rm -e POSTGRES_PASSWORD=dev -p 5432:5432 postgres:16

The --rm deletes the container on exit, -e sets the password, and -p maps the port to your host. Your app connects to localhost:5432 and you get a clean database every run. Swap postgres:16 for redis:7 or any image and the pattern holds.

Best for: spinning up backing services for local dev and integration tests, reproducibly, without polluting your machine.

Honest limits: it’s not lightweight in the binary sense; it needs a running daemon and real disk and memory. But the CLI is scriptable and terminal-first, and for reproducible local infrastructure nothing else is close.

apidog-cli

Once you’re doing API work at the command line, the missing piece is your actual API project: its endpoints, schemas, environments, and test scenarios. Apidog ships apidog-cli, the lightweight CLI that connects the terminal to that project. It installs as one npm package and gives you a scriptable path to design, import, mock, and test resources without opening the desktop app.

npm install -g apidog-cli
apidog login --with-token <YOUR_TOKEN>
apidog run -t <scenario_id> -e <env_id> -r cli

apidog run executes a saved test scenario against an environment and prints a step-by-step result in the terminal. It exits 0 when every assertion passes and non-zero on failure, so it drops straight into a CI gate. Beyond tests, the CLI covers real command groups: endpoint and schema for design, import and export for moving specs (OpenAPI, Swagger, Postman) in and out, mock for mock expectations, and environment and variables for config. Output is structured JSON with agentHints.nextSteps, which is why it also fits AI coding assistants doing API development. For the full command reference, see the complete Apidog CLI guide; the Apidog CLI installation guide walks through the first run.

Best for: running your test scenarios in CI and managing project resources from scripts, especially in a spec-first API development workflow where the contract drives everything.

Honest note: Apidog isn’t open source; it’s a commercial product with a free tier. But that free tier plus the CLI gives you an integrated alternative to stitching a request client, a mock server, and a test runner together yourself, all backed by one project. The lightweight piece is the apidog-cli binary; the full Apidog platform is a GUI on top of the same project.

How to choose

Most of these are complementary, not competing. You’ll likely run several: an HTTP client, jq, a tunnel, a watcher, and a test runner.

Pick by the job. Sending requests: xh or HTTPie for interactive work, curl for scripts. Reading responses: always jq. Exposing a port: ngrok. Local HTTPS: mkcert. Rerunning on save: watchexec. Backing services: Docker. Running your API tests and managing the project: apidog-cli.

Wrapping up

A good lightweight kit is a handful of small, fast tools that each do one thing and pipe into the next. curl and xh send requests, jq reads them, ngrok and mkcert handle local access, watchexec closes the edit-run loop, and Docker gives you throwaway infrastructure. None of them ask for much before they’re useful.

apidog-cli is the piece that ties the loop back to your actual API project, so the endpoints and tests you run from the terminal are the same ones your team designs and ships. Download Apidog to set up a project, then drive it from the command line with the CLI in your CI pipeline. Same speed-and-footprint idea, applied to the whole API lifecycle instead of one request at a time.