# kRPC: driving Kerbal Space Program from scripts that run outside the game

> kRPC gives Kerbal Space Program an external control surface, with client libraries for many languages and a protocol-first layout built on protobuf, Bazel and .NET. It is a mature 0.x project whose scope deliberately excludes KSP2.

**krpc/krpc** — Remote Procedure Calls for Kerbal Space Program

- Repository: https://github.com/krpc/krpc
- Website: https://krpc.github.io/krpc
- Stars: 748 · Forks: 169
- Language: C#
- License: NOASSERTION
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/krpc-krpc

## A control surface that lives outside the game process

The README states the premise in one line: kRPC allows you to control Kerbal Space Program from scripts running outside of the game, and comes with client libraries for many popular languages. That separation is the whole design decision. The script does not live inside the game's address space, so a Python or Lua script can be edited and rerun without restarting anything, and the game exposes its state through a remote interface instead of through a plugin that shares memory with it. The audience is the modding and automation community around KSP, and the forum release thread in the README points at exactly that audience, with an early version described as remote control for your ships using Python, C, C++ and Lua. The implementation is C#, the default branch is main, and the repository topics are kerbal-space-program and krpc.

## A protocol-first repository layout

The tree shows a build arranged around a wire protocol rather than around the game. A protobuf directory sits at the top level, and alongside it are service, client, server, core, tools and doc directories. The build system is Bazel: there is a .bazelrc, a pinned .bazelversion, a BUILD.bazel, a MODULE.bazel and a config.bzl, and maven_install.json records Java side dependencies. On the .NET side the tree carries KRPC.sln and Directory.Build.props. Based on that layout, the service definitions are the contract, the client side is generated or written per target language, and the server side is the piece that lives with the game. The CHANGELOG.md at the root is where a change to that contract would be recorded. The split across C, C++, C#, Java and scripting languages is the cost of that contract, and the mixed build tooling in one repository is the direct consequence.

## The client libraries are the actual product surface

For most users, kRPC is a client library and a documentation site, not a C# codebase. The README puts the Web Documentation at krpc.github.io/krpc and points to the releases page for PDF Documentation, which is a useful detail for anyone working offline or in a locked-down environment. A client directory at the top of the tree is where the per-language libraries live, and the forum release thread and the Discord server are the two support channels the project lists. The documentation being a separate published site rather than a folder of Markdown in this repository is the shape of the project: the interface definition changes rarely, so the reference material is generated or maintained elsewhere and the repository concentrates on the implementation. If you are evaluating kRPC, the thing to read is the interface documentation, because that is the contract your script will be written against.

## The README points you to documentation rather than to an install command

There is no install command in the README, and there is no package manager line, no Docker file and no setup script to copy. Instead the README offers its entry points, and the first two are documentation:

```bash
 * [Web Documentation](https://krpc.github.io/krpc)
 * [PDF Documentation](https://github.com/krpc/krpc/releases)
```

For anyone who wants to build the project rather than consume it, the README points to Development-Guide.md for information on the project structure, compiling the code and the various tools, and to Release-Guide.md for maintainers doing releases. Contributions are invited through Contributing.md, and the project asks that people read that guide first. The honest reading is that the installation path is documented outside this repository, on the documentation site, and the repository is the place to go only if you intend to compile the server or the client libraries from source.

## KSP2 support was planned and then dropped

One paragraph in the README is decisive for anyone scoping a project today. Under a KSP2 heading it says kRPC was briefly planned for KSP2, but has now been abandoned, and points to the separate repository krpc/krpc2. That sentence sets the boundary of this codebase: it is the KSP1 line, and the successor work lives elsewhere. There is a practical consequence beyond the headline. A script written against the kRPC interface in this repository targets the interface described by the documentation for Kerbal Space Program, and the abandoned plan means no forward-compatible layer in this tree will smooth a move to the other game. Anyone evaluating kRPC for a new simulator project should look at krpc/krpc2 first and treat this repository as the established, released version of the older target.

## Per-language linting and test configuration in one tree

