Primate is a desktop client for the Kong Admin API

A desktop client rather than a web admin

Primate is described as a desktop client for Kong Admin API, and it was formerly called KongDash, which tells you the lineage: the old name suggests the project outgrew its original identity as it moved to the desktop. The project site is getprimate.xyz, and the README keeps a screenshot of the interface in the header. The distinction matters because a desktop client and a web dashboard have different security and deployment consequences. A desktop client holds its own configuration and credentials locally and talks to the admin API from the operator's machine, which is a reasonable trade for an administrator who wants one tool on their own workstation rather than a second service to deploy and secure. The package is built with Electron, and the manifest shows the shape of the application, with a main entry at out/platform/main.js and a lint script that covers src/platform, src/workbench and build/, which tells you the code is split into a platform layer and a workbench layer.

The compatibility table is the whole scope statement

There is one table in the README and it is short enough to quote, and it constrains everything else. Primate version 1.0.0 to 1.1.0 is compatible with Kong Admin API versions 2.7.x and 2.8.x, and there are no other rows. That is the entire supported matrix. A reader will notice what it implies, because Kong's own release line has moved on from those versions, and the project has not published a newer client since. The release history makes the same point. The most recent release is v1.1.0 on 2023-09-10, before that v1.0.0 in June 2022, and before that v0.3.0 from July 2017, so the project has an old name, an old package identity and a long gap in between. The last push to the repository was on 2026-09-23, so the code is still being touched, but the published desktop builds and the compatibility statement are both anchored in 2023. For a Kong operator deciding whether to install this, the table is the first thing to check against their own gateway version, and it is a short table with a definite answer.

Installing on the three desktop platforms

Builds are available for the major desktop operating systems and the README gives one route for each. On Windows you download the latest executable setup file from the releases page and run it. On macOS you download the latest DMG file, open it, and move the app to /Applications. On Linux the project offers an AppImage and a tar.gz archive for all popular distributions, and the steps are to download the latest AppImage, make it executable with chmod a+x, and run it.

$ sudo chmod a+x Primate-version-x64.AppImage

There is also a Snap for Ubuntu users, installed from the Snap store.

$ sudo snap install primate

The project also describes itself as a modern dashboard for Kong Gateway admins, which is the positioning in the repository description, and it lists the admin, dashboard, electron, kong and kongdash topics. The rename from KongDash to Primate is the part worth remembering when you search for the tool, because the old name is what most existing references will use.

Building from source with yarn and grunt

The developer requirements are NodeJs v16.13.2 or higher and yarn v1.22.17 or higher, and the application is built with Electron. To build and run it, you clone the repository, install the dependencies and start.

$ git clone https://github.com/getprimate/primate
$ cd primate
$ yarn install
$ yarn start

Packaging for your operating system takes a compile step and a dist step.

$ yarn run compile
$ yarn run dist

The binaries are written to a /dist directory, and a clean script removes the output directories. One restriction is called out and it will save you a wasted afternoon, because compiling to a non-native binary is currently disabled. The manifest confirms the shape of the toolchain, since the scripts are thin wrappers around grunt, with clean, start, compile, dist and release all delegating to a Gruntfile.js at the repository root. The dependencies are of a particular vintage, with Electron at ^22.0.3, electron-builder at ^23.6.0, grunt at ^1.5.3, Babel for the transpilation step, eslint, prettier, rimraf for the clean task and inquirer, which is what you would expect in an Electron app that prompts during a build.

What the repository contains beyond the application

The tree is modest, and a few entries say something about the state of the project. There is a build/ directory at the top level, a resources/ directory, src/ with the application code, test/ for the test suite, and a Gruntfile.js driving the tasks. The project keeps a CHANGELOG.md, a CONTRIBUTING.md that the README points to for a complete overview of how to help, a TODO.md, and a LICENSE file with the MIT terms, which the README also states. Configuration for the tooling is present in the shape you would expect, with .eslintrc.json, .prettierrc.js and .prettierignore, and a yarn.lock pinning the dependency tree. The presence of both a CHANGELOG and a TODO file in a repository whose last release was in 2023 suggests the maintenance mode the release dates imply, where small fixes accumulate without new packaged versions. The README closes with a supporters section that thanks JetBrains for the open source community discount and links to the GitBook pricing page for non-profit and open source discounts, which is a common way for a project built on commercial tooling to acknowledge sponsorship.

Where Primate is the wrong tool

Three limits, and the first is decisive. The compatibility table stops at Kong Admin API 2.8.x, so if your gateway is running a later release, this client is not certified against it, and the client is old enough that newer Kong features simply will not be in it. That is a different situation from a bug, because there is no release to wait for. The second is that a desktop client is a single-administrator tool. There is no shared state, no team access model and no audit trail of who changed what, and the whole thing is bound to the machine it is installed on, which is fine for one operator and wrong for a platform team with a change process. The third is the build toolchain. This is a grunt and Babel application on Electron 22 with a Node 16 floor, which is old enough that a current Node version may not build it cleanly, and there is no container image in the repository listing to sidestep the problem. The alternative worth naming is driving the Admin API directly with curl or your own script, which gives you full coverage of whatever version you run at the cost of writing the calls yourself.

Editorial conclusion

Adopt Primate if you run Kong Gateway and want to inspect and manage routes, services and plugins from a desktop application rather than the browser, and you are on Admin API 2.7 or 2.8. Skip it if you need to manage a Kong deployment that has moved past those API versions, since the compatibility table stops there, and skip it if you need multi-user access or a shared configuration, because a desktop client on one administrator's laptop is not a team tool. Before you build from source, check the version table against your Kong, and expect the grunt based build rather than a modern bundler.

Frequently asked questions

Official sources

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