Skip to main content
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.
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

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:
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:
  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:
    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:
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.
Reads need no credentials. Add the header only if the client should publish or yank.

​
Deploying a registry

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.

Agent Development Lifecycle

Where publishing fits into shipping an agent.

A2A agents and frameworks

What makes an agent a valid, discoverable artifact.

Sample agents

Ready-to-deploy agents you can pull.

Registry in the dashboard

Browse and publish from the registry’s web app.