The root directory carries a surprising amount of quality tooling for a project of this size, and the list says something about how the languages are separated. There is a .clang-format and a .clang-tidy for the C and C++ side, a .luacheckrc for Lua, and a ruff.toml plus a pyrightconfig.json and a pytest.ini for the Python tooling. The .gitattributes file sits next to them, and a CLAUDE.md is also present at the root, which suggests the project has taken to writing guidance for automated assistants alongside its contributor docs. The point of the configuration split is that the repository does not treat the client libraries as an afterthought: each language has its own formatting, linting and test conventions, checked in the same tree. For a contributor, that means the rules are legible per language instead of being described in prose in a wiki page that nobody updates.

## Three licence files and no standard identifier

GitHub classifies the licence of this repository as Other, meaning a custom licence that the platform cannot map to a known identifier, and the root directory explains why: it contains LICENSE alongside COPYING and COPYING.LESSER. Two named licence texts and one custom file usually means the project distinguishes between components with different terms, but the README does not say which parts those are, so the assignment has to be made by reading the files rather than by guessing from the tree. This is worth doing before adoption, because a client library embedded in your own code and a server component distributed with the game are not the same legal object. No conclusion about which terms apply should be drawn from the file names alone, and this is a question for the project's own licence text and, if the terms are unclear, for whoever in your organisation handles licensing.

## Two years between v0.5.4 and v0.6.0, with commits still landing

The release history explains the pace. The most recent release is kRPC v0.6.0 on 2026-07-22, preceded by v0.5.4 on 2024-06-10 and v0.5.3 on 2023-04-02. A gap of more than two years between the last two tags, followed by a new 0.x release, tells you two things at once. The project is not dead, because the last push to the repository was on 2026-10-16, and the CI and documentation workflow badges at the top of the README are still linked. But it is also a project on a 0.x version line with a long release cycle, which in practice means the version number carries no promise of interface stability across minor versions, and that pinning an exact release rather than tracking a branch is the sensible approach. Upgrade cost for a user is therefore a deliberate decision, taken when the interface documentation and the game version line up.

## Conclusion

kRPC fits players and teams who want autopilots, telemetry and mission scripting for Kerbal Space Program in a language other than the one the game runs on, and it fits engineers who want the control logic outside the game process so a crash does not take the script with it. It does not fit KSP2 work, since the README states that KSP2 support was planned and then abandoned, and it does not fit a team that needs a stable 1.x contract, because the project is still releasing 0.x versions with a two year gap between v0.5.4 and v0.6.0. Verify first which licence terms apply by reading LICENSE, COPYING and COPYING.LESSER in the repository root, since GitHub classifies the licence as Other, and check the Development-Guide.md for the compile steps before committing a build pipeline to Bazel and .NET.

## FAQ

### What does kRPC actually let me do?

The README states that kRPC allows you to control Kerbal Space Program from scripts running outside of the game, and that it comes with client libraries for many popular languages.

### Does kRPC support KSP2?

No. The README says kRPC was briefly planned for KSP2 but has now been abandoned, and points to the separate repository krpc/krpc2 for that work.

### How do I install or build kRPC?

The README gives no install command. It points to the Web Documentation at krpc.github.io/krpc for usage, to the PDF Documentation on the releases page, and to Development-Guide.md for the project structure, compiling the code and the various tools.

### Which programming languages have kRPC client libraries?

The README says client libraries for many popular languages are included, and an early forum release thread refers to remote control using Python, C, C++ and Lua.

### What licence does kRPC use?

GitHub classifies the repository licence as Other, a custom licence it cannot map to a known identifier. The repository root holds LICENSE, COPYING and COPYING.LESSER, and the README does not explain which components each covers.

## Sources

- [Issues](https://github.com/krpc/krpc/issues)
- [krpc/krpc on GitHub](https://github.com/krpc/krpc)
- [Project website](https://krpc.github.io/krpc)
- [README](https://github.com/krpc/krpc/blob/main/README.md)
- [Releases](https://github.com/krpc/krpc/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/krpc-krpc
