OpsKat: a Go and Wails desktop workbench for SSH, RDP, databases and AI-driven ops

The pile of tools OpsKat is trying to replace

Day-to-day ops work spreads across a terminal emulator, a SQL client, a Redis browser, a Kafka console, an object-storage web UI and a remote-desktop viewer. Each one has its own credential store, its own connection list and its own idea of what a folder is. OpsKat's pitch is that these are all asset types inside one desktop application with a single tree-structured grouping, so a host, a database and a bucket sit next to each other instead of in six unrelated apps.

The target user is the individual operator or small team who touches many kinds of infrastructure and wants one window. The README lists SSH, VNC, RDP, local terminal and serial under servers; MySQL, PostgreSQL, SQL Server, SQLite, Redis, MongoDB and etcd under databases; Kafka and Kubernetes under middleware; and S3-compatible object storage including cloud and self-hosted. That breadth is the product. It is not a specialist SSH client that happens to have a query tab.

How the pieces fit: Wails, Go backends and a plugin system

OpsKat is a Wails v2 application: a Go backend with a React 19 frontend, packaged as a native desktop binary for macOS, Linux and Windows. The repository layout confirms the split, with cmd/, internal/, pkg/, plugin/, frontend/ and migrations/ at the top level, plus a wails.json. The Go module declares go 1.26.0 and pulls in protocol clients directly: franz-go for Kafka, minio-go for object storage, go-redis for Redis, pgx and go-sql-driver for PostgreSQL and MySQL, go-mssqldb for SQL Server, the MongoDB driver, and the etcd client and server packages.

Two details in the dependency list are worth noting because they shape what the app can do. First, github.com/tetratelabs/wazero is present, which is a WebAssembly runtime in Go; combined with the plugin/ directory and the README line that more asset types are coming via the plugin system, this suggests plugins run as sandboxed Wasm rather than as native shared objects. Second, github.com/zalando/go-keyring is a dependency, so credentials go to the OS keyring rather than a bespoke encrypted file, which is the right call for a desktop app and also means credential storage depends on the platform keyring being available.

The README also describes proxy chains for SSH and remote data assets: ordered layers that can combine an SSH tunnel reusing an existing SSH asset, a SOCKS5 proxy with optional username and password, and an HTTP script tunnel compatible with DBX-style tunnel scripts. That ordering matters when a database is only reachable through a bastion, and it is the kind of feature that is easy to claim and hard to get right.

Installing OpsKat and connecting a first host

The README points at the Releases page for macOS, Windows and Linux builds and says no Go or Node toolchain is required. Step-by-step notes live in the installation docs at opskat.dev. If you prefer to build from source, the Makefile defines the targets, and the build embeds the opsctl CLI when you use the embed tag.

make build-embed

On macOS there is a separate target that builds and installs the app bundle into ~/Applications by default, with APP_INSTALL_DIR overridable.

make install-app

For development the Makefile offers a hot-reload mode, and separately a sandbox that runs the real application against an isolated data directory with a headless Chromium attached. The comment in the Makefile is explicit that you should not verify features that write data against your real database, and should use the sandbox instead.

make dev
make dev-sandbox

Once the app is open, the README's first-run sequence is three steps: add an asset (an SSH or RDP host, a database, an object-storage account, Redis and so on) or import from an SSH config, Tabby, WindTerm, .rdp or Excel file; connect and use the terminal, query editor or bucket browser; and optionally configure an AI provider so the agent can act on your behalf. The import path is the practical entry point, because retyping a hundred hosts is the reason people stay on their old client.

The repository also ships a .env.example for end-to-end verification against real targets, with variables such as E2E_SSH_HOST, E2E_SSH_PORT, E2E_SSH_AUTH and E2E_SSH_KEY. Its header states plainly that the application itself does not read this file; only the e2e harness loads it, and the guidance is to run read-only or non-destructive operations only. One caveat is written into the file: private key paths must be absolute, because the connect path uses os.ReadFile and does not expand ~.

The AI agent is the least specified part of the product

The README says you can tell the agent what you need in natural language and it will use registered tools to pull logs, run SQL, check cluster status and more. It also says applicable operations use their policy and approval paths, and that tool calls carry an audit trail and decision context where available. Those two sentences are the entire public description of the governance model in the documentation available.

