One server can separate several organizations
Nakama uses an organization as its tenant boundary. Profiles, sessions, members, tools, skills, MCP servers, usage data, and shared memory belong to that organization. Roles split platform admin, org admin, member, and viewer access. A viewer can read history without invoking an agent, while an org admin manages membership. This is the reason to consider Nakama over a personal desktop agent: one deployment can serve multiple teams or customers without intentionally sharing their agent state.
The separation has an administrative catch. Platform admins still provision profiles and tools, even inside organizations run by org admins. Removing an organization hides it from chat, workers, and the switcher, but the docs say members, profiles, and files remain on disk. The last organization cannot be removed. Those semantics may be right for recoverability, yet an operator must understand that deletion from the interface is not secure erasure and that the platform administrator remains powerful across tenant boundaries.
Profiles bind one model to selected tools
Each profile combines its instructions, memory, model, skills, built-in tools, custom tools, and assigned MCP servers. The server supports 10 provider types in its current table, including OpenAI, Anthropic, Gemini, Ollama, OpenRouter, DeepSeek, Cerebras, Fireworks, Cloudflare Workers AI, and custom OpenAI-compatible endpoints. Two profiles in one organization can use different models. Provider-dependent behavior matters: built-in web search is limited to OpenAI or Anthropic, while Telegram audio transcription requires OpenAI.
MCP support is a client feature, with HTTP and stdio transports. A stdio server gets one process per profile and starts in that profile's workspace; HTTP connections are shared across assigned profiles. Tools are namespaced and cached when the server connects, then require a sync when the remote list changes. Platform admins register servers and assign them. This is flexible, but every HTTP header, stdio environment variable, and spawned command expands the secrets and code that a Nakama administrator must audit.
What happened when we ran it
Our sandbox installed commit cf3d6ac in 72 seconds using Bun. The monorepo pulled 1,061 packages and occupied 1,509 MB on disk. Its 1,360 files contained about 223,627 lines of source, and the repository had 5 CI workflow files plus a Dockerfile. The build completed successfully in 37 seconds. This is a sizable Node installation for a service presented as one Docker container, though the container remains the simpler operator path.
Tests ran for 466 seconds and exited with code 1. The log tail shows 3 failed tests and 1 error in @nakama/db, plus 8 failed tests and 5 errors in @nakama/server. It also reports completed runs for the CLI, Telegram, WhatsApp, web, and Discord packages, with their displayed cases passing. The provided tail does not identify the failing assertions or their causes, so the finding is limited to package scope and outcome rather than a theory about missing services.
Custom tools currently share the server's trust
Open issue #447 is the clearest deployment boundary. It says custom JavaScript handlers execute in the server process and custom Python tools inherit the full server environment. The issue is labeled critical and scheduled for later. A malicious or careless tool can therefore reach beyond one agent's intended workspace or secrets. Profile-level assignment controls which agent can call a tool, but it does not turn the tool implementation into untrusted code. Only platform administrators should install code they have reviewed.
Other open security work includes request-body validation and size limits, global and stricter authentication rate limits, redaction of message content and phone numbers from channel logs, and avoiding raw internal errors in client responses. Issue #374 also groups smaller fixes involving login CSRF, proxy HSTS, Telegram state, WhatsApp local authentication, and platform-admin access. An internal network and reverse proxy can reduce exposure, but they do not replace the missing application controls described in those issues.
v0.4.3 is moving faster than its operations story
Release v0.4.3 shipped on 2026-08-23, and GitHub recorded another push on 2026-08-25. The release added WhatsApp group handling and an optional skill-curation feature alongside web and issue-template fixes. GitHub showed 52 open issues and pull requests combined. Recent work covers profile export, channel behavior, browser installation, and security. This is active development, which is encouraging for bug turnaround and risky for teams that want slow configuration drift. Pin the image and rehearse upgrades.
Backup support exports the whole data root as a ZIP, and restore replaces the active root rather than merging records. That archive may include API keys, auth data, memory, custom code, and SQLite, so it deserves the same encryption and access control as production secrets. Nakama is most convincing as an internal team agent hub run by one capable administrator. The feature set already reaches far; its current security queue and failing server tests say the safe deployment boundary should stay narrow.