Deploying and managing agents

Deploying is one command against a connected cluster. Day-2 operations use the same command set regardless of the runtime underneath.

Connect to a cluster

nasiko connect https://nasiko.example.com --name prod
nasiko auth login

Or run one locally:

nasiko up             # Postgres, Redis, and the control plane, registered as "local"
nasiko clusters       # list configured clusters
nasiko use prod       # switch the active cluster
nasiko down           # stop the local cluster

Every command below runs against the active cluster.

Getting an image onto the platform

Build locally, push
Upload source

nasiko deploy .                    # build, push, deploy
nasiko deploy . --name my-agent
nasiko deploy . --port 8080
nasiko deploy . --env-file .env
nasiko deploy . -e API_KEY=sk-xxx

Builds the image locally, pushes it to the cluster’s embedded registry, and starts the container. Names are unique per cluster — deploying the same name updates the existing agent.For CI, nasiko push . builds and pushes without starting the container.

nasiko upload .

No local Docker needed. Zips your source (or takes a .zip) and posts it; a background build worker builds and deploys it. Returns a build ID immediately (202 Accepted) — watch progress with nasiko logs or the Builds view.

Every deployment is automatically instrumented for observability and receives its decrypted secrets as environment variables. No extra step for either.

Day-2 operations

Command	What it does
`nasiko ps`	List running agents (`--json` for machine-readable output)
`nasiko logs <agent>`	Tail container logs (`-n 200` for more history)
`nasiko stop <agent>`	Scale to zero, keeping config and state
`nasiko start <agent>`	Resume a stopped agent
`nasiko restart <agent>`	Recreate the container, picking up secret and env changes
`nasiko scale <agent> <n>`	Scale to `n` replicas
`nasiko rm --name <agent>`	Terminate and deregister (`-f` skips confirmation; accepts a raw UUID positionally instead of `--name`)
`nasiko status`	Control plane health and metrics

restart and stop/start are not interchangeable. restart tears down and recreates the container — this is what picks up changed secrets or environment variables. stop/start pause and resume without touching configuration.

Secrets

Secrets are encrypted environment variables injected at deploy and restart time, at two scopes:

# Vault — every agent you own
nasiko secrets set OPENAI_API_KEY sk-xxx
nasiko secrets ls
nasiko secrets rm OPENAI_API_KEY

# Agent-specific — overrides the vault
nasiko secrets set DB_URL postgres://... --agent my-agent
nasiko secrets ls --agent my-agent

Precedence, highest first: nasiko deploy -e → agent-specific secret → vault secret. A changed secret takes effect on nasiko restart. Full model, including team and department scoping: secrets overview.

Observability

nasiko observe    # sessions, traces, spans, project stats, TokenOps, insights

Traces, logs, and cost are available as soon as your agent handles traffic. See the orchestrator for how a session groups a multi-agent conversation.

Versions and lifecycle

How versions map to what’s running.

Secret management

Vault vs. agent-specific, precedence, rotation.

Getting Started

CLI

ADLC

Dashboard

Platform

MCP Gateway

MCP Hub

Agents in Artifact Registry

Connect to a cluster

Getting an image onto the platform

Day-2 operations

Secrets

Observability

Next

Versions and lifecycle

Secret management

​Connect to a cluster

​Getting an image onto the platform

​Day-2 operations

​Secrets

​Observability

​Next

Versions and lifecycle

Secret management

Connect to a cluster

Getting an image onto the platform

Day-2 operations

Secrets

Observability

Next