> ## 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.

# Versions and lifecycle

> How AgentCard.json versions map to deployments, and how published artifacts age.

"Version" means two things on Nasiko: the image tag behind a deployed agent, and the version history of an artifact published to a shared registry.

## Deployed-agent versions

The `version` field in `AgentCard.json` is the image tag — the deployed image is `name:version`. Bump the field and redeploy.

```json AgentCard.json theme={null}
{
  "name": "code-reviewer",
  "version": "0.2.0"
}
```

Agent names are unique per cluster. Deploying the same name updates the existing agent in place, whether or not the version changed. `nasiko restart` recreates the container from the current image and secrets, without rebuilding.

There's no rollback command — roll back by redeploying an older version tag.

## Registry artifacts

<Warning>
  **Enterprise feature.** This section describes the standalone artifact registry (`nasiko-ee`),
  not OSS control-plane behavior — see [artifact registry](/artifact-registry/overview).
</Warning>

Each publish to a shared [artifact registry](/artifact-registry/overview) creates a new version row under that artifact's name. This is separate from deploying to a cluster.

<Note>
  Artifact versions are free-text strings, not enforced semver. The registry never does semver comparison — "latest" means most recently published and non-yanked, not highest number. Keep your version strings monotonic if you want "latest" to mean what you expect.
</Note>

### Lifecycle status

Every version starts at `preview`. A registry administrator can promote it:

| Status     | Meaning                     |
| ---------- | --------------------------- |
| `preview`  | Default for a new version   |
| `stable`   | Considered production-ready |
| `verified` | Highest confidence label    |

These are informational labels — the registry only displays and filters on them, it doesn't change behavior. Define your own conventions.

Administrators update status, description, tags, license, framework, and other metadata with a partial update: send only the fields you're changing.

### Yanking

Yanking is separate from lifecycle status and isn't available through partial update. A yanked version:

* Disappears from browsing, listing, and search
* Stays individually resolvable — anyone who pinned that exact `owner/name/version` can still fetch it, and it remains in the version history

So yanking stops recommending a version without breaking existing consumers.

### Artifact types

```sh theme={null}
nasiko registry search "code review"     # keyword search across types
nasiko registry search -t agent          # filter by type
```

Recognized types: **skill**, **agent**, **tool**, **mcp** (an MCP server), and **executable** (a standalone binary or CLI). Each type constrains valid packaging formats — a skill ships as source or an open-standard package; an agent or MCP artifact can ship as source, a Dockerfile, a compose file, a pre-built image, or an external card reference.

### Publishing

Publishing is an administrator action, authenticated separately from your platform login. See [artifact registry](/artifact-registry/overview).

## Next

<CardGroup cols={2}>
  <Card title="Artifact registry" href="/artifact-registry/overview">
    Browsing, searching, and publishing.
  </Card>

  <Card title="Deploy and manage" href="/adlc/deploy">
    Push, upload, and operate a deployment.
  </Card>
</CardGroup>