Nasiko-Labs/nasiko

Deploy, route, secure, and observe any A2A -speaking agent with a single command — no gateway, no sidecar, no glue code. 📚 Documentation • 💬 Discord • 🐛 Report a bug Table of Contents What is Nasiko? Features Architecture Requirements Quick Start — Docker only (no Rust needed) Setup guides by operating system CLI — install & use Coding Agents & LLM Router Environment Variables Project Structure Troubleshooting Project Activity Documentation & Links Support Contributing License What is Nasiko? Running more than a couple of agents quickly turns into an operations problem: who calls whom , which key does each agent hold , what did that call cost , why did it fail? Nasiko is a single control-plane process that sits in front of every agent and answers all of that. It terminates TLS, authenticates every request, and proxies all agent-to-agent traffic itself, so agents are never publicly reachable — every hop is a checkpoint for rate limits, ACLs, and tracing. Different language, same A2A protocol — bring your own agents in Python, Rust, Go, or TypeScript. No proprietary agent format, no lock-in. Nasiko Dashboard — deploy agents, route traffic, manage tools, and watch traces. Features Feature What it does Deploy anything that speaks A2A nasiko deploy builds, pushes to the embedded registry, and runs it. No external registry required. Intelligent routing engine 3-stage pipeline — shortlist by embedding similarity, rerank on conversation context, then LLM final pick. Callers don't need to know your fleet. Single ingress, always proxied Agents are never publicly reachable; every agent-to-agent call is proxied through the server. MCP Gateway One permanent URL gives every agent a merged, permission-filtered view of Composio toolkits and custom MCP servers — without the agent holding the credentials. LLM Router Agents get an OPENAI_BASE_URL + a short-lived identity token instead of a real key. The router resolves provider/model/key server-side. No agent or log ever sees a real API key. Full observability Every dispatch and proxy hop emits a real OTel span -> one end-to-end trace. Token usage & cost are auto-collected from gen_ai.* attributes. Flow guards Redis-backed cascade limits (depth, fan-out, token budget, timeout, cycle detection) stop runaway agent loops. Encrypted secrets Per-agent secrets are AES-256-GCM encrypted at rest, injected only at deploy time. Access control User to-agent ownership/grants and an agent-to-agent allowlist gate every proxy call, independently. Embedded OCI registry Self-hosted, S3-backed registry with layer dedup — nasiko push / nasiko deploy need nothing external. CLI-first, no lock-in nasiko new , run , chat , deploy . Bring your own LLM provider. Architecture Nasiko is a single process — there is no separate gateway. Every inter-agent call is proxied back through the server, the single chokepoint where flow limits, ACLs, and observability are enforced. Durable state lives in Postgres , Redis , and S3 (RustFS), with optional observability via Tempo / Loki / the OTel Collector . flowchart LR subgraph Clients["Clients"] UI["Web Dashboard (embedded)"] CLI["nasiko CLI"] end subgraph CP["nasiko-server (single control-plane process)"] direction TB API["REST API (agents, builds, uploads)"] AUTH["Auth (session JWT, TLS, rate-limit, ACLs)"] OIDC["OIDC client (SSO)"] ROUTE["Routing engine (shortlist, rerank, select)"] PROXY["A2A Proxy (generic agent reverse-proxy)"] MCP["MCP Gateway (tools/list, tools/call, OAuth)"] LLM["LLM Router (OpenAI-compatible egress)"] OCI["Embedded OCI registry (/v2/*)"] FLOW["Flow guards (depth, fan-out, token budget, cycles)"] SECRETS["Secrets engine (AES-256-GCM)"] GITHUB["GitHub App integration"] end subgraph Infra["Backing services (Docker)"] PG[(Postgres)] RD[(Redis)] S3[(RustFS S3)] OTEL["OTel Collector"] TEMPO["Tempo"] LOKI["Loki"] end subgraph Agents["Agent containers (Docker runtime)"] A1["Agent A"] A2["Agent B"] A3["Agent C"] end UI --> API CLI --> API CLI -. "push / pull images" .-> OCI API --> ROUTE API --> GITHUB ROUTE --> FLOW OIDC --> AUTH SECRETS --> API AUTH -. gates .-> API AUTH -. gates .-> MCP AUTH -. gates .-> OCI AUTH -. gates .-> PROXY ROUTE -- "selected agent, direct call" --> Agents PROXY -. "proxied A2A calls (bypasses routing)" .-> A1 PROXY -. "proxied A2A calls (bypasses routing)" .-> A2 PROXY -. "proxied A2A calls (bypasses routing)" .-> A3 OCI -- "image pull at deploy" --> Agents Agents -- "OPENAI_BASE_URL" --> LLM Agents -- "tools/list, tools/call" --> MCP OCI --> S3 FLOW --> RD SECRETS --> PG AUTH --> PG CP --> OTEL --> TEMPO OTEL --> LOKI Loading Every request to an agent is either dispatched by the routing engine or proxied generically — both paths originate inside the server. Agents never receive a direct, public request, and both call back out into the LLM Router and MCP Gateway rather than holding real API keys or tool credentials. Requirements Component Minimum version Why Docker Engine + Compose V2 Compose V2 plugin (the docker compose command — not the legacy standalone docker-compose v1 binary) docker-compose.yml uses the extended depends_on: condition: service_healthy syntax; the Docker-only path needs nothing else. Rust 1.85+ (stable) The workspace targets edition = "2024" (see Cargo.toml ), stabilized in Rust 1.85 — only needed for the CLI / Path B developer setup, not the Docker-only path. A2A protocol Spec v1.0 exactly (latest upstream release: v1.0.1, Linux Foundation) Nasiko requires and hardcodes the A2A-Version: 1.0 header on every request; agents on older/pre-1.0 spec versions (e.g. 0.2.x, 0.3.0) are rejected with -32009 VersionNotSupported (see docs/A2A_PROTOCOL.md ). Any agent speaking v1.0 works, regardless of its implementation language. Quick Start — Docker only (no Rust needed) The fastest way to run Nasiko requires only Docker (with Compose). The server builds itself from source inside Docker. 1. Clone and configure git clone https://github.com/Nasiko-Labs/nasiko.git cd nasiko cp .env.example .env Edit .env and set at minimum: OPENAI_API_KEY — your OpenAI key (used by the routing engine and injected into agents) ADMIN_PASSWORD — password for the bootstrap admin account 2. Start the platform docker compose up -d This builds the server image and starts the full stack: Postgres · Redis · RustFS (S3) · OTel Collector · Tempo · Loki · nasiko-server . First build takes a few minutes (compiles Rust inside Docker) — subsequent builds are fast. Open http://localhost:8080 for the dashboard and log in with ADMIN_USERNAME / ADMIN_PASSWORD (default admin / changeme ). docker compose logs -f server # follow server logs docker compose down # stop everything docker compose up -d --build # rebuild after pulling new changes No Docker? Use the Developer / Rust setup below. Setup guides by operating system You have two supported paths : Path Requires Best for A. Docker-only Docker only Anyone who just wants to run the platform B. Source / Rust Rust + just Contributors, developers, hot-reload Path A — Docker-only Windows Install Docker Desktop -> https://www.docker.com/products/docker-desktop/ Open Docker Desktop and wait until the engine is running. In a terminal (PowerShell or Git Bash): git clone https: // github.com / Nasiko - Labs / nasiko.git cd nasiko Copy-Item .env.example .env # edit .env -> set OPENAI_API_KEY and ADMIN_PASSWORD docker compose up - d Open http://localhost:8080 and log in. Windows troubleshooting: see the Troubleshooting section (port conflicts, line endings, encryption key, WSL, Docker Desktop). macOS Install Docker Desktop for Mac -> https://www.docker.