Skip to main content
The lifecycle guide covers building and deploying agents. This page covers the runtime underneath.

​
The two runtimes

Enterprise feature. The Kubernetes/KEDA runtime below is nasiko-ee only — the open-source ContainerRuntime implementation is Docker-only (no Kubernetes feature or dependency at all). AGENT_RUNTIME=kubernetes has no effect in an OSS-only install.
Selected with AGENT_RUNTIME. The control plane’s contract is the same either way: deploy, scale, restart, fetch logs, route traffic.

Docker

Single-replica, reached at localhost:port on the control plane host. No cluster to operate — right for local development and single-machine deployments.

Kubernetes

Deployments and Services, reached at the Service’s cluster DNS name. KEDA-driven autoscaling via min/max replica annotations, secrets refreshed before scale-up, in-cluster build pipeline.
Instrumentation is applied uniformly regardless of runtime — see observability.
Agent secrets are AES-256-GCM encrypted at rest and decrypted into a container’s environment at deploy time. Plaintext never touches disk outside the running container’s memory.

​
Two on-ramps, one deployment path

  • Push a pre-built image — nasiko push / nasiko deploy build locally and push layers and a manifest to the embedded /v2/* OCI registry (S3-backed, blob dedup across layers), then request a deployment.
  • Upload source — nasiko upload (or POST /api/agents/upload) ships an archive; the platform builds server-side, off the request path.
Both land in the same place. Deploying wires up networking, injects decrypted secrets, and instruments the container — no change to the agent’s code.

​
Server-side builds

Uploads are queued and picked up by a background worker, so a slow build never holds a client connection. You get a build ID immediately and poll for progress, or watch it on the Builds screen.
  • A failing build can’t take others down. Each build runs isolated from the worker’s scheduling loop — a crash resets just that job.
  • Retries cap at three attempts. A job that exhausts them is marked failed immediately, so nothing polling hangs forever.
  • Orphaned builds are recovered. A periodic sweep finds jobs still in-progress past any plausible build time — the signature of a replica that died mid-build — and resets or fails them.
The same pipeline handles uploaded MCP servers, which also get OS-level hardening and network segmentation.
In-progress image pushes are buffered on the instance that received them, so a push is sticky to that instance. Behind a load balancer, use session affinity for /v2/* traffic or large pushes will fail when split across replicas.

Agent Development Lifecycle

Scaffolding, running locally, deploying, versioning.

Agents in the dashboard

Deploying, scaling, and watching builds.

Observability

Traces, cost, and the configuration behind them.

Access control reference

Who can deploy, update, or manage an agent.