Firecamp: an AGPL-3.0 multi-protocol API client for REST, GraphQL, WebSocket and Socket.IO

What Firecamp is and the gap it targets

Firecamp describes itself as a dx-first API development platform and, in the README subtitle, as an "Open Source Postman Alternative". The stated problem is tool sprawl. The philosophy section argues that "the decentralization of tools, processes, and people creates friction in API development workflow" and that developers lose time switching between applications. The target user is a backend, frontend or mobile engineer who works across more than one protocol and wants collections shared with teammates rather than kept in a personal scratch pad.

The protocol list is the concrete part of the pitch: REST, GraphQL, WebSocket and Socket.IO each get a dedicated GUI playground, and the README claims WebSocket and Socket.IO coverage is where the tool stands apart. That is a narrower and more defensible claim than "Postman alternative" in general. If your day is HTTP requests plus JSON assertions, Firecamp is one of many options. If you also debug socket event streams and want those sessions in the same workspace as your REST calls, the overlap between the two is smaller.

How the repository is laid out and how the client runs

The project is a pnpm workspace. The root package.json declares "private": true and a preinstall hook of "npx only-allow pnpm", so npm and yarn installs are rejected before dependencies resolve. Top-level entries include packages/, platform/, playgrounds/, webpack.common.js, webpack.dev.js and webpack.prod.js, which is the shape of an Electron-style desktop app plus a web build rather than a library you import.

The build pipeline is explicit about which packages must exist before the app can start. The build:workspace script filters on four packages: @firecamp/scripts, @firecamp/rest-executor, @firecamp/ws-executor and @firecamp/socket.io-executor. The executor naming is the useful signal here. Each protocol has its own executor package, so request execution is separated from the UI layer that renders the playground. The dev script runs pnpm boot first, then runs build:workspace and webpack:dev in parallel via run-p. The .env.example file points the client at one backend: FIRECAMP_API_HOST="https://api-development.firecamp.dev" alongside NODE_ENV="development". That host is Firecamp's own API, which tells you collections and workspace state are server-backed in this configuration, not purely local files.

Installing Firecamp and sending a first REST request

The README's getting-started path is not a local install. It says to sign in at firecamp.dev, follow the Getting Started guide at firecamp.io/docs, and begin testing. For the desktop build, the README lists four direct downloads: Firecamp for MacOS Intel, MacOS Silicon, Windows and Linux AppImage, each behind a short link such as https://fcamp.co/mac and https://fcamp.co/linux-appImage. There is no package-manager install line for the desktop client in the README.

Running from source is a different route and the root package.json is the only place that documents it. Because of the preinstall guard, use pnpm:

pnpm boot

That runs pnpm install --shamefully-hoist. The shamefully-hoist flag flattens the dependency tree into the root node_modules, which is a common workaround for tooling that cannot resolve pnpm's strict layout. Expect a large download and a flat node_modules afterwards.

To start the development build, the dev script chains the install, the four workspace builds and the webpack dev server:

pnpm dev

The README does not document a port for the dev server, so read the webpack.dev.js configuration in the repository root if you need to know what webpack serve binds to. After the server starts, the app loads against the host in .env.example. If you want to point it elsewhere, copy .env.example to your own env file and change FIRECAMP_API_HOST before starting.

A first real use is the REST playground. The README links it at firecamp.io/docs/rest/introduction and describes it as a "lightweight, IntelliSense, and next-generation testing client". You create a request, set the method and URL, and send it. To reuse values across requests, the environment documentation at firecamp.io/docs/platform/environment covers dynamic variables, and the scripts documentation at firecamp.io/docs/platform/scripts covers pre-request and test scripts. The README does not publish the exact variable syntax, so treat the docs site as the reference rather than guessing at a template format.

Where Firecamp stops short: roadmap versus shipped features

This is the most important thing to check before you commit a team to it. Four items that competing clients treat as core sit under Roadmap in the README, not under Features: self-hosted deployment, CLI and CI/CD, the API test runner, and API documentation publishing. The same list includes SSL custom certificates, proxy setup and history tracking.

