Apiflow turns a Postman alternative into a self-hosted server with a desktop client

One workspace for testing, mocking, WebSocket and SSE

The scope is wider than a request builder, and the feature list makes the boundaries clear. The core capabilities cover HTTP API testing for RESTful work with connection pooling and keep-alive reuse, WebSocket testing, a mock server that speaks HTTP, WebSocket and SSE, an environment and variable system, pre-request and post-request scripts, project and folder management, import and export in Postman, OpenAPI and JSON formats, and internationalization in English, Chinese and Japanese. The mock server supporting Server-Sent Events is the less common of those capabilities, and the project gives it its own preview section next to the AI agent, which suggests it is treated as a first-class feature rather than an afterthought. The people this is aimed at are the ones the README names in its comparison, developers used to Postman, Hoppscotch and Insomnia, and the team features, unlimited teams and members with project-level permissions, role-based access control and read, write and admin roles, are aimed at a shared workspace rather than a solo tool.

The AI agent is configured against a model you supply

The AI agent is a built-in feature for API design, testing and debugging, and the key property is that you configure your own large language model rather than using a hosted one tied to the project. The documentation says the agent works in offline or intranet environments, and the environment file makes that concrete. The DeepSeek settings are present as first-class configuration: DEEPSEEK_API_KEY, DEEPSEEK_BASE_URL pointing at https://api.deepseek.com and DEEPSEEK_MODEL set to deepseek-v4-pro. There is also a npm mirror switch, USE_NPM_MIRROR, which is set to false by default and controls whether the deployment installs from npmmirror.com rather than the default registry. The combination of a configurable model endpoint and a Docker deployment is what makes the intranetwork claim credible rather than aspirational, since the whole stack can run inside a network that has no route to a hosted model and no route to a hosted Postman.

The Docker deployment starts MongoDB, a server, a website and a web client

The compose file is where the architecture becomes concrete, and it runs four services. The mongo service uses a pinned image, xiaoxiaoshu/apiflow-mongo:6, with the root username, root password and database name injected from the environment and a named volume for the data directory, plus a healthcheck that pings the database with mongosh. The server service, xiaoxiaoshu/apiflow-server:latest, depends on the mongo service being healthy before it starts, and it takes the connection string, the deployment type, the email registration switch and the Aliyun DirectMail credentials. The website service, xiaoxiaoshu/apiflow-website:latest, listens on port 3000, and the web service, xiaoxiaoshu/apiflow-web:latest, depends on the server. The server healthcheck hits http://localhost:7001/api/health. So a deployment is a web front end, an API server, a marketing site and a database, which is a heavier footprint than a single binary but is what makes the team features possible.

First deployment: copy the env file, pull the images, check the health endpoint

The documented first deployment needs Docker and Docker Compose, and the sequence is short. You clone the repository, copy the environment file, edit it to configure the MongoDB credentials, pull the images, bring the stack up, and then verify it.

git clone https://github.com/trueleaf/apiflow
cd apiflow

cp .env.example .env
# edit .env to configure MongoDB credentials

docker compose pull
docker compose up -d

# Verify deployment
curl http://localhost
curl http://localhost/api/health

The environment file itself carries the security advice, which is worth reading. It says to copy the file to the project root as .env and not commit the real one to Git, to use strong secrets and store them in a platform secret manager in production, to use unique accounts and strong passwords, to enable backups and access control, to keep secrets out of the code, and to run containers with least privilege and consider read-only root file systems. The example values are placeholders, MONGO_ROOT_USERNAME=admin, MONGO_ROOT_PASSWORD=your_secure_password_here and MONGO_DATABASE=apiflow, so nothing useful ships by default. Adding the first users is a three-step procedure, and step two is the one to notice. You switch the application to Internet Mode using the network mode toggle, usually in the top-right corner, which enables the online features. You then log in with the default admin account, where the username is admin and the default password is 111111, and the documentation marks in bold that you should change the default password after the first login for security. You then go to the admin panel, find the user management section, and click Add User to create accounts for team members. The Internet Mode step is worth understanding, because the same product is designed to work local-first and online, and the toggle is what switches the two modes rather than being a deployment switch. The default credentials are the one genuinely sharp edge in the deployment documentation, since an instance exposed on a network with the default password still in place is a straightforward account takeover.

Updates and rollbacks are scripted, and the rollback is snapshot based

The deployment story extends past the first run, and the scripts in the repository root are the interesting part. If you run Apiflow with Docker, updating the code does not require rebuilding locally, and the recommended path is a script. The first time you need to make the scripts executable, then run the update script.

