# Canary Deploy Process

## Overview

Deploy changes to the secondary server first (192.168.1.198), verify health, then deploy to the primary server (192.168.1.228). This reduces risk by catching issues before they affect the main system.

## Steps

### 1. Deploy to Secondary (Canary)

```bash
# Deploy to secondary server only
TARGET_HOST=archipelago@192.168.1.198 ./scripts/deploy-to-target.sh --live
```

### 2. Verify Health

```bash
# Check health endpoint
curl -s http://192.168.1.198/health

# Check backend service
ssh -i ~/.ssh/archipelago-deploy archipelago@192.168.1.198 "sudo systemctl status archipelago"

# Spot-check the UI
# Open http://192.168.1.198 in browser, verify pages load
```

### 3. Deploy to Primary

Once the secondary is healthy and verified:

```bash
./scripts/deploy-to-target.sh --live
```

### 4. Verify Primary

```bash
curl -s http://192.168.1.228/health
```

## Quick Deploy to Both (Non-Canary)

If you're confident and want to deploy to both at once:

```bash
./scripts/deploy-to-target.sh --both
```

This deploys to 228 first, then copies the built artifacts to 198. Not a true canary — use the step-by-step process above for safer rollouts.

## Rollback

If the canary (198) shows issues, do NOT deploy to primary. Fix the issue first.

If primary (228) shows issues after deploy:

```bash
# Check logs
ssh -i ~/.ssh/archipelago-deploy archipelago@192.168.1.228 "sudo journalctl -u archipelago -n 50"

# Restart services
ssh -i ~/.ssh/archipelago-deploy archipelago@192.168.1.228 "sudo systemctl restart archipelago && sudo systemctl restart nginx"
```

## Post-Deploy Health Check

The deploy script automatically waits up to 60 seconds for the health endpoint to return 200 after deploying. If it fails, check the backend logs for errors.