OpsKat: a Wails desktop workbench that puts SSH, databases and an AI agent behind one window

The tool sprawl problem OpsKat is built around

The README opens with the situation it targets: managing servers means juggling a pile of tools, SSH clients, database GUIs, Redis managers and Kafka consoles, and switching between them. OpsKat's answer is a single cross-platform desktop application that holds all of those asset types in one tree-structured grouping. The intended user is an operations engineer or SRE who touches several of these systems in a working day and would rather not maintain five sets of connection profiles. The secondary pitch is an AI layer: you describe what you need in natural language and an agent uses registered tools to pull logs, run SQL or check cluster status. That second layer is the part worth scrutinising, because it changes the trust model. A terminal client that only opens sockets is a different proposition from one that can be instructed in prose to execute operations against production systems.

What actually sits in the asset tree

The supported asset table is broad. Under servers and terminals: SSH, VNC, RDP, local terminal and serial. Under databases: MySQL, PostgreSQL, SQL Server, SQLite, Redis, MongoDB and etcd. Middleware covers Apache Kafka and Kubernetes. Object storage is listed as S3-compatible, cloud providers and self-hosted. The README notes that more asset types are on the way via a plugin system, and the repository topics include dsh-plugins, which suggests plugin support is a live part of the codebase rather than a roadmap line. The feature list under the workbench heading goes deeper than the table: split-pane terminals with themes, an SFTP browser, jump host chains, a SQL query editor and data browser, Redis command execution with a key browser, MongoDB collection browsing, Kafka management covering topics, messages, consumer groups, ACLs, Schema Registry and Kafka Connect, an object-storage browser with presigned URLs, port forwarding and SOCKS proxying. Import paths exist for SSH config, Tabby, WindTerm, .rdp files and RDP Excel templates, which is a practical detail: it means an existing tool's configuration is not a reason to stay.

How the AI agent is wired to the rest of the app

The README describes the agent as using registered tools, and states that applicable operations use their policy and approval paths, with tool calls carrying an audit trail and decision context where available. The hedged phrasing matters. Where available is doing real work in that sentence, and the documentation supplied here does not enumerate which operations are gated by policy, what an approval path looks like in the UI, or where the audit trail is written. What can be said from the material is the shape of the design: the agent is not given a shell. It is given a set of named tools corresponding to operations the application already knows how to perform, and those tools are the interception point for policy and approval. That is a more defensible architecture than handing a model an SSH session, because the blast radius is bounded by the registered tool list. It is also a constraint: anything without a tool cannot be done by the agent, no matter how it is phrased. The AI layer is optional. The README lists configuring an AI provider as step three of first run, marked optional, and describes OpsKat as a full-featured terminal and asset manager even before the AI is turned on.

Install and first run

The installation path is a download from the GitHub Releases page for macOS, Windows or Linux. The README is explicit that no Go or Node toolchain is required: download and run. Step-by-step notes live at opskat.dev/docs/getting-started/installation. First run is three steps. Add an asset, which can be an SSH or RDP host, a database, an object-storage account, Redis, or an import from SSH config, Tabby, WindTerm, .rdp or Excel files. Connect, which means opening a terminal or remote desktop, running a query, or browsing keys, collections, buckets and objects. Then optionally configure an AI provider. Because the project is Go and React behind Wails v2, the release artefacts are prebuilt desktop binaries rather than something you compile. The README does not document a package-manager install (no brew, apt or winget line appears in the supplied material), so treat the Releases page as the supported channel unless the installation docs say otherwise. The repository also publishes a nightly tag alongside stable ones, most recently v1.13.4-nightly.20260909 against stable v1.13.4, so there is a deliberate pre-release channel for people who want fixes ahead of a tagged release.

Proxy chains and the layered connection model