# Make scripts executable (first time only)
chmod +x update.sh rollback.sh

# Run update
./update.sh

The manual equivalent is a compose down, pull and up sequence.

docker compose down
docker compose pull
docker compose up -d

The rollback is where the design is careful. The recommended option is to roll back to the latest snapshot created by the update script, with an alternative that rolls back to a named snapshot file such as current_versions_20260122_120000.txt. There is also a compatibility mode that rolls back by tag or by commit sha, and the documentation is honest that it is not guaranteed to be exact and is meant for emergencies.

# Option 1: rollback to the latest snapshot created by update.sh (recommended)
./rollback.sh --previous

The presence of a reset_admin_password.sh script in the repository root is a reminder of the default credential problem above.

The Electron to Tauri move changes the desktop upgrade path

The download section carries a migration note that anyone on an older build needs to read carefully. Desktop releases from v0.9.82 use Tauri and Rust, and the instruction for upgrading from an Electron-based release is to back up your local data through Settings, Local Data, Data Backup / Export, then install the new package and restore the backup in the new client. The documentation also says to download the installer directly for this transition, because the new client uses a signed Tauri update feed. The underlying change is a shift in the desktop shell from a Chromium-embedding framework to a system webview, which is what makes the desktop binary smaller and the update feed signed, and it is also why the data has to move manually. For a team that has built workflows around the desktop app, the migration is a real chore with a real risk of losing local work if the backup is skipped, and the release list shows the pace, with v0.9.82 and v0.9.83 both published on 2026-10-15.

Building the desktop client needs Node 22, Rust and a native toolchain

Building the client yourself is the path for anyone who wants to point a desktop build at their own server. The prerequisites are Node.js 22.12.0 or newer, Rust 1.85 or newer with the native toolchain for the target platform, Xcode Command Line Tools on macOS via xcode-select --install, and on Linux WebKitGTK 4.1, AppIndicator, OpenSSL development packages, patchelf, fakeroot and dpkg. Each platform's installer can only be built on its native operating system, with no cross-platform compilation. The optional first step is a download speed-up, uncommenting the registry line in the root .npmrc, which the documentation shows as a properties block pointing at registry.npmmirror.com. After that you clone, install with npm, and edit packages/web/src/config/config.ts to change the backend server URL, where the default points at the official server and the development value is http://127.0.0.1:7001.

// Change the backend server URL
// Default points to the official server; replace with your own when self-hosting
httpRequest: {
  url: isDev ? 'http://127.0.0.1:7001' : 'https://your-server.example.com',
  // ...
},

The note that follows is the practical part, since it removes the need to rebuild for a URL change: after packaging, the server URL can be updated at any time in the app through Settings, App Config, API Endpoint.

Where Apiflow is the wrong choice

The first wrong case is a single developer who wants a desktop API client and nothing else, because the product is shaped as a client plus a server plus a database, and the collaborative features only make sense with the server running. The second wrong case is a team that will not operate MongoDB, since the compose file treats the database as a first-class service with credentials, a healthcheck and a volume, and that is a thing to run and back up. The third is anyone who needs a stable, slow-moving release train, because the tag list shows two releases on 2026-10-15 alone and a scheme at the 0.9.x level that signals a project still finding its shape. The fourth is a group that must guarantee its request history never leaves the organisation, where the bidirectional conversion between offline and online data is a feature and also a risk, since the same workspace can be synchronised to a hosted service if a user turns that on. The fifth is a team that needs a mature, widely used tool, because the honest comparison in the README lists Postman, Hoppscotch and Insomnia as the established alternatives, and choosing Apiflow is choosing the newer implementation.

Editorial conclusion

Teams that need Postman-style testing, mocking and OpenAPI work without a paid plan, and that need to run the tool inside a private network or an intranet where requests must not leave the organisation, are the people Apiflow is for, and the offline-first design with bidirectional conversion between local and online data is the part that distinguishes it from the hosted alternatives it names. It is the wrong tool for a single developer who wants a desktop client and nothing else, because the desktop application is paired with a server and a MongoDB instance, and it is the wrong tool for a team unwilling to own an update process, since the project ships several releases a month and moved the desktop client from Electron to Tauri at v0.9.82, which requires a data backup and restore. Check three things before you deploy it: that you change the default admin password of 111111 before anyone else reaches the instance, that you set the MongoDB credentials in .env rather than leaving the example values, and that the AI agent can reach the model endpoint you configure, since the environment file points DeepSeek at a specific base URL and model. The licence is MIT, the newest release is v0.9.83 from 2026-10-15, and the last push was on the same day.

Frequently asked questions

Official sources

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