The practical consequence is that collection tests cannot be executed from a pipeline using anything the README documents. If your quality gate is a command in a CI job, Firecamp is the wrong tool today, regardless of how good the playgrounds are. The test runner being unbuilt also means script-based assertions live inside the GUI, so a passing test is something a person observes rather than something a build records.

The second limitation is data location. With FIRECAMP_API_HOST pointing at a Firecamp-operated API and the getting-started flow built around signing in at firecamp.dev, workspace and collection state is tied to that account and service. Self-hosting is a roadmap item, so there is no documented way to keep collections entirely on your own infrastructure. Teams with data-residency constraints should treat this as a blocker rather than a preference.

The third is release cadence. The newest release listed is v3.3.0-beta.3 from 2024-03-04, and it is a beta. The last stable tag in the release list is v3.2.3 from 2023-10-20. The repository's last push is 2026-03-04, so work has continued on main, but the release channel has not produced a stable tag in a long time. Anyone who wants a stable, versioned artifact should confirm on the releases page what they are actually installing.

Firecamp compared with Postman and Insomnia

The README names Postman directly in its subtitle, so the comparison is fair. Postman is a hosted platform with a mature CLI and collection runner, and its free tier is a hosted service. Firecamp is AGPL-3.0 and open source, which means the client code is readable and modifiable, but the README's own architecture points at a Firecamp-operated backend for workspace data. Open source client, hosted service: those are two different axes, and Firecamp is open on one and not the other.

Insomnia is the closer comparison in shape. It is a desktop API client that also covers REST and GraphQL in one window, and it has a plugin system. Firecamp's differentiator in the README is protocol breadth in the GUI: WebSocket and Socket.IO playgrounds that let you watch emitter and listener events over a bidirectional connection, described as the "only GUI client to test, debug, and visualize real-time or event-driven messages collaboratively". If your work is event-driven APIs, that is a real gap in most REST-first clients. If your work is HTTP-only, the difference narrows to interface preference and licence.

The honest summary is that Firecamp's approach is to win on developer experience and protocol coverage inside the app, and to defer the automation surface. Postman and Insomnia both ship automation today. Firecamp's README says it intends to.

Licence, upgrade cost and what the AGPL-3.0 tag means here

The repository licence is AGPL-3.0. The root package.json has an empty "license" field, which is a small inconsistency worth noting: the LICENSE file at the repository root is the authoritative text, not the package manifest. This is not legal advice, and the distinction matters most if you plan to modify Firecamp or offer it to others as a service. The AGPL's network clause is the part teams usually need to read carefully, because running a modified version as a network service carries obligations that the MIT and Apache licences used by some other clients do not.

Upgrade cost is where the beta channel bites. If you install from the direct download links, you are taking whatever build those links serve, and the README does not describe an auto-update mechanism or a versioned release channel. The release list shows a beta tag as the most recent entry, so pinning to a known-good version means tracking tags yourself. For a source build, the upgrade path is a git pull followed by pnpm boot and pnpm dev or pnpm build, and the four executor packages rebuild as part of that. Expect the install step to be slow on a fresh clone because of --shamefully-hoist and the workspace build chain.

Editorial conclusion

Firecamp fits a backend or full-stack team that tests REST, GraphQL, WebSocket and Socket.IO endpoints and wants those collections shared in one workspace instead of four tools. It does not fit a team whose API testing happens in CI, because the README lists CLI and CI/CD, the test runner, self-hosting and API documentation under Roadmap rather than under Features. Before adopting, check the releases page for the newest non-beta tag against the 3.3.0-beta.3 build, confirm that your workspace data lives on Firecamp's servers rather than locally, and read the AGPL-3.0 text yourself if you plan to modify or redistribute the client.

Frequently asked questions

Official sources

1. firecamp-dev/firecamp on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases