--- title: Nasiko description: Register, govern, and cost-account every AI agent your organization runs. product: Marketplace url: https://docs.digitalocean.com/products/marketplace/catalog/nasiko/ last_updated: "2026-06-12" --- > **For AI agents:** The documentation index is at [https://docs.digitalocean.com/llms.txt](https://docs.digitalocean.com/llms.txt). Markdown versions of pages use the same URL with `index.html.md` in place of the HTML page (for example, append `index.html.md` to the directory path instead of opening the HTML document). # Nasiko Generated on 12 Jun 2026 from [the Nasiko catalog page](https://marketplace.digitalocean.com/add-ons/nasiko) ## Overview Most teams do not have an agent problem. They have an agent estate problem. Agents are built in different frameworks, call different models, hold different credentials, and are deployed by different people. Six months in, nobody can answer three questions: what is running, what it can reach, and what it cost. Nasiko is an Open Runtime that answers them. Open means it belongs to no vendor inside it: any framework, any language, any model provider, and the freedom to change your mind about all three later. It sits underneath your agents rather than replacing them, so whatever you have already built continues to work. Register an agent once, and it inherits access control, tool permissions, cost attribution, and end-to-end tracing without a line of your agent code changing. ## What you get **One registry for the whole estate.** Every agent is listed with an owner, a status, and a version history. Agents built with different frameworks and in different languages all appear the same way because the platform communicates with them via a container contract rather than an SDK you have to adopt. **Three ways to publish an agent.** Point Nasiko at a GitHub repository, upload a zip, or deploy from the CLI. The platform builds it and registers it. Use whichever fits how that team already works, and use different ones for different teams. **A registry of agents you did not have to write.** The artifact registry holds shared agents, skills, and templates. Browse it, deploy something working in a couple of clicks, then publish your own back for the rest of the organization to pull. **Access control that covers both agents and people.** Grant users the right to chat with, manage, or deploy a specific agent. Separately, decide which agents may call which other agents. Organize it by department and team so access follows how your organization is actually structured. **Tool access agents cannot exceed.** Connect to external MCP servers via URL or deploy your own, then choose, per agent, which tools it may call. An agent discovers what it is permitted to use at runtime, so there are no hardcoded tool names and no way to reach a tool it was not granted. **Spend you can attribute.** Token usage and cost broken out per agent and per model, compared month over month, exportable to CSV. Not a provider invoice you have to reverse engineer. **One trace per interaction, with cost attached.** Follow a question from the moment it arrives, through every agent hop, to the answer. Agent-to-agent calls are proxied through the platform rather than made directly, which means limits and tracing apply at every hop, not just the first. **Bounded multi-agent runs.** A flow guard bounds agent-to-agent calls, so a loop between two agents cannot quietly consume your budget while nobody is watching. **Secrets that stay out of your repo.** Encrypted at rest, injected at deploy time, rotated on demand. ## Two ways in, and neither requires the other **The dashboard** is for governing and for getting started. Chat, registry, access control, tool permissions, traces, spend, secrets, and admin all live there. If your agents were published by someone else, this is the only surface you need. **The CLI** is a full agent development lifecycle rather than a deploy command: - **Scaffold** a project from a template, with its agent card and container definition generated for you - **Run and test locally**, chatting with the agent against the same routing and access checks it will meet once deployed - **Deploy** to your instance, or hand the build to the platform if you would rather not build locally - **Operate** what you shipped, with logs, scaling, restarts, secrets, and teardown - **Version** deliberately, with agent card versions mapped to deployments, so you always know what is live and what it replaced Framework and language are your choice throughout. The platform talks to your agent over a container contract rather than an SDK, so the lifecycle works the same whether the agent is fifty lines or a large codebase, and it is the same lifecycle regardless of which of the three publish paths a team prefers. ## The fastest path to something working You do not need to build an agent to determine whether this fits. 1. Sign in to your instance 2. Deploy a sample agent from the artifact registry and chat with it 3. Bring one of your own, from GitHub, a zip, or the CLI 4. Connect a tool over MCP and choose what that agent may call 5. Open the trace and the spend view, and see the same run from both angles Full walkthrough: [**https://docs.nasiko.com/quickstart**](https://docs.nasiko.com/quickstart) ## Documentation and support - Documentation: [https://docs.nasiko.com/](https://docs.nasiko.com/) - Discord: [https://discord.gg/a4aU2kcAyy](https://discord.gg/a4aU2kcAyy) - Email: [support@nasiko.com](mailto:support@nasiko.com) ## Software Included *This Marketplace listing does not include a detailed software list.* ## Installing this Add-On using the Control Panel Click the **Deploy to DigitalOcean** button to install this add-on. If you aren’t logged in, this link will prompt you to log in with your DigitalOcean account. [![Deploy Nasiko to DO](https://www.deploytodo.com/do-btn-blue.svg)](https://cloud.digitalocean.com/add-ons/create/nasiko) ## Getting Started After Deploying Nasiko *This Marketplace listing does not include getting-started steps.*