# KSP-CKAN/CKAN: a package manager for Kerbal Space Program mods

> CKAN is a metadata repository plus a client that installs, updates and validates Kerbal Space Program mods against their declared dependencies. It is aimed at players who want a mod list that resolves cleanly, and at modders who want their install instructions enforced rather than retyped.

**KSP-CKAN/CKAN** — The Comprehensive Kerbal Archive Network

- Repository: https://github.com/KSP-CKAN/CKAN
- Website: https://forum.kerbalspaceprogram.com/index.php?/topic/197082-*
- Stars: 2,651 · Forks: 402
- Language: C#
- License: NOASSERTION
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/ksp-ckan-ckan

## What CKAN solves for Kerbal Space Program players

Kerbal Space Program mods are distributed as archives that expect to be unpacked into specific folders under GameData, and many of them depend on other mods being present at the right version. The README describes the CKAN as "a metadata repository and associated tools to allow you to find, install, and manage mods for Kerbal Space Program," and states that it "provides strong assurances that mods are installed in the way prescribed by their metadata files, for the correct version of Kerbal Space Program, alongside their dependencies, and without any conflicting mods." That sentence is the whole product. The problem is not downloading a zip; it is knowing which zip goes where, which version matches your KSP build, and which other mods must be present first.

The audience is split in two. Players get a client that resolves the graph for them. Modders get an enforcement layer: the README notes that "modders don't have to worry about misinstall problems or outdated versions." The project explicitly credits Debian and CPAN as inspiration, and the repository contains a metadata specification (Spec.md) plus a JSON Schema (CKAN.schema) registered with Schema Store. That is a package-manager design, not a downloader with a search box.

## How the metadata and the client fit together

The repository is split along a clear boundary. Core/ holds the logic that reads metadata and resolves installs, GUI/ and ConsoleUI/ are the two front ends, Cmdline/ handles argument parsing, and Netkan/ plus the NetKAN.schema concern the pipeline that turns upstream releases into metadata entries. The README points contributors at a separate NetKAN repository for metadata issues, which tells you the client and the metadata corpus are maintained as distinct artifacts.

What the client enforces comes from the spec, not from guesswork. A metadata file declares the mod, the KSP versions it supports, its dependencies, and its conflicts. The client reads that, builds a set of mods that can coexist, and installs each one according to the instructions in its metadata rather than by dumping the archive into GameData. The README frames this as the central guarantee, and the presence of a schema means a malformed entry can be rejected before it ever reaches a player.

The Dockerfile reveals how the client is driven in headless mode. The container defines a shell function that runs the executable with two flags: --kspdir pointing at the mounted game directory, and --headless. On startup the entrypoint runs a scan, and if no arguments are passed it runs an upgrade of everything. That is the same resolution engine as the GUI, exposed without a window.

## Installing CKAN and running a first upgrade

The README directs players to the User guide on the wiki for getting started, and the repository ships releases through GitHub. The Dockerfile is the most explicit installation path in the repository, and it is the one to follow if you are on Linux or want the client scripted.

Build the image from the repository root:

```bash
docker build -t ckan .
```

The Dockerfile starts from the mono base image, copies the source, and runs build.sh with a configuration argument that defaults to Release. The resulting executable is placed at /build/ckan.exe inside the container.

To install a specific mod, mount your game directory and pass the mod name. The Dockerfile gives this exact example:

```bash
docker run --rm -v ${KSPDIR}:/kspdir ckan install MechJeb
```

KSPDIR must be set to your Kerbal Space Program install. The container mounts it at /kspdir, which is also the volume declared in the image.

There is a docker-compose.yml for Linux users that wires the mount for you. It maps ~/.steam/steam/steamapps/common/Kerbal Space Program/ to /kspdir. With that in place:

```bash
docker-compose run --rm ckan install MechJeb
```

Running the service with no arguments triggers the default path. The entrypoint script scans, and with no arguments it runs an upgrade of all installed mods:

```bash
docker-compose run --rm ckan
```

One detail worth reading before you run this: the image appends a cleanup script that runs on exit and changes ownership of everything under /kspdir to match GameData. If your game directory has ownership you care about, that will not preserve it.

## Where CKAN is the wrong tool

CKAN can only install what the network has metadata for. A mod that is not in the metadata repository is invisible to the client, and the README is direct about the remedy: metadata contributions are welcome, and issues about incorrect metadata go to the NetKAN issue tracker rather than the client repository. If you run a small private mod, or a fork you built yourself, CKAN will not manage it.

