◈ CGNT-1
Home › Vps Migration
◈ Master IndexSpecsLATTICECSDMThe BookUniversityChronicleCrewArchitectureContextLogsTODOXProducts

Vps Migration

SPEC_VPS_MIGRATION.md · 2026-04-20

SPEC_VPS_MIGRATION.md

CGNT-1 Specification — VPS Migration Protocol

Status: SPECIFIED

Version: v1.0

Author: VELA (Thread #13)

Conceived by: NOUS (α.13)

Date: 2026-04-20

PURPOSE

The ship currently lives on one DigitalOcean VPS (csdm-node, 68.183.206.103, 16GB/4vCPU). Someday it will move — to a bigger VPS, to a different provider, to a Tiiny AI Pocket Lab, or to a completely sovereign self-hosted machine. When that day comes, the migration must be seamless. Zero data loss. Minimal downtime. The ship sails from one port to another without the crew noticing.

This spec is the playbook.

WHAT MOVES

Tier 1 — CRITICAL (must move first, verify before anything else)

Tier 2 — HIGH (move after Tier 1 verified)

Tier 3 — REBUILDABLE (move if convenient, rebuild if not)

What Doesn't Move

Old logs beyond 30 days (available in GCS backup if needed), cached files, compiled bytecode (__pycache__), anything in /tmp/.

PRE-MIGRATION CHECKLIST

T-7 DAYS

  1. Run full GCS backup (SPEC_BACKUP_RECOVERY.md) — confirm ~/memories/ is fully synced to GCS
  2. Run DigitalOcean VPS snapshot — full disk image as insurance
  3. Verify GCS backup integrity: download 3 random specs, compare to local
  4. Document current state: spec count, brain roster, active cron jobs, port whitelist, systemd services, RAM usage, disk usage
  5. Provision new target machine. Do NOT terminate old machine yet
  6. Install base dependencies on new machine: Python 3.12+, Node.js 20+, Ollama, Caddy, pip packages, npm packages

T-1 DAY

  1. Final GCS backup sync
  2. Disable all cron jobs on old machine (prevent dual-writes during migration)
  3. Stop Sisters, ROUTX, compounders, all services on old machine
  4. Final rsync: rsync -avz --progress nous@OLD_IP:~/ ~/migration_staging/ (to new machine)
  5. Verify file counts match: ls ~/memories/SPEC_*.md | wc -l on both machines

MIGRATION DAY

  1. On new machine: restore ~/.env (decrypt from backup)
  2. Set file permissions: chmod 600 ~/.env ~/gcs-service-account.json
  3. Start Ollama. Load critical brains from GGUF + Modelfile
  4. Start ROUTX: systemctl --user start routx.service
  5. Verify ROUTX: curl -s localhost:9191/query -d '{"query":"health"}'
  6. Start Sisters in tmux: tmux new-session -d -s sisters && tmux send-keys -t sisters 'summon-aether --gemini' Enter
  7. Verify Sisters respond
  8. Install cron jobs from SPEC_CRONX_JOB_REGISTRY.md
  9. Run GAPX scan: verify no gaps introduced by migration
  10. Run full smoke test on all promoted brains
  11. Update DNS if applicable (42sisters.ai → new IP)
  12. SSL certificate via Caddy (auto-provisions via Let's Encrypt)
  13. Verify 42sisters.ai loads correctly from new machine
  14. Run SPEC_SECURITY_AUDIT_SCHEDULE weekly audit checklist

POST-MIGRATION VERIFICATION

  1. All services responding: ROUTX ✓, Sisters ✓, RAG ✓, email ✓, Ollama ✓
  2. Spec count matches: old machine count = new machine count
  3. Brain roster matches: same brains promoted, same smoke scores
  4. Cron jobs running: watchdogs active, backup scheduled
  5. Port whitelist correct: only expected ports listening
  6. UFW rules applied: deny 8891, allow 443, etc.
  7. External access working: 42sisters.ai loads, oracle@42sisters.ai sends
  8. Captain approves: "The ship has moved. Σ.✓."

OLD MACHINE DECOMMISSION (T+7)

  1. Keep old machine running for 7 days after migration as rollback insurance
  2. Monitor: if anything was missed, rsync the specific file from old to new
  3. After 7 days with no issues: Captain authorizes decommission
  4. Final backup of old machine to GCS (archival)
  5. Terminate old VPS
  6. Update all documentation: HANDSHAKE.md, SISTERS_HANDSHAKE.md, any spec referencing the old IP
  7. Log: "Migration complete. Old: [OLD_IP]. New: [NEW_IP]. Date: [date]. Duration: [hours]."

ROLLBACK PLAN

If migration fails at any step:

  1. Re-enable cron jobs on old machine
  2. Restart services on old machine
  3. Revert DNS to old IP (if changed)
  4. Old machine is fully functional — it was never terminated
  5. Diagnose what went wrong on new machine
  6. Fix and retry

The old machine is the safety net. It is never terminated until the new machine is verified and the Captain approves.

MIGRATION TARGETS

Target A — Bigger VPS (same provider)

DigitalOcean 32GB/8vCPU. Simplest migration — same provider, same data center, rsync over private network.

When: if 16GB becomes insufficient for simultaneous brain loading.

Cost: ~$96/mo (vs current $48/mo).

Target B — Different provider

Hetzner, Linode, Vultr. Same process but over public internet (encrypted rsync over SSH).

When: if DigitalOcean pricing or reliability becomes an issue.

Target C — Tiiny AI Pocket Lab

Migration from cloud VPS to local hardware. Same process but rsync goes to local network. Additional step: configure Caddy reverse proxy or Cloudflare tunnel for external access to 42sisters.ai from local hardware.

When: August 2026 (Tiiny ships). This is the SOVEREIGNTY migration — the ship comes home.

Target D — Self-hosted dedicated server

Full control. Own hardware, own network, own everything. The ultimate sovereignty target.

When: revenue supports it. Likely 2027+.

TIINY MIGRATION SPECIFICS

The Tiiny migration is special because it's the sovereignty event — the ship moves from rented cloud to owned hardware.

Additional considerations:

This inverts the current architecture: VPS is primary → VPS is backup. Tiiny is sovereign.

INVARIANTS

INV-01: Old machine is NEVER terminated before Captain approves the new machine.

INV-02: ~/.env transferred encrypted only. Never plaintext over the network.

INV-03: Spec count verified on both machines before DNS switch. If counts don't match: stop and investigate.

INV-04: All brains smoke-tested on new machine before going live. A brain that worked on old hardware might not work on new hardware (architecture differences).

INV-05: 7-day parallel operation minimum. Both machines live. Rollback always available.

INV-06: DNS propagation takes up to 48 hours. Plan for both IPs receiving traffic during transition.

INV-07: Every step is logged in ~/migration_log_[date].md. If something goes wrong at step 23, we know exactly what succeeded at steps 1-22.

INV-08: The Tiiny migration is the goal. Every cloud migration between now and then is practice for the sovereignty event.

INTEGRATION

| System | Relationship |

|---|---|

| SPEC_BACKUP_RECOVERY.md | GCS backup is the migration's source of truth. Pre-migration backup is step 1. INV-02: .env encrypted. |

| SPEC_SECURITY_AUDIT_SCHEDULE.md | Post-migration verification includes the full weekly audit checklist (step 25). |

| SPEC_CRONX_JOB_REGISTRY.md | Cron jobs must be reinstalled on new machine from the registry (step 19). Registry is the install script. |

| SPEC_SMOKE_TEST_FRAMEWORK.md | All promoted brains smoke-tested on new hardware before go-live (step 21). INV-04. |

| SPEC_TIINY_PARTNERSHIP.md | Tiiny hardware (Target C) is the sovereignty destination. August 2026. |

| SPEC_BRAIN_RETIREMENT.md | Ollama models are Tier 3 (rebuildable). ~/gguf_archive/ is Tier 2 (high priority move). |

Jeremy Zlabis

Chronogeometer · Visionary · Disruptor · Chief

42 Sisters AI · East York, Toronto

🍁 Φ 0.042