That is thin for a feature that can run SQL and fetch logs. The qualifiers do real work: applicable operations, where available. They leave open which operations are not applicable, what an approval path looks like in the UI, and where the audit trail is stored or how it is exported. The dependency on github.com/sashabaranov/go-openai and the cago-frame/agents packages tells you the plumbing exists, but not how a destructive statement is gated. If you are evaluating OpsKat for a regulated environment, treat the AI layer as unverified until you read the docs and test it, and note that the README does not document a way to disable individual tools or restrict the agent to read-only queries.

Where OpsKat is the wrong tool

OpsKat is a desktop application. If your workflow is a bastion host that engineers SSH into, or a browser-based console you can reach from a locked-down laptop, this is not that, and the README does not describe a server component or a web deployment mode. The Wails IPC boundary is part of the design: the README notes that VNC remote desktop tabs are backed by noVNC with session bytes carried over Wails IPC, which only makes sense in a packaged desktop app.

Scale is the second boundary. The asset tree, the credential keyring and the connection state are per-installation. There is no mention of shared configuration, team-level policy sync or a central inventory, so a team of ten adopting OpsKat gets ten independent setups. For a single operator that is fine. For an organization that needs one audited source of truth for who can reach which host, it is a gap.

Third, the AI agent is optional and the README treats it that way. If you want an agent-first ops tool, OpsKat's agent is a layer on a manual workbench, not the other way around.

Alternatives and the actual difference in approach

The closest comparison in spirit is a terminal-centric client such as Tabby or WindTerm, both of which OpsKat can import from. Those tools are terminal emulators with SSH profiles, and their feature depth is in the terminal: session management, shell integration, themes. OpsKat's terminal is one tab type among many, and its depth is in the number of asset protocols it speaks. If your day is 90 percent shells, a dedicated terminal client will feel better tuned; if your day is a shell, then a query editor, then a bucket listing, OpsKat removes the context switch.

For database work specifically, a dedicated GUI such as DBeaver goes deeper per engine than OpsKat's SQL editor and data browser can, because OpsKat spreads its effort across SSH, RDP, VNC, Kafka, etcd, Kubernetes and object storage as well. Choosing OpsKat is choosing breadth over per-protocol depth, and the README's own framing supports that reading: it calls itself a workbench, not a database IDE.

The other difference is packaging. OpsKat is a single Go binary with an embedded frontend, licensed GPL-3.0, with a plugin system built around a Wasm runtime. An alternative assembled from separate open-source clients gives you independent licences and independent update cycles, at the cost of the integration you were trying to get.

Maintenance, releases and the GPL-3.0 question

The repository is not archived and the last push was on 2026-09-10. Releases are frequent: v1.13.4 on 2026-09-07, v1.13.3 the same day, and a nightly build v1.13.4-nightly.20260909 on 2026-09-09. Nightly builds exist alongside tagged releases, which is a signal that the project moves quickly and that you should pin to a tagged version rather than a nightly if you care about reproducibility.

Building from source has a real cost. The module requires Go 1.26.0, Wails v2, and a Node toolchain for the React frontend, and the dependency list is long: Kafka, MongoDB, etcd, Kubernetes API, gRPC, SQLite drivers and a Wasm runtime all in one binary. That is a large surface to compile and a large surface to keep current. There is no separate lightweight client in the repository.

The licence is GPL-3.0. For an individual installing the app, that is a non-issue. For a company that wants to redistribute a modified OpsKat internally, or bundle it into a product, the copyleft terms apply to the distributed work, and the plugin system raises the usual question of whether a plugin is a derivative work. The repository does not include a plugin-licence exception among the files visible at the top level. That is a question for your own legal review, not something the README settles.

Editorial conclusion

Adopt OpsKat if you are tired of running a terminal, a database GUI, a Redis browser and a Kafka console side by side, and you want one asset tree with proxy chains and encrypted credentials. Do not adopt it if your team needs a headless, server-side jump host, or if you cannot accept GPL-3.0 obligations in your distribution. Before rolling it out, verify two things yourself: that your OS keyring actually stores the credentials (go-keyring is a dependency, but the README does not describe a fallback), and what the AI agent's approval and audit controls do in practice, because the README only asserts that applicable operations use them.

Frequently asked questions

Official sources

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