Restfox: an offline-first HTTP and socket client you can self-host

What Restfox solves, and for whom

Most API clients assume a hosted account. Collections live on a vendor's servers, environments sync through a login, and the desktop app is a thin shell around that account. Restfox takes the opposite position. The README describes it as an "Offline-First Minimalistic HTTP & Socket Testing Client for the Web & Desktop", and the repository layout backs that up: there is no server component beyond the web-standalone package, and no authentication code in the top-level entries.

The audience is narrower than a general developer-tools audience. It is for engineers who test HTTP endpoints, GraphQL queries and WebSocket connections, and who want the request data to sit on their own disk. It is also for people who cannot install a desktop application on a managed machine but can open a browser tab, since the project ships a web build and a Docker image. The topics list on the repository names api-client, api-testing, graphql-client, http, rest-api, rest-client, testing-tools and websocket, which is a fair summary of the surface area. What it is not, based on everything present, is a load-testing tool or a mock server.

How the UI, the standalone web build and Electron fit together

The repository is a monorepo. The root package.json is private and contains no dependencies of its own; it is a set of script aliases that forward to three packages: packages/ui, packages/web-standalone and packages/electron. The scripts are named ui:dev, ui:build, ui:build-web, ui:build-desktop, web:start, electron:dev and electron:build, each one running the matching script inside the child package.

That split explains the deployment shapes. The UI package holds the Vue application and its CodeMirror editors; the README lists a maintenance command that upgrades the CodeMirror packages individually, which tells you the editor is composed from separate first-party modules rather than a single bundled widget. The web-standalone package is a small Node server that serves the built UI and, according to the Dockerfile, expects the compiled UI in its public directory. The Electron package wraps the same UI for desktop distribution, with makers for deb, rpm, squirrel, zip and flatpak listed in the upgrade command.

Data flow is local. Requests are issued from the browser or from the Electron process, responses are kept for the response history feature shown in the screenshots, and environment variables are stored alongside the collections. The docker-compose file mounts ./data into /app/data and comments that you should "use this path in the File Workspace folder path field", so in the containerised setup the collections are files on the host, not rows in a database.

Installing Restfox on macOS, Windows, Linux or Docker

The README gives a package manager for each desktop platform. On macOS, Homebrew carries it:

brew install restfox

On Ubuntu and other distributions with snap support, the command is:

sudo snap install restfox

On Windows, the package lives in the extras bucket for Scoop, so you add the bucket first and then install:

scoop bucket add extras
scoop install restfox

For RPM, DEB and NuPKG there are precompiled binaries on the releases page rather than a package manager entry. If you would rather not install anything, the Docker image is the shortest path:

docker run --name Restfox -d -p 4004:4004 flawiddsouza/restfox:0.40.0

The container listens on port 4004, and the README says to visit localhost:4004 once it starts. The compose file offers a variant with a named project and a custom host port, and a version override through an environment variable:

RESTFOX_VERSION=0.40.0 docker-compose up -d

After the app opens, the first real task is to create a request against an endpoint you control, save it into a collection, and point the File Workspace folder path at a directory you can back up. In the Docker case that directory is ./data on the host, mounted at /app/data. If you skip that step, your collections live wherever the app defaults to, and a container rebuild will not carry them across.

Where Restfox gets in the way

The offline-first design is also the main constraint. There is no account system in the repository, so there is no built-in way for two engineers to share a collection through the app itself. Sharing means sharing files, and the README does not document a merge strategy, a conflict resolution flow or a locking mechanism for a file workspace that two people edit at once. Teams that expect the client to be the collaboration layer will find that layer missing.

The documentation is another limit. The README points to docs.restfox.dev and to a video about plugins, but the README itself does not describe the plugin API, the scripting model, or how environment variables are scoped to a request versus a collection. The screenshots show environment variable screens and a context menu, yet the text gives no rules for precedence. If your workflow depends on computed variables or request chaining, confirm the behaviour in the app before you commit a team to it.

Finally, the desktop distribution depends on Electron makers for deb, rpm, squirrel, zip and flatpak. That covers the common Linux and Windows formats, but it does not mean every architecture is built for every release. The README directs RPM, DEB and NuPKG users to the releases page rather than to a repository, so availability is per release, not guaranteed.

Restfox compared with Postman and Bruno

The most common comparison is with Postman, and the difference is architectural rather than cosmetic. Postman is built around a cloud account: workspaces, team roles and sync are the product. Restfox is built around local storage and a file workspace, with a Docker image for teams that want a shared instance on their own hardware. If your organisation already pays for a hosted API platform, Restfox duplicates the request-building part and drops the collaboration part.

The closer comparison is with Bruno, which also stores collections as files on disk and markets itself on that basis. The difference visible in this repository is packaging. Restfox ships three delivery shapes from one codebase: an Electron desktop build, a web-standalone Node server, and a Docker image whose compose file mounts a data directory. That makes it easier to run as an internal web service behind your own reverse proxy. Bruno's distribution model is centred on the desktop application. Both avoid a hosted account; Restfox is the one designed to be served from a container.

Licence, maintenance and upgrade cost

The repository is MIT licensed, with the LICENSE file at the top level. MIT permits commercial use, modification and redistribution provided the copyright notice and permission notice are kept. That is a permissive position, and it means you can fork the UI package and ship an internal build without asking anyone. It says nothing about the names or logos, so if you redistribute a modified build, treat branding as a separate question and get your own advice rather than reading the licence as covering it.

Maintenance signals are mixed. The last push to the default branch was on 2026-07-03, and the most recent release listed is v0.40.0 from 2025-07-27, with v0.39.0 and v0.38.0 before it at roughly monthly intervals. The repository is not archived. The gap between the newest release and the latest commit suggests work continues between tagged versions, but there is no published release cadence, so you cannot plan upgrades against one.

Upgrading is cheap if you use a package manager, since Homebrew, Snap and Scoop all track the project. It is more work if you build the Docker image yourself: the Dockerfile pins node:19.8.1-alpine3.17 in both stages, and that base image will need attention long before the application code does. The compose file's default image tag is ${RESTFOX_VERSION:-0.14.1}, well behind the 0.40.0 shown in the README, so set RESTFOX_VERSION explicitly rather than relying on the fallback.

Editorial conclusion

Restfox fits engineers who want an API client without an account, and teams that prefer a self-hosted container over a hosted workspace. It is a poor fit if you need a shared cloud workspace, a team review workflow, or a client with a large plugin marketplace, since the repository shows no such features. Before adopting it, verify two things: that a package for your platform exists in the releases page or in Homebrew, Snap or Scoop, and that the file workspace path you mount is the one the app writes to, because the docker-compose file mounts ./data and expects that same path in the File Workspace folder path field.

Frequently asked questions

Official sources

1. flawiddsouza/Restfox on GitHub
2. License: MIT
3. Project website
4. README
5. Releases