Kellnr is a crates.io you can run on your own hardware

One command to a working registry

The quick start is a single Docker invocation with a port mapping and one environment variable:

docker run \
    -p 8000:8000 \
    -e "KELLNR_ORIGIN__HOSTNAME=localhost" ghcr.io/kellnr/kellnr:5

The hostname variable is there because a registry has to know its own public address to build the URLs that cargo will fetch from, and the double underscore is the environment variable encoding of a nested configuration key. The image tag is on a major version line, so the tag moves as the project moves. For a longer-lived deployment there are two more routes: the container images on the GitHub package registry, including a minimal variant, and a Helm chart published from a separate repository, with the binary releases also on GitHub. The documentation site at kellnr.io covers configuration in more detail.

The CLI does configuration as well as serving

Run as a standalone binary, the tool has both a server role and a configuration role, and the subcommands are short:

# Show help and available commands
kellnr

# Start the server
kellnr start

# Start with custom data directory and port
kellnr start --registry-data-dir /var/lib/kellnr --local-port 8080

# Show current configuration as TOML
kellnr config show

# Create a default configuration file
kellnr config init

`kellnr config show` prints the effective configuration as TOML, which is a genuinely useful debugging tool, because you can see what the defaults and the environment actually resolved to. `kellnr config init` writes a default file, and it takes an output path with `-o`. A specific file can be selected with `-c` on the run command, for example `kellnr -c /path/to/kellnr.toml run`. The configuration precedence is stated explicitly: CLI arguments are highest, then environment variables such as `KELLNR_REGISTRY__DATA_DIR`, then the TOML configuration file, then the default values.

The two modes that matter are hosting and caching

Kellnr can act as a crates.io proxy, which means you can use it as a cache for crates.io to speed up downloads, and it can host crates, which means you can upload your own crates and use them in your projects with no extra tooling because cargo works out of the box. Those are different products with the same binary, and which one you need determines the rest of your setup. The proxy mode is a local cache in front of crates.io. The hosting mode brings the rest of the feature list: a web UI for uploading crates, managing versions and viewing documentation, docs.rs style support so you can host your own documentation for your crates, and user and group management where you can create users and groups, assign them to crates, create read-only users, or require authentication for crate pulls.

The storage and database backends are separate choices

Two independent decisions shape the deployment. The database holds the registry metadata and can be Sqlite or PostgreSQL. The crate files themselves live on the local filesystem, in S3, or in Google Cloud Storage. That separation is what lets a small installation be a single machine with Sqlite and a local directory, while a larger one can keep metadata in PostgreSQL and the artifacts in an object store. The workspace manifest shows the storage layer is its own crate, `kellnr-storage`, and the testing infrastructure reflects that both backends are treated as first class, with separate testcontainer crates for a fake GCS and for RustFS. The database layer has the same shape, with `kellnr-db`, a `kellnr-db-testcontainer` crate, and separate entity and migration crates under `crates/db`.

A dozen internal crates, and a UI built separately

The Cargo manifest describes a workspace with a default member of `crates/kellnr` and about fourteen internal crates, each with its own version, and the names map onto the responsibilities: `kellnr-appstate`, `kellnr-auth`, `kellnr-common`, `kellnr-db`, `kellnr-docs`, `kellnr-entity`, `kellnr-error`, `kellnr-index`, `kellnr-migration`, `kellnr-registry`, `kellnr-settings`, `kellnr-storage`, `kellnr-web-ui` and `kellnr-webhooks`. That is a normal Rust service layout, and the `kellnr-web-ui` crate name is worth noting because the UI is a crate rather than a set of static files, and the justfile shows a build step called npm-build that the release build depends on. The webhooks crate is not mentioned in the README's feature list, so it is the kind of thing you would find by reading the code.

The build tooling treats Windows as a first class target

The justfile is the entry point for development, and it is configured around the idea that the just commands provide additional functionality over the cargo commands. The interesting part is the platform split. Recipes are marked unix or windows, and on Windows the build runs with `--no-default-features` while the unix build does not, which means the default feature set differs by platform. There is a helper that sources an MSVC environment setup script on Windows before running cargo, and the justfile says to use PowerShell on Windows and sh elsewhere. The clippy recipe is run across the workspace with all targets and all features, and there is a separate clippy-deny recipe that adds `--deny warnings` for CI, plus a formatting check that runs `cargo fmt --all -- --check` without modifying files. The repository also has a Cross.toml for cross compilation, a flake.nix for Nix development, a clippy.toml, and a `ui/` directory at the top level for the frontend.

The motivation is dependency control in a corporate setting

The section on why the project exists is the most useful part of the README for judging fit. The author is a security engineer and researcher who fights vulnerabilities in software for a living, and with Rust becoming more popular he sees a lot of potential in the language for writing secure software. To adapt Rust in a corporate environment he needs to be able to control the dependencies of the software he writes, and that is where Kellnr comes in. The stated goal is to accelerate the adoption of Rust in corporate environments by providing a secure and private registry for crates, with the ultimate aim of making the world a bit more secure by promoting Rust. The three differences from crates.io are listed as private, easy to host, and user management, with the hosting claim being that it can run on a single machine without a complex setup, in stand-alone, Docker or Kubernetes deployments.

Editorial conclusion

Adopt Kellnr when you need to control which crates your organisation can pull, or when you want a crates.io cache on your own infrastructure, since the proxy mode and the private hosting mode are the two features it is built around. Do not adopt it as a drop-in replacement for crates.io without checking the protocol compatibility for your cargo version, since the project describes itself as Kellnr with crates.io caching rather than a full mirror. Verify first which storage backend you will use, whether Sqlite or PostgreSQL for metadata and the local filesystem, S3 or GCS for the crate files, and read the configuration precedence rules, because the CLI arguments override the environment variables which override the TOML file.

Frequently asked questions

Official sources

1. kellnr/kellnr on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases