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

Enterprise feature. This section describes the standalone artifact registry (nasiko-ee), not OSS control-plane behavior — see artifact registry.
Each publish to a shared artifact registry creates a new version row under that artifact’s name. This is separate from deploying to a cluster.
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.

​
Lifecycle status

Every version starts at preview. A registry administrator can promote it: 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

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.

​
Next

Artifact registry

Browsing, searching, and publishing.

Deploy and manage

Push, upload, and operate a deployment.