The proxy chain section is the most concrete piece of engineering detail in the README. SSH and remote data assets can use an ordered chain when direct access is not enough, and a chain may combine three layer types. SSH tunnel layers reuse an existing SSH asset as the next hop, which means a jump host you have already configured is addressable by name rather than re-specified. SOCKS5 proxy layers carry optional username and password authentication. HTTP script tunnel layers are described as compatible with DBX-style tunnel scripts, taking a URL plus a token. The ordering is the point: the chain is composed, not selected, so a connection can traverse a SOCKS5 proxy into an SSH tunnel into the target. For anyone who has maintained a separate jump-host configuration per database client, this is the feature that justifies the consolidation argument. The README does not describe failure behaviour when an intermediate hop in the chain is unavailable, nor whether chains are shared between assets or defined per asset, so those are things to check in the docs before standardising on it.

Where OpsKat is the wrong tool

The honest limitation is the one the product's own framing creates. Consolidation means one application holds credentials for your SSH hosts, databases, Redis instances, Kafka clusters and object-storage accounts, protected by what the README calls encrypted credential storage. That is a single point of compromise, and the README does not state how the encryption key is derived, whether it is protected by an OS keychain, or what happens to stored credentials if the application data directory is copied. If your security model requires that database access goes through a bastion with its own audit, or that each protocol is handled by a tool reviewed on its own, a unified client works against you. There is a second, quieter limitation: breadth has a cost in depth. The README lists Kafka management down to Schema Registry and Kafka Connect, and SQL editing across four engines, but it does not claim parity with a dedicated client for any single one of them. If your work is ninety percent deep PostgreSQL administration, a generalist workbench is the wrong shape regardless of how many other tabs it saves you. Finally, the plugin system is described as the route for more asset types, which means anything not in the current table is a dependency on plugin authors, not on the core project.

How this differs from a terminal multiplexer plus separate clients

The obvious alternative is the assembled stack most ops engineers already run: a terminal emulator with SSH and jump-host support, a database GUI, a Redis client, a Kafka console, and a cloud storage browser. The difference is not feature count, it is where session state lives. In the assembled stack, each tool owns its own connection profiles, its own credential store and its own idea of what a host is, and the jump host is redefined in each one. OpsKat's asset tree is the shared definition: a host configured once is available to the terminal, to the SFTP browser, and as a hop in a proxy chain for a database connection. That sharing is the actual product. The AI agent extends the same idea, since its registered tools operate on assets that already exist in the tree rather than on a separate configuration. The trade-off is that you cannot replace one layer without replacing the application. If your team has standardised on a particular database client for its query tooling, OpsKat does not let you keep that and take only the terminal.

Licence, release cadence and what to check first

OpsKat is GPL-3.0. For an end user running the desktop application this is unremarkable, but it matters if you intend to embed it, ship it internally as part of a larger product, or build plugins that link against its code. The GPL-3.0 obligations attach to distribution, and the plugin system is the place where that question becomes concrete: whether a plugin is a separate work or a derivative one is a legal question, not a technical one, and it is worth answering before you invest in writing one. On maintenance, the release history shows a steady cadence with stable tags and a parallel nightly channel, and the repository is not archived. The nightly tag existing alongside stable means the project is comfortable shipping pre-release builds to anyone who wants them, which is a signal about velocity and also about where you should source your binary. Verify before adopting: the installation docs for whether a package manager is supported on your platform, the credential storage documentation for key derivation and OS keychain integration, and the agent documentation for whether policy and approval can be turned off rather than simply left unconfigured. Those three answers determine whether OpsKat fits your environment, and none of them are settled by the README.

Editorial conclusion

Adopt OpsKat if you already juggle four or five separate clients and want your SSH, database, Redis, Kafka and object-storage sessions in one tree, and if you are comfortable running a GPL-3.0 desktop binary that stores credentials locally. Skip it if your environment requires per-protocol tooling that is audited independently, or if you cannot accept a nightly channel shipping alongside stable tags. Before installing, verify three things: which asset types the plugin system actually exposes today versus which are listed as coming, how the encrypted credential store derives and protects its key on your OS, and whether the AI agent's approval path can be disabled entirely rather than merely left unconfigured.

Official sources

1. License: GPL-3.0
2. opskat/opskat on GitHub
3. Project website
4. README
5. Releases