agentregistry-dev/agentregistry: the installer comes from main while everything else is pinned

The installer comes from a branch while the server is version-pinned

The quickstart is three steps and the version discipline is inconsistent across them:

# 1. Install the CLI
curl -fsSL https://raw.githubusercontent.com/agentregistry-dev/agentregistry/main/scripts/get-arctl | bash

Step one pipes an install script straight from the default branch into a shell. Step two asks the resulting command for its version, extracts a field from the first line of that output with a line-oriented text tool, and uses it to fetch a compose file from a matching tag. Step three brings the stack up and waits for it. So the server side is pinned to a release while the client side is whatever the branch tip currently builds, and the two can disagree: a user can end up running a command from an unreleased commit against a released server image. The version extraction is also brittle by construction, since it depends on the first line of the command's output having a particular shape, and any banner or warning printed there would silently change what gets fetched.

The compatibility endpoints are anonymous and bypass list filters

The most security-relevant passage in the file is the environment template's comment on protocol compatibility, and it is worth reading in full because it is both a warning and a feature. A compatibility layer re-exposes MCP server resources in the official registry shape at a versioned path so that registry-aware clients, with a specific editor's gallery named, can discover them. The comment states plainly that this is anonymous, that it flattens all namespaces into a single catalogue, and that it bypasses the per-kind access-control filters applied to normal list operations. It is off by default, and the instruction is to enable it only where an unauthenticated cross-namespace catalogue is acceptable, with a separate document behind the details. A second read-only shim does the same job for a different ecosystem's plugin marketplace format, so a URL can be registered directly with that client. Both are described as read-only re-exposures of already-stored resources.

Secrets are encrypted at rest and the key lives in the environment

Because MCP server entries carry environment variables, the registry is a credential store, and the configuration template treats it as one. There are two backends. One writes secret payloads into the registry's own database and requires a 64-character hex-encoded AES-256 key supplied through the environment. The other stores them as namespace objects in Kubernetes, defaulting to a system namespace. Leaving the setting empty disables secret writes altogether, which is a reasonable default for a local trial and a trap for a deployment where someone assumes secrets are stored and they are not. Two neighbouring defaults deserve the same attention: the shipped database connection string disables transport security, which is fine on a laptop and wrong if copied into a cluster, and registry package-reference validation is off, meaning a stored reference is not checked against its source by default.

Four documented artifact kinds, seven example files

The build section describes four things you can publish. MCP servers, registered from a package runner for either of two ecosystems, from an OCI image, or from a remote endpoint, with versioning, environment variables and package references. Skills, defined as a markdown manifest bundled with examples, documentation, PDFs and reference URLs, scaffolded and pushed as an image. Agents, which bundle an identity with the servers and skills they need and how they should be configured. And prompts, versioned and stored alongside the other three. The example directory holds seven YAML files. Four map cleanly onto those kinds, one covers a remote endpoint variant, one is a fuller composition, and one is named for a model rather than for any of the four documented categories. Neither the documentation nor the visible capability list explains what registering a model means here.

The dependency set carries a TUI, two metrics stacks and a cluster client

The module file is long, and several entries tell you more about the project than the prose does. A terminal interface toolkit plus a text reflow library means the command has a full screen mode rather than only flag output. The API framework is one that generates its surface from an OpenAPI description, which matches the spec file committed at the repository root. Container handling comes from a registry library rather than a shell-out, so pushing is in-process. Migrations are a library, so schema history lives in the repository. Metrics are doubled: a client library for one exposition format and a full tracing and metrics stack with a Prometheus exporter alongside it. A cluster client triple plus an agent-to-agent implementation built on an RPC framework cover the Kubernetes and A2A halves of the story. One indirect entry is a Microsoft Windows library, which means a Windows-flavoured dependency is pulled into a cross-platform binary.

The light-mode logo is still named for the previous product

At the top of the file is a picture element with two image sources selected by colour scheme. The dark one points at a file named for this project. The light one points at a file whose name belongs to a different product entirely, with a gateway in it. Both files live under the documentation image directory, so both are committed, and the wrong name is doing real work: every visitor whose system prefers a light colour scheme loads the old brand. It is a small thing, and it is the kind of thing that survives for years because nobody opens the repository on a light-themed machine. It is also a signal worth weighting when reading the rest of the release history, where a project that renamed itself is still shipping artefacts from before the rename.

The build file loads the environment by hand because make keeps the quotes

The build file contains one of the more careful pieces of shell and make interaction in the repositories this article format tends to surface. It loads the environment file into make's variable scope only if the file exists, and the comment explains why it does not simply export everything: a bare export would push every make variable into recipes, which forces make to re-evaluate all recursively computed shell calls on every single invocation. A second comment explains the quote handling, noting that make's include keeps surrounding double quotes as part of the value where a shell source would strip them, so without manual stripping a line with quoted values would leak the literal quote characters into child processes. The fix is a pair of substitutions applied per variable. The same file also juggles two different local registries, with a comment explaining that the containerised builder cannot reach one of them and must push to another.

Blueprints turn an agent and its dependencies into one unit

The deployment section is where the platform's actual opinion shows. Local runs and Kubernetes clusters are driven from the same registry with the same discovery path, rather than being two systems that drift. Kubernetes deployment goes through a Helm chart, and the chart directory is committed at the top level next to the module definition. The unit of deployment is called a blueprint, and it bundles an agent together with the servers and skills it depends on into a single deployable object, which is the packaging decision that makes the difference between a catalogue and a supply chain. The curation side is described in terms of reviewing versioning, metadata and environment variable requirements, and of controlling what gets published and promoted. On the release record, the newest tag is about two months behind the last push, with a four-month gap between the two most recent tags before it.

Editorial conclusion

This suits an organisation that has outgrown per-developer manual setup and wants one approved catalog with the same delivery path locally and on Kubernetes. Read the compatibility section before enabling anything: the ecosystem shim deliberately bypasses list-level access control, and the documentation is unusually candid about that. Pin the CLI yourself if you care about reproducibility, since the documented installer does not, and turn on registry validation if your artifacts come from anywhere other than your own pipeline.

Frequently asked questions

Official sources

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