Nautilo: A First-Timer's Guide to the Self-Hosted Multi-User AI Agent Workspace

Who It's For

Nautilo is a self-hosted, multi-user AI workspace open-sourced by agentsea (MIT license). Its official positioning is "AI goes multiplayer": humans and AI agents (Genie agents) collaborate in shared Rooms across desktop, mobile, and web. It suits:

• Individuals or small teams who want to build their own self-hostable AI collaboration environment where multiple members share a workspace with AI agents.
• Users who want to unify tool discovery, registration, and MCP connections on one platform (its MCP client package handles tool discovery, registration, and MCP connections).
• Early adopters willing to accept that the project is in alpha and tolerate instability.

Situations where it's a poor fit or warrants caution:

• Production-grade stability is required: the project is explicitly in alpha and not recommended for business-critical workloads.
• You don't want to self-host or have no Docker environment: even local evaluation requires Docker to run the local PostgreSQL and Logto infrastructure.
• Using models or services may incur vendor costs; provider keys must be configured yourself. Evaluate whether you're willing to bear such costs first.
• The evidence does not state the release status or system requirements of each client (desktop, mobile, web); defer to the official documentation for these details.

Your First Try in 3 Minutes

The main path officially recommended for first-time users is the Local Deploy Quickstart on Mac (a single-machine evaluation deployment using Docker Desktop and the signed Nautilo CLI). Follow the official documentation at https://nautilo.ai/docs/operator/deploy/local :

1. Prerequisite: a Mac with Docker Desktop installed (the local PostgreSQL and Logto infrastructure depend on Docker).
2. Open the Local Deploy Quickstart page above and follow the instructions to install the signed Nautilo CLI and run the single-machine evaluation deployment.
3. Once the deployment succeeds, connect to this local Nautilo service with a client to start using it.

If you'd rather run from source (also covered in the official docs, consider it a fallback):

git clone https://github.com/agentsea/nautilo.git
cd nautilo
bun install --frozen-lockfile
bun run dev-stack --instance my-nautilo-dev

Note that the official requirements for the source setup pin Bun 1.3.11 and Node 24.x, and you must use an unused instance name.

A low-risk first action: after deployment, do read-only operations only — open the client to browse rooms and the tool list, and check that the service and UI respond normally; don't rush into write tasks. Success signals: the local service is up in Docker and the client connects and shows the workspace UI. If you later need mobile access or team access via a server, the official recommendation is to switch to a hosted deployment (the docs provide Railway and Docker Compose guides).

A reminder: local deployment involves local writes and starting infrastructure — it is not a read-only operation. Uninstalling or stopping containers is a control mechanism, but the official evidence does not describe a complete rollback path, so keep your own cleanup measures in place.

Use Cases

Case 1: Set up a single-machine evaluation environment and connect a client. Scenario: you want to try Nautilo on your own Mac first to see if it fits. Approach: follow the Local Deploy Quickstart to install Docker Desktop and the signed Nautilo CLI, complete the single-machine evaluation deployment, then open a client to connect to the local service. Expected outcome: you get an accessible Nautilo workspace on your machine (the server side provides Fastify HTTP and WebSocket APIs serving clients), and you can log in and look around. If you later need mobile or team server access, switch to the Railway or Docker Compose hosted deployment docs.

Case 2: Spin up a dev instance from source to validate tool and MCP capabilities. Scenario: you're a developer and want to check in a development state whether its tool discovery and MCP connections meet your needs. Approach: in an environment pinned to Bun 1.3.11 and Node 24.x, run the four commands above with an unused instance name (e.g., my-nautilo-dev) to start the dev stack; the local PostgreSQL and Logto are provided by Docker. Expected outcome: once the dev stack is running, the server serves clients via the Fastify HTTP/WebSocket API, and the MCP client package handles tool discovery, registration, and MCP connections — the evidence is sufficient to confirm these components exist and run, but it provides no concrete call parameters or output examples; for tool-level details, rely on the actual UI and official documentation.

Boundaries of Use

• Read/write nature: Nautilo is a continuously running self-hosted service that starts and writes to local infrastructure (PostgreSQL, Logto); it is not a one-shot read-only tool. For a first try, observe rather than write.
• Credentials and prerequisites: Using models or services may incur vendor costs, and provider keys must be configured; the official evidence does not specify which keys are required for startup — defer to the deployment documentation.
• Side effects and confirmation points: Running the deployment brings up Docker containers and writes local state; operations involving generated content call external model services. The official evidence provides no unified rollback/cleanup procedure.
• Explicit official limitations: The project is in alpha; the Local Deploy Quickstart is a single-machine evaluation setup and is not suitable as a mobile endpoint or a team server.
• Unconfirmed information: The concrete tool list, the readOnlyHint of each MCP server, the release status of the desktop/mobile clients, and data privacy and retention policies are all not covered by the evidence — consult the official documentation before making decisions involving sensitive data.