> ## Documentation Index
> Fetch the complete documentation index at: https://docs.nasiko.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Artifact registry

> Push, pull, and browse agents, skills, tools, and other artifacts.

<Warning>
  **Enterprise feature.** The artifact registry is a standalone `nasiko-ee` service — no route,
  module, or crate under the open-source edition hosts it. The OSS `nasiko` CLI ships only a
  generic client (`nasiko registry connect/search/list`) that can point at a registry URL you
  supply; it doesn't bundle or default to one.
</Warning>

The artifact registry is an OCI-compliant store for everything you build — agents, skills, tools, MCP servers, standalone binaries. It speaks the same protocol as `docker`, `podman`, and `oras`, with a metadata and search layer on top.

Reach it three ways: its own web UI, the `nasiko` and `nasiko-ee` CLIs, or the `/v1` (metadata) and `/v2` (OCI) HTTP APIs.

## Artifact types

| Type         | What it is                                                              |
| ------------ | ----------------------------------------------------------------------- |
| `agent`      | A runnable A2A agent                                                    |
| `skill`      | A reusable skill bundle                                                 |
| `tool`       | A tool or function artifact                                             |
| `mcp`        | An MCP server package                                                   |
| `executable` | A standalone binary or CLI — how the platform CLI itself is distributed |

Packaging is separate from type. An artifact can ship as plain source, a Dockerfile or Compose recipe, a multi-layer OCI image, or an external reference card with no blob at all.

## Publishing

**The registry publish command** auto-detects agents (`AgentCard.json` at the root) and skills (`skill.json`). For anything else, pass `--type` with an `artifact.json` manifest:

```sh theme={null}
nasiko-ee registry publish ./my-agent --owner myorg
```

If the path isn't a local directory, it's treated as an image reference and pushed as OCI layers.

**A standard OCI push** — `docker push`, `podman push`, or `oras push` — works against `/v2` with any compliant client. The registry still classifies the artifact for its catalog, best-effort and never rejecting the push:

1. An explicit `org.nasiko.type` annotation:
   ```sh theme={null}
   oras push registry.example.com/myorg/my-cli:v1 ./nasiko-ee \
     --annotation "org.nasiko.type=executable"
   ```
2. Otherwise, inference from OCI media types — an OCI 1.1 `artifactType`, a Helm chart's config media type.
3. Otherwise `unknown`, grouped under "Miscellaneous."

A mis-typed artifact isn't stuck — an admin can correct its type, description, tags, license, or framework without re-publishing.

## Pulling

* **Image-packaged** — `docker pull` / `podman pull` / `oras pull` against `registry.example.com/{owner}/{repo}:{tag}`
* **Single-blob** (source, open-standard bundles) — `/v1/artifacts/{owner}/{name}/{version}/download`
* **From the CLI:**

  ```sh theme={null}
  nasiko registry connect https://registry.example.com
  nasiko registry search "nutrition planning" --type agent
  nasiko registry list --type skill
  ```

  `nasiko registry` also supports `disconnect`, `status`, and `--json`. `search` (alias `discover`) takes `--framework`, `--top`, and `--min-score`.

## Browsing and searching

The web UI shows a card grid with type tabs — **All**, **Agents**, **Skills**, **MCP**, and **Miscellaneous** (which appears only when there's an uncategorized artifact). Framework and format facet filters hide themselves when they wouldn't narrow anything.

Search takes a natural-language query and ranks semantically when an embeddings provider is configured. Without one, it falls back to keyword search transparently — same API, same UI, no error.

## Lifecycle and admin edits

Each version carries a status: `preview`, `stable`, or `verified`. An admin sets these in the UI's edit-details view or via the metadata API:

```sh theme={null}
curl -X PATCH https://registry.example.com/v1/artifacts/myorg/my-agent/v1 \
  -u admin:secret \
  -H "Content-Type: application/json" \
  -d '{"status": "verified", "tags": ["nlp", "customer-support"]}'
```

`yanked` isn't settable this way — removing a version is a deliberate separate action: `nasiko-ee registry yank <name> <version>`.

Browsing, searching, and downloading stay open to anyone who can reach the registry. Publish, yank, and edit require admin credentials.

## Connecting an MCP client

The registry exposes an MCP server over Streamable HTTP, so MCP-capable clients can browse and act on it directly.

| Tool                                                                                                                     | Auth  | Purpose                     |
| ------------------------------------------------------------------------------------------------------------------------ | ----- | --------------------------- |
| `list_artifacts`, `search_artifacts`, `get_artifact`, `list_versions`, `get_version`, `list_facets`, `download_artifact` | none  | Browse, filter, download    |
| `publish_artifact`, `yank_artifact`                                                                                      | admin | Publish or remove a version |

```sh theme={null}
claude mcp add --transport http nasiko-registry https://registry.example.com/mcp \
  --header "Authorization: Basic $(printf 'admin:secret' | base64)"
```

Reads need no credentials. Add the header only if the client should publish or yank.

## Deploying a registry

```sh theme={null}
nasiko-ee registry init \
  --host <server-ip> \
  --domain registry.example.com \
  --admin-password <password>

nasiko-ee registry status                # registries you manage and their state
nasiko-ee registry upgrade --tag <tag>   # pull a new image and restart
nasiko-ee registry logs --tail 50
```

Pull and push access is governed by the credentials you configure for that deployment. `nasiko-ee activate <token>` saves pull credentials for a cluster consuming images from a gated registry.

<CardGroup cols={2}>
  <Card title="Agent Development Lifecycle" href="/adlc/overview">
    Where publishing fits into shipping an agent.
  </Card>

  <Card title="A2A agents and frameworks" href="/adlc/a2a-agents">
    What makes an agent a valid, discoverable artifact.
  </Card>

  <Card title="Sample agents" href="/artifact-registry/sample-agents">
    Ready-to-deploy agents you can pull.
  </Card>

  <Card title="Registry in the dashboard" href="/product/artifact-registry">
    Browse and publish from the registry's web app.
  </Card>
</CardGroup>