Nasiko-Labs/nasiko
The Open Runtime for AI Agents
Nasiko – a control‑plane for A2A‑speaking AI agents
What it is – Nasiko is a single‑process server (written in Rust) that sits in front of any number of autonomous agents that speak the A2A (Agent‑to‑Agent) protocol. It handles deployment, routing, security, observability and secret management for those agents, so you never have to expose an agent directly to the internet.
Why it matters – Running a fleet of LLM‑powered agents quickly becomes an operations nightmare: you need to manage keys, rate limits, tracing, and the network topology between agents. Nasiko solves this by making the server the only public entry point. All inter‑agent traffic is proxied through it, where policies, ACLs, flow‑guards and cost‑tracking are enforced.
Core features (as listed in the README)
| Feature | What it does |
|---|---|
| Deploy anything that speaks A2A | nasiko deploy builds a container, pushes it to an embedded OCI registry, and runs it – no external registry needed. |
| Intelligent routing engine | 3‑stage pipeline – shortlist agents by embedding similarity, rerank with conversation context, then let an LLM pick the final target. |
| Single ingress, always proxied | Agents are never publicly reachable; every call goes through the server, enabling rate‑limits, ACLs and tracing. |
| MCP Gateway | Provides a unified, permission‑filtered view of toolkits (e.g., Composio) and custom MCP servers without giving agents the raw credentials. |
| LLM Router | Agents receive a short‑lived token and an OPENAI_BASE_URL; the server resolves the real provider/key, keeping API keys secret. |
| Full observability | Every dispatch emits an OpenTelemetry span; token usage and cost are auto‑collected from gen_ai.* attributes. |
| Flow guards | Redis‑backed limits on depth, fan‑out, token budget, timeout and cycle detection stop runaway loops. |
| Encrypted secrets | Per‑agent secrets are stored AES‑256‑GCM at rest and injected only at deploy time. |
| Access control | User‑to‑agent ownership and an agent‑to‑agent allowlist gate every proxy call. |
| Embedded OCI registry | Self‑hosted, S3‑backed registry with layer deduplication; nasiko push / nasiko deploy need nothing external. |
| CLI‑first, no lock‑in | Commands like nasiko new, run, chat, deploy let you manage agents without writing glue code. |
Architecture at a glance
- nasiko‑server – a single Rust process that hosts a REST API, authentication, routing, proxy, MCP gateway, LLM router, embedded OCI registry, flow‑guard logic and a secrets engine.
- Backing services – Postgres (metadata & secrets), Redis (flow‑guard state), RustFS S3 (artifact storage), optional OpenTelemetry stack (Tempo/Loki/Collector) for tracing and logs.
- Agents – run as Docker containers; they talk to the server via the A2A protocol (v1.0). The server proxies all agent‑to‑agent calls, so agents never receive a direct public request.
- Observability – each request creates an OTel span; the server can export to Tempo/Loki or any OTel collector.
The README includes a Mermaid diagram that visualises these components and their interactions.
Getting started (Docker‑only path – no Rust needed)
- Clone the repo and copy the example env file:
git clone https://github.com/Nasiko-Labs/nasiko.git cd nasiko cp .env.example .env - Edit
.env– at minimum setOPENAI_API_KEY(for the routing engine) andADMIN_PASSWORD. - Start the stack with Docker Compose:
This builds the server image (Rust compilation happens inside the container) and starts Postgres, Redis, the S3‑backed storage, OTel collector, Tempo, Loki and the nasiko‑server.docker compose up -d - Open http://localhost:8080 – log in with the admin credentials (
admin/ the password you set). - Use the web dashboard or the CLI (see below) to create, deploy and chat with agents.
For developers who want to build the CLI or server natively, the README provides a Path B that requires Rust 1.85+, just and Docker.
CLI highlights
nasiko connect <url>– point the CLI at a running control‑plane.nasiku auth login– authenticate with the admin account.nasiku new <template> <name>– scaffold a new agent project.nasiku deploy .– build the Docker image, push it to the embedded registry and start the agent.nasiku chat <agent>– interact with an agent via the terminal.nasiku secrets set– store encrypted per‑agent secrets.nasiku observe– view sessions, traces and cost statistics.nasiku maf– create and run multi‑agent flow workflows.
All commands are documented with --help and the project ships a full‑featured web UI that mirrors the CLI functionality.
Who should use Nasiko?
- ML/LLM engineers building fleets of specialized agents (e.g., retrieval, reasoning, tool‑calling) who need a unified deployment and routing layer.
- Product teams that want to expose agents to end‑users without giving them direct network access or API keys.
- Ops teams looking for built‑in rate‑limiting, ACLs, secret encryption and OpenTelemetry tracing for AI workloads.
- Researchers experimenting with multi‑agent workflows; the “flow guards” prevent runaway loops while still allowing complex graph execution.
License & community
- License: Apache‑2.0
- Docs: https://docs.nasiko.com
- Discord: https://discord.com/invite/HmnfkTfjFv
- Contributions: PRs are welcome; the repo shows badges for CI, issue tracker and a “PRs Welcome” label.
Bottom line: Nasiko is a production‑grade, Rust‑based control plane that lets you treat any A2A‑compatible AI agent as a first‑class service—handling deployment, secure routing, secret management and observability with a single command line or web UI.
Related
- Project
- Project
- Project
- Project
- Project