Multi-Device Quick Start

Connect two Crow installations so they share the same identity, sync memories, and can call each other's tools. This walkthrough takes about 15 minutes.

Prerequisites

• Two machines with Crow installed (see Home Server or Desktop Install)
• Node.js 24+ on both machines
• Network connectivity between them — Tailscale recommended (see Tailscale Setup), or same LAN

Step 1: Pick Your Home Instance

Decide which machine is your home instance (primary) and which is the satellite. The home instance is where your identity was first created.

For this guide, we'll call them server-a (home) and server-b (satellite).

Step 2: Export Identity from Home

On server-a:

cd ~/crow
npm run identity:export
# (non-interactive: npm run identity:export -- -- --passphrase <passphrase>)

You'll be prompted for a passphrase (minimum 12 characters) to encrypt the export. The command prints a base64 blob to the terminal — the master seed inside it is scrypt + AES-256-GCM encrypted under your passphrase. Copy the whole string.

Alternatively, download a backup file from the dashboard: the first-run wizard's final step (replayable from Settings → Help & Setup → "Download identity backup") saves crow-identity-backup.json in the same encrypted format.

Step 3: Import Identity on Satellite

On server-b (before the first gateway start, while it has no identity yet — the import refuses to overwrite an existing identity.json):

cd ~/crow
npm run identity:import -- <base64-blob>
# (a downloaded crow-identity-backup.json imports the same way:
#  npm run identity:import -- "$(base64 -w0 crow-identity-backup.json)")

You'll be prompted for the passphrase you chose during export. The import decrypts the backup and writes server-b's identity.json with the shared identity. If server-b already created its own identity, move ~/.crow/data/identity.json aside first.

Verify both machines have the same Crow ID:

# On server-a
npm run identity

# On server-b
npm run identity

The Crow IDs should match.

Step 4: Initialize the Satellite Database

On server-b, if you haven't already:

npm run init-db

Step 5: Start the Gateway on Both Machines

Each instance needs its gateway running:

# On server-a
npm run gateway

# On server-b
npm run gateway

Note the gateway URLs — by default http://<ip>:3001.

Step 6: Register Instances

On server-a, open a Crow session and register the satellite:

"Register server-b as a satellite instance at http://<server-b-ip>:3001"

On server-b, register the home instance:

"Register server-a as my home instance at http://<server-a-ip>:3001"

Using Tailscale?

Use Tailscale IPs or MagicDNS names for reliable cross-network connectivity:

"Register server-b as a satellite instance at http://server-b:3001"

Step 7: Verify Sync

On either machine:

"Show instance status"

You should see both instances listed with "online" status. Now test sync:

# On server-a
"Remember that multi-device sync is working"

# On server-b (wait a few seconds)
"Search memories for multi-device sync"

The memory stored on server-a should appear on server-b.

Step 8: Test Federation

Federation lets you call tools on the remote instance:

# On server-b
"Search all instances for project notes"

This queries both the local database and server-a's database, merging results.

Example: Oracle Cloud + Google Cloud

A common setup is Oracle Cloud (home, 1GB RAM) + Google Cloud (satellite, 1GB RAM) — two always-free clouds chained together.

Setup

Instance	Role	IP (Tailscale)	Guide
Oracle Cloud	Home	100.x.x.x	Setup guide
Google Cloud	Satellite	100.y.y.y	Setup guide

Follow the Google Cloud guide's Step 9: Chain with Oracle Cloud for the complete walkthrough.

What you get

• Redundancy — memories exist on both clouds
• Federation — query Oracle's projects from Google Cloud
• Free tier stacking — separate workloads across two machines
• Geographic distribution — Oracle (your home region) + Google Cloud (US)

Troubleshooting

Instances show "offline"

• Verify both gateways are running: check http://<ip>:3001/health
• Check network connectivity: curl http://<ip>:3001/health from the other machine
• If using Tailscale, verify both machines are on the same tailnet: tailscale status

Identity mismatch error during registration

• Re-run npm run identity on both machines and confirm the Crow IDs match
• If they differ, re-export from the home instance and re-import on the satellite

Memories not syncing

• Check that both gateways have been running since registration — sync starts when the gateway process connects
• Look at gateway logs for sync errors: restart the gateway with DEBUG=crow:* for verbose output
• Verify the instances are registered on both sides (registration is bidirectional)

Sync conflicts

When two instances edit the same memory offline, a conflict is created. Check the Nest dashboard's Instances panel for pending conflicts and resolve them there.

Tailscale not connecting between clouds

• Verify both machines are on the same Tailscale network: tailscale status on both
• Check that UDP port 41641 is open on both (required for direct connections)
• Try tailscale ping <other-ip> to test connectivity
• If using Google Cloud, verify the VPC firewall allows Tailscale UDP traffic

Gateway health check fails from remote machine

• Verify the gateway is running: curl http://localhost:3001/health on the machine itself
• Check UFW: sudo ufw status — port 3001 should be allowed from 100.64.0.0/10 (Tailscale)
• Check cloud firewall rules (Oracle Security Lists / Google VPC Firewall)

Next Steps

• Multi-Instance Guide — Full feature overview
• Instance Architecture — Sync internals and conflict resolution
• Tailscale Setup — Secure your cross-network connections