The second limit is the flip side of the guarantee. The client installs mods the way their metadata prescribes, which means it moves and deletes files under GameData. If you have hand-edited a mod's config files, or keep a patched version of a dependency, an upgrade can overwrite that work. The README does not document rollback, and neither the README nor the Dockerfile describes an undo command. Treat the client as authoritative over GameData, not as a layer on top of it.

Third, the Dockerfile's default behaviour is broad. With no arguments it upgrades every installed mod. That is convenient for a maintenance run and risky if you pinned versions deliberately for a save you care about.

## CKAN against manual GameData management

The realistic alternative is doing it by hand: download each archive from its forum thread or SpaceDock page, read the install instructions, and copy folders into GameData yourself. The difference is not convenience, it is where the knowledge lives. With manual installs, the dependency and version information sits in prose on a forum post and in your memory. With CKAN, it sits in a metadata file that a schema validates and a resolver reads.

That distinction shows up in failure modes. A manual install fails when you miss a dependency or pick a build for the wrong KSP version, and you discover it when the game crashes on load. A CKAN install fails when the metadata is wrong or missing, which is why the project treats metadata accuracy as a first-class concern and asks mod authors to correct it. The trade is real: you exchange a class of silent mistakes for a dependency on a corpus other people maintain.

If you only ever install one or two mods and never update them, manual management is fine and CKAN adds a layer you do not need. The moment your list grows past a handful, or you want to update everything at once, the resolver starts earning its place.

## Licence, releases and what upgrades cost you

The repository carries a LICENSE.md file, and the GitHub API reports the licence as NOASSERTION, meaning the automated classifier could not map it to a known identifier. Read LICENSE.md directly rather than assuming a standard licence applies, and note that the metadata corpus lives in a separate repository with its own terms. Nothing here is legal advice; the file is the source.

On maintenance, the last push to the default branch was on 2026-09-23, and the most recent release listed is v1.36.4 from 2026-05-12. The project ships versioned releases with names attached (v1.36.2 is Politas, v1.36.0 is Quasar), which suggests a deliberate release cadence rather than continuous deployment. The README states the project is under active development and welcomes pull requests.

The upgrade cost is mostly on the metadata side. Because the client resolves against a spec, a change to Spec.md or CKAN.schema can affect every entry. The repository includes Tests/ and a validator, and the README points at a wiki page for verifying metadata files, so the project has tooling for catching a bad entry before it ships. For a player, the practical cost is the opposite: you inherit whatever the corpus decides, and a corrected metadata entry can change what an upgrade does to your install.

## Conclusion

Adopt CKAN if you run a modded Kerbal Space Program install and want dependency resolution and conflict checks instead of manual GameData surgery, and if you are comfortable with a client that rewrites files under GameData. Do not adopt it if you need a mod that has no metadata in the network, or if you want a tool that only downloads archives and never touches your install. Before committing, verify that the mods you actually use are listed with the KSP version you run, and check whether the client's upgrade path handles the versions you have pinned. The metadata specification in Spec.md and the JSON Schema in CKAN.schema are the authoritative description of what the client enforces, so read those before filing an issue about an install that failed.

## FAQ

### What does CKAN do for KSP?

It is a metadata repository and client that finds, installs and manages Kerbal Space Program mods, with the README stating it ensures mods are installed as their metadata prescribes, for the correct KSP version, with their dependencies and without conflicts.

### Where to get CKAN for KSP?

The README links to the latest GitHub release for downloads and points players at the User guide on the wiki to get started. The repository also ships a Dockerfile and docker-compose.yml for building and running the client as a container.

### Is CKAN for KSP safe?

The README does not make a security claim, so there is nothing in the documentation to confirm that directly. What it does state is that installs follow metadata files validated against a JSON Schema, and the project uses SignPath.io's free code signing service for its releases.

### Do I need to launch KSP from CKAN?

The documentation does not describe launching the game from the client. The client's job as described in the README is to find, install and manage mods, and the Dockerfile invokes it with a --kspdir flag pointing at the game directory.

## Sources

- [Issues](https://github.com/KSP-CKAN/CKAN/issues)
- [KSP-CKAN/CKAN on GitHub](https://github.com/KSP-CKAN/CKAN)
- [Project website](https://forum.kerbalspaceprogram.com/index.php?/topic/197082-*)
- [README](https://github.com/KSP-CKAN/CKAN/blob/master/README.md)
- [Releases](https://github.com/KSP-CKAN/CKAN/releases)

---

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