Cyber API is a native HTTP API client written in Rust and rendered with GPUI, the GPU-accelerated UI engine behind the Zed editor, aimed at developers and teams who test REST, GraphQL, gRPC, WebSocket and server-sent-event APIs and who want the same application on the desktop and as a self-hosted web version.

What it is

Cyber API is a desktop application for macOS, Windows and Linux that is built in Rust and drawn by GPUI, with no Electron and no web view. The same codebase also compiles to WebAssembly and is served by cyberapi-bridge, a single binary that keeps accounts and projects in PostgreSQL or MySQL and sends the page's requests on the user's behalf. That gives a team one application in two forms: a native client installed from Releases, and a web version running on its own infrastructure.

The concrete problem it addresses is the weight and the lock-in of collection-based API clients. Because GPUI draws on the GPU, a project containing thousands of APIs opens at once, and every kind of API a modern backend exposes — REST, GraphQL with schema completion, gRPC from server reflection or .proto files, WebSocket, event streams — is handled in the same window. It is positioned as a replacement rather than an addition: anyone coming from Postman, Insomnia, Hoppscotch, Bruno or Swagger can import the collection or paste a cURL command. The project lives in the Rust and GPUI ecosystem, and its topic list still records tauri, reflecting the earlier Tauri build that the install notes describe moving away from.

Key capabilities

• Sends REST, GraphQL with schema completion, gRPC from server reflection or .proto files, WebSocket and server-sent event requests from one client.
• Breaks a request down into DNS, TCP, TLS and server time, shows the request exactly as it went out, and renders JSON as a tree or queries it with JSONPath.
• Runs the same checks from CI through cyberapi-cli, alongside the history kept in the application.
• Switches environments next to the project name, inherits auth from a folder, chains a response with {{g(api, data.token)}}, and follows an OpenAPI source while the values and secrets already typed stay in place.
• Serves a self-hosted web version from the same code, where the desktop app signs in, works offline and syncs when the user chooses.
• Exposes APIs to MCP clients such as Claude Code and Cursor with secrets masked, sending them only when allowed.

Who uses it and how

• Individual developers on macOS, Windows or Linux who download a build from Releases and let the app check for new versions itself.
• Teams that run the web version behind nginx with HTTPS, point CYBERAPI_BRIDGE_STORE at PostgreSQL or MySQL, create the first administrator with the setup token printed in the log, and invite everyone else.
• Projects large enough that opening thousands of APIs at once is the deciding factor, where GPU rendering replaces a web view.
• Pipeline authors who reuse the application's checks from cyberapi-cli rather than reimplementing them.
• Existing users of the Tauri build following the install notes to move across.

Getting started

Download the macOS, Windows or Linux build from Releases, or run the web version with docker run -p 7380:7380 -e CYBERAPI_BRIDGE_STORE=postgres://user:password@host:5432/cyberapi vicanso/cyberapi-web from Docker Hub for linux/amd64 and linux/arm64. The deployment guide covers Docker Compose, the binary under systemd, HTTPS behind nginx including a sub-path, upgrades and backups.

How it compares

Against the clients whose collections it imports — Postman, Insomnia, Hoppscotch, Bruno and Swagger — Cyber API is released under Apache-2.0 and can be self-hosted, so accounts and projects stay in the operator's own PostgreSQL or MySQL rather than in a vendor's service. The desktop and web versions come from one codebase, and the CLI reuses the same checks, so there is no separate server product to license or reconcile.

When to use it — and when not to

Choose it when a native client and an in-house web deployment are both wanted and the team is prepared to operate a database plus TLS, since the login cookie is Secure and only --insecure-cookie relaxes that for plain HTTP. Building the web version from source also requires the nightly toolchain with wasm32-unknown-unknown, wasm-pack and wasm-opt, which is a real cost for anyone who cannot use the published image. Teams without the appetite to run PostgreSQL or MySQL should stay with a hosted client.

docker run -p 7380:7380 \
  -e CYBERAPI_BRIDGE_STORE=postgres://user:password@host:5432/cyberapi \
  vicanso/cyberapi-web

make dev            # run the desktop app (a debug build uses its own database)
make lint           # fmt check and clippy, as CI
make test           # every test
make desktop-dist   # package for this machine (cargo install --locked cargo-bundle@0.11.0)

make db-up          # PostgreSQL and MySQL in local containers (Apple's `container`)
make web-bundle     # build the page
make bridge         # http://127.0.0.1:7380/, setup token `dev`
make check-web      # the wasm build's check
make web-dist       # the deployment tarball; `make docker` builds the image