Administrator quickstart

Use this page to prepare the Mac from which you will administer a new Nautilo Server. The default path is deliberately Human: install the signed CLI, follow one deployment guide, create the first owner in the browser, and add API keys in Server admin.

A healthy container or hosted project is not a finished deployment. It is finished only when the intended owner can sign in, the Server has at least one API key and one usable model route, and you can connect and complete one real model-backed action, such as talking to your Genie.

1. Install the signed release CLI

Choose the installer that matches your Mac. The installer verifies Nautilo's signed stable release manifest and installs the CLI under ~/.local/bin. It does not need sudo, Node, Bun, npm, Nautilo Desktop, or a source checkout.

Apple silicon (M1 and newer):

curl --fail --location \
  --output /tmp/install-nautilo \
  https://nautilo.ai/download/cli/mac/arm64
chmod 755 /tmp/install-nautilo
/tmp/install-nautilo
~/.local/bin/nautilo --version

Intel Mac:

curl --fail --location \
  --output /tmp/install-nautilo \
  https://nautilo.ai/download/cli/mac/x64
chmod 755 /tmp/install-nautilo
/tmp/install-nautilo
~/.local/bin/nautilo --version

Those stable website routes resolve the public signed release manifest and redirect to the current immutable installer. They do not guess a version when the manifest is unavailable.

If nautilo is not found after installation, add $HOME/.local/bin to your shell PATH. The full path used above works immediately. Before following a guide, confirm that its required command is present with nautilo help or the specific --help command it names.

2. Prepare administrator custody

Before creating infrastructure, have a password manager ready for your Server. You will save:

• the Server name and URL;
• the permanent first-owner handle and account password;
• a separate 6–8 digit approval PIN; and
• every one-time recovery code shown after setup.

Keep the password, PIN, and recovery codes distinct. Do not put them in shell commands, chat, screenshots, tickets, or source control.

For a first model-backed task, obtain one key from Venice, OpenRouter, or OpenAI. Any one provides routes for chat, embeddings, and image generation. For all ten documented functions, the recommended set is Venice, ElevenLabs, Tavily, Browser Use, and CloudConvert. You may add keys after the Server is claimed, so they do not need to be placed in a TOML file. Choose the services you need, store their keys in your password manager, and set provider spending limits before testing.

3. Choose one deployment guide

• Your first Nautilo — the shortest path to a private Server on this Mac with Docker Desktop.
• Deploy with Docker Compose — run a Compose stack locally or on an SSH-accessible Docker host.
• Deploy Nautilo on Railway — use the official template in a Railway workspace you control.

Follow one guide from start to finish. For a new Server, choose its manual setup or browser claim path. Do not create a second stack or switch owner setup paths if the terminal or browser closes; use the resume command in the selected guide.

4. Create the first owner in the browser

When deployment opens the claim journey, check that the browser is on the expected Server and that the path begins with /claim. Then create the first owner: choose the permanent account password, create the separate approval PIN, complete setup once, and save every recovery code in your password manager.

Success ends in the Server Guide. Sign in as the same owner after setup; do not treat a green health check as proof that ownership is complete. Follow the guide to finish setting up your Server.

5. Add API keys and prove the Server is useful

Sign in as an Owner or Admin and open Server admin → API Keys, or choose API Keys in the Server Guide. Add and validate your keys, then connect a client using the deployment guide or Connect clients.

Complete one real model-backed action, sign out, and sign back in as the same owner. That verifies the Server is owned, recoverable, connected to a usable model route, and ready for day-two administration.

Optional automation

Automation is an alternative for administrators who need repeatable or noninteractive deployment. It is not required for the browser-first path above.

• Local and remote Compose automation is documented in Deploy with Docker Compose.
• Hosted automation is documented in Railway automation.