Navop: a Rust and GPUI desktop workspace that puts databases, SSH, SFTP and RDP in one native app

The problem Navop addresses: connection sprawl across a dozen clients

Most engineers who work against remote infrastructure keep four or five applications open at once. A database GUI for MySQL or PostgreSQL, a terminal emulator for SSH, an SFTP client for moving files, a remote desktop viewer for the Windows box, and something else again for Redis or MongoDB. Each one has its own connection list, its own credential store and its own keyboard shortcuts. Navop's stated goal is to collapse that set into one native desktop application.

The README describes it as "a native, all-in-one workspace for databases, SSH, SFTP, terminals, remote desktop, monitoring, and AI agents." The intended audience is the operator who moves between those surfaces during a single debugging session: query a table, tail a log over SSH, pull a config file down over SFTP, then open an RDP session to the application server. Navop's answer is tabs inside one window rather than windows inside one taskbar.

The breadth is the point and also the risk. A tool that covers MySQL, Oracle, ClickHouse, Redis, MQTT, RDP and VNC in one binary is competing with specialists on every front at once.

How Navop is built: GPUI, Rust crates and a WASM extension runtime

The repository is a Cargo workspace. The root Cargo.toml lists default-members as main and then enumerates roughly sixty member crates, including crates/ssh, crates/sftp, crates/sftp_transfer, crates/terminal, crates/port_forwarding, crates/remote_desktop, crates/redis-runtime, crates/mongodb-runtime, crates/markdown-editor, crates/notes and crates/known_hosts_view. That layout is the clearest evidence of the architecture: each surface is a separate crate rather than a module inside one large binary.

The README states the UI is built with GPUI and Rust, with GPU-accelerated rendering and no WebView. That is the central design decision. An Electron or Tauri client renders HTML; Navop draws its own widgets. The practical consequence is that the app does not carry a browser engine, and the trade-off is that every control has to be implemented in Rust.

Extensibility runs through a set of extension crates: extension-runtime, extension-host, extension-driver, extension-protocol, extension-plugin-adapter, extension-wasm and extension-api. The README says the extension marketplace adds database drivers, remote desktop providers, document renderers, connection importers and external editors, and that first-party extensions are built and published from a separate repository, navop-extensions. The workspace also includes a submodule entry, navop-extensions, in the top-level listing.

For remote desktop, the README describes two backends. On Windows, a C++ host crate (windows_rdp_host) embeds the Microsoft RDP ActiveX control so sessions appear inside a Navop tab or a fullscreen window, and the native mstsc.exe client can also be launched. On other platforms, a pure-Rust IronRDP canvas backend renders RDP.

Installing Navop and running a first SSH session

The README's install section points at the GitHub releases page. There is no package manager command documented for Homebrew, winget, apt or cargo install, and the workspace sets publish = false, so the crates are not published to crates.io. The documented route is the release artifact for your platform.

If you build from source instead, the workspace manifest is the entry point. The default member is main, so a plain cargo run from the repository root builds and launches the application:

cargo run

The README does not document a release profile, feature flags or required system packages for that build, so treat the source path as the less-travelled one.

Once the app is open, the tab bar accepts ad-hoc SSH connections. The README states that quick open "supports ad-hoc SSH connections from the tab bar, so throwaway sessions no longer need a saved connection." That is the fastest way to see whether the native rendering approach suits you: open a terminal tab, connect to a host you already have credentials for, and check that a split pane and the quick-command bar behave the way your current terminal does.

For file work, the SFTP view is a separate surface rather than a panel inside the terminal. The README lists uploads, downloads, search, favorites, remote editing with configurable size limits and a default editor, drag-and-drop, ZMODEM transfer and server-to-server copy.

Where Navop is the wrong tool, and what the README does not say

The licence is the first thing to check. The repository's licence identifier is NOASSERTION. The README badge reads "Apache-2.0 plus supplementary terms," and the top level contains both LICENSE-APACHE and a separate NAVOP_LICENSE file. A supplementary-terms file next to an Apache-2.0 file usually means the Apache grant is conditioned on something else. Anyone who needs an unambiguously OSI-approved licence, or who wants to redistribute a modified build, should read NAVOP_LICENSE before going further. I am not going to characterise what those terms permit; the file is short and you should read it yourself.

The second gap is operational. The README does not document rollback, downgrade or migration of the local configuration between versions. The release cadence visible in the release history is rapid: v0.16.0 and v0.16.1 on 2026-09-05, then v0.17.0 on 2026-09-08. Three releases in four days at the 0.x stage means the on-disk format for connections, notes or extension state may move. If you cannot tolerate a config reset, pin a version.

The third gap is performance evidence. The README claims GPU-accelerated rendering. It publishes no benchmarks, no memory figures and no startup timings, so the claim is a statement about the rendering path, not a measured result. Whether a native GPUI client feels faster than your current terminal is something you can only settle on your own hardware.

Finally, breadth cuts against depth. A dedicated ClickHouse client will have query profiling and cluster tooling that a general workspace does not. Navop lists ClickHouse, TDengine, IoTDB, Dameng DM, KingbaseES, GBase 8s, OceanBase, openGauss and Oscar among its targets, and several of those arrive through extension drivers rather than the built-in set. If your daily work is deep in one of those engines, check the extension's coverage before assuming parity.

Navop compared with DBeaver and with a terminal multiplexer setup

The obvious comparison is DBeaver. DBeaver is a Java application built on Eclipse RCP, and its centre of gravity is the database client: a large JDBC driver catalogue, SQL editing, ER diagrams and data transfer. Navop also does SQL editing, execution plans, import and export, schema and data comparison, and ER diagrams, which the README lists under its database features. The difference is what surrounds the database. DBeaver's SSH tunnelling exists to reach a database; Navop's SSH, SFTP, port forwarding, Telnet and serial support are first-class surfaces with their own views, session recording, broadcast input and a Known Hosts page. If your database work is the whole job, DBeaver's maturity is hard to argue with. If the database is one stop on a route through the host, Navop's shape fits better.

The second comparison is the assembled approach: a terminal emulator plus tmux plus an SFTP client plus a separate RDP viewer. That stack is free, scriptable and battle-tested, and each piece can be replaced independently. Its cost is that nothing is shared. Connection metadata lives in four places, and moving a file from an SFTP pane into an editor inside a remote session is a manual sequence. Navop's bet is that the integration is worth more than the independence. That bet only pays off if you actually use several of the surfaces; installing a sixty-crate workspace to run one MySQL query is a poor trade.

Maintenance, release cadence and upgrade cost

The repository is not archived, and the last push was on 2026-09-10. The release history shows v0.16.0 and v0.16.1 on 2026-09-05 and v0.17.0 on 2026-09-08, so the project is moving quickly at the 0.x stage. Fast movement is good for coverage and bad for stability guarantees.

The upgrade cost has three parts. First, the application binary, which the releases page supplies per version. Second, extension compatibility: the workspace separates extension-host, extension-protocol and extension-runtime, which suggests a versioned contract between the app and its extensions, and the README points to the navop-extensions repository as the source of first-party extensions. A protocol bump can leave an extension behind. Third, local state: connections, notes, themes and known hosts all live somewhere on disk, and the README does not describe a schema version or a migration step.

The licence situation adds a different kind of cost. With LICENSE-APACHE and NAVOP_LICENSE both present and the repository identifier set to NOASSERTION, a company that scans dependencies for licence compliance will flag this repository and ask a human to read the terms. Budget for that conversation before you standardise a team on it.

Editorial conclusion

Adopt Navop if you already juggle a database client, an SSH terminal, an SFTP browser and a remote desktop viewer and want one native process on Linux, macOS or Windows, and if the databases you touch are on the supported list. Do not adopt it if you need a documented rollback path, a plain OSI licence, or a tool with published benchmarks. Before installing, open the LICENSE-APACHE and NAVOP_LICENSE files in the repository and read the supplementary terms, then check the releases page for your platform's artifact.

Frequently asked questions

Official sources

1. feigeCode/navop on GitHub
2. Issues
3. Project website
4. README
5. Releases