Where and how your agent runs
Pick between managed and self-hosted Nairi runtimes, and understand how concurrency, container provisioning, and scaling work for each option.
Every Nairi agent runs inside a container. Where that container lives is your choice.
Two runtime options
Managed (default)
Nairi runs the container on our infrastructure. You don't think about hosts, updates, or process supervision.
What you get:
- Automatic updates to
nairid, Claude Code, and the rest of the toolchain. - Credential isolation by default. The secret proxy and mcp-proxy sidecars sit between the agent and the outside world. Vault secrets are swapped in only on outbound HTTPS calls to allowed domains — the agent's process never sees the plaintext. MCP server credentials live entirely on the mcp-proxy side; the agent only ever sees the MCP's tool surface, not the API keys or connection strings behind it. A compromised prompt, a buggy skill, or a hijacked subprocess can't read what isn't in scope.
- Logs and crash recovery handled by us.
This is what every plan defaults to. Pick this unless you have a specific reason not to.
Self-hosted
You run nairid yourself, on your own machine, VM, or container. Nairi's backend still orchestrates jobs (Slack/Discord events, scheduled jobs, API calls), but the actual work happens on your hardware.
Reasons to self-host:
- Data residency or compliance. Source code and tool output never leave your infrastructure.
- Private network access. The agent needs to reach an internal database, VPN-only API, or a service that isn't on the public internet.
- Run your own LLM. Point the agent at a model you host yourself — Ollama, LM Studio, vLLM, llama.cpp, or any OpenAI-compatible endpoint. Inference stays entirely on your hardware; no prompt or tool output is sent to Anthropic, OpenAI, or any third-party provider. This is the only configuration where the model itself runs on your infrastructure. Use the OpenCode CLI (
--agent opencode) with--model <your-provider>/<your-model>and point OpenCode at your local endpoint. - Custom hardware. GPU-backed runtimes, larger disks, or specific CPU SKUs.
- Free, unlimited self-hosted agents on every plan. You bring the compute, you keep the savings.
Self-hosting requires you to install and supervise nairid, keep dependencies up to date, and handle credential injection yourself. There's no secret proxy on a self-hosted runtime, so vaults aren't available.
Setup is documented in Self-hosting Nairi.
Tenancy and isolation
Containers are a deployment detail, not the tenancy boundary. The boundary is your org: every agent your org creates runs in a container that belongs to your org, and nothing crosses that line.
- Per-agent containers. One container per agent, with its own filesystem, env vars, network namespace, and credentials. Containers are started when the agent is deployed and torn down when it's deleted.
- Org-scoped. Every container belongs to exactly one org — the one that created the agent. There is no connectivity between containers in different orgs. A compromised agent in another customer's org cannot read your codebase, secrets, or tool calls.
- No shared state by default. Two agents inside the same org also don't share filesystems or env vars. If you want them to share something (a knowledge base, a cache, a queue), wire it up explicitly via an MCP, a vault, or shared infrastructure you control.
- Credentials never cross containers. Vault secrets are injected per-container by the secret proxy on outbound HTTPS calls, only to allowed domains. They are never visible in another agent's env vars, logs, or memory. MCP server credentials live on the mcp-proxy sidecar of that specific agent — see Secret handling for the full design.
The same model applies to self-hosted runtimes, except the OS-level boundaries are whatever you have set up on your machine. Two nairid instances on one host each get their own working directory and process, but tenant scoping there is up to your OS and network configuration.
Concurrency and parallel work
How many tasks can run in parallel is set at the org level by your plan, not per agent:
| Plan | Concurrent tasks |
|---|---|
| Hobby | 1 at a time |
| Team | 5 at a time |
| Self-hosted | You control it yourself — no platform-imposed cap |
When the org cap is hit, additional tasks queue until a slot frees up. The cap is shared across every agent in the org and every channel (Slack, Discord, API, scheduled jobs).
On self-hosted, the only limits are whatever your hardware can run and how many nairid instances you start. See Self-hosting Nairi for the multi-instance setup.
Related
Can't find what you're looking for? Email support@nairi.ai.
How to deploy an agent
Walk through every setting on the agent editor: integration, model, prompt, rules, MCPs, skills, env vars, vaults, and your code repo.
Rules
Long-lived markdown instructions that shape how an agent behaves across every task. Define style, policies, and guardrails once, reuse everywhere.