Connect clients
Connect Nautilo clients to the intended Server and prove the account works.
Deployment is finished only when the right person reaches the right Server. Do not test against a convenient browser tab and assume it belongs to the profile you just deployed.
Verify the active target
nautilo profile list
nautilo status --profile circle-serverReplace circle-server with the intended deployment profile. Check the profile
name, instance identity, and Server URL against your deployment receipt.
profile current displays the saved active profile, which may be a different
target; it is not a substitute for an explicit --profile on an operation.
Connect a person
Give the person the exact client-facing Server URL and an invitation or their own account's sign-in instructions. Do not share your owner password or a first-owner claim link. Choose the client they will actually use:
| Client | Start here | Expected result |
|---|---|---|
| macOS Desktop | Install Desktop, launch the app, and enter the Server address | The intended Server is selected and the person signs in as themselves |
| Web | Open the Server URL using the web-client guide | The Server's own Workbench opens, not the Nautilo marketing website |
| iPhone or Android | Follow Mobile connection and recovery | The phone verifies the Server and opens its sign-in flow |
Public access uses HTTPS. The same-machine local guide
uses loopback HTTP; localhost on another computer or phone means that other
device, not your Server. For a trusted local network, read the separate
LAN limitations before sharing an HTTP address.
Administrator CLI sign-in is separate
nautilo login --profile circle-server
nautilo whoami --profile circle-server --format jsonnautilo login opens browser authentication on a workstation. Add --remote
to the same explicitly profiled command for device flow on a headless machine
when the Server supports it. This authenticates the administrator CLI; it does
not install or launch Desktop, sign another client in, or open a chat terminal.
The signed standalone CLI is an administration tool, not the source client TUI.
The Desktop, Web, and Mobile clients must reach the intended Server. A successful network connection is not enough: sign in as the intended person, enter a Room, and make one model-backed turn.
Acceptance checklist
- The Server identity matches the selected profile.
- The owner login is known; no default or invented password is involved.
- Setup state is ready.
- At least one intended model route works.
- A second client, when used, reaches the same Room and durable history.
If the Server is fresh and unclaimed, stop. Return to the Administrator quickstart; do not silently create an unrecorded owner or wipe the deployment.
For a failed sign-in, use account recovery. For a missing Browser or Terminal control, check client and workstation prerequisites instead of changing deployment profiles.