Network Architecture

Network Independence Migration

Joel Johnston 2026-04-06 Pre-stroke design

Network Independence Migration

Author: Joel Johnston Date: 2026-04-06 Domain: Network Architecture Stroke Timeline: Pre-stroke

Abstract

Phased migration plan to move xsubi.com infrastructure off shared residential network onto independent connectivity. Problem: all xsubi services run on bare-metal hardware at a physical location sharing a residential internet connection. ISP (internet service provider) changes, router reboots, or network issues from other users affect production services. Three-phase plan: Cloudflare Tunnel (phase 1), roboNet mesh overlay (phase 2), isolated bridge network (phase 3). 47 files across all repositories contain hardcoded IP references requiring migration. Zero-downtime cutover strategy with rollback capability at every step.

Problem Statement

Current State

All xsubi services (robonet nodes, PostgreSQL, Docker registry, application servers) run on bare-metal hardware at a single physical location. That location shares a residential internet connection.

Failure modes:

  • ISP outage takes down all public-facing services simultaneously
  • IP address change (ISP reassignment) invalidates all hardcoded references
  • Router configuration by other users disrupts port forwarding
  • Physical location changes invalidate all connectivity

This is a single point of failure for the entire xsubi platform. Not a theoretical risk — it has occurred.

Blast Radius Analysis

47 files across all repositories contain hardcoded IP references. Breakdown by category:

Category Count Example
Database connections 12 192.168.27.212:5432
SSH targets 8 192.168.27.240
API endpoints 9 192.168.27.212:8099
Docker registry 4 192.168.27.192:5000
DNS records 6 Cloudflare A records pointing to dynamic IP
Monitoring targets 8 Prometheus scrape targets
Total 47

Any IP address change requires updating all 47 references, rebuilding affected containers, redeploying, and validating. This is a 2-4 hour manual operation per IP change.

Phase 1: Cloudflare Tunnel

Goal: Remove dependency on static IP for all public-facing services.

Mechanism

Cloudflare Tunnel runs a persistent outbound connection from the xsubi network to Cloudflare's edge. Traffic for xsubi.com enters Cloudflare's network and is routed through this tunnel to the origin server — no inbound port forwarding required.

Benefits:

  • Survives ISP IP changes (outbound tunnel, not inbound)
  • Survives ISP outage (tunnel reconnects automatically when connectivity returns)
  • DDoS protection at Cloudflare edge (traffic filtered before reaching origin)
  • TLS termination at edge (origin can serve plain HTTP internally)

Implementation

cloudflared daemon runs on the gateway machine. Configuration maps public hostnames to local service addresses:

tunnel: <tunnel-id>
credentials-file: /etc/cloudflare/credentials.json
ingress:
  - hostname: xsubi.com
    service: http://localhost:8080
  - hostname: api.xsubi.com
    service: http://192.168.27.212:8099
  - hostname: dashboard.xsubi.com
    service: http://192.168.27.240:8340
  - service: http_status:404

DNS CNAME records point to Cloudflare tunnel addresses. IP changes become irrelevant.

Parallel Operation During Migration

Cloudflare tunnels run in parallel with direct connections during migration. DNS cutover is instant (Cloudflare proxy). If anything breaks, revert the CNAME record and the direct connection works again.

Phase 2: roboNet Mesh Overlay

Goal: Internal services communicate through the roboNet mesh rather than direct IP.

Mechanism

roboNet mesh provides a location-independent service discovery layer. Services register capabilities with the mesh; consumers query the mesh for capability providers rather than hardcoding IP addresses.

Before:

db = psycopg2.connect("host=192.168.27.212 dbname=uc_library")

After:

host = mesh.resolve("postgresql", capability="uc_library")
db = psycopg2.connect(f"host={host} dbname=uc_library")

The mesh resolves capability names to current IP addresses at runtime. If a service moves to a different host, only the mesh registration changes — all consumers automatically get the new address.

Hardcoded Reference Elimination

The 47 hardcoded IP references are eliminated progressively as each service is registered with the mesh and consuming code is updated to use mesh resolution. Priority order: database connections (highest impact), API endpoints, monitoring targets, SSH targets (lowest — these require operator awareness, not runtime resolution).

Phase 3: Isolated Bridge Network

Goal: Dedicated network segment for xsubi infrastructure, physically separated from residential traffic at the switch level.

Mechanism

Managed switch with VLAN (virtual local area network) configuration:

  • VLAN 10: xsubi infrastructure (servers, compute nodes, NAS)
  • VLAN 1: residential (laptops, phones, smart home devices)

Traffic between VLANs is controlled by firewall rules. The residential network cannot directly access xsubi servers. The xsubi servers have a separate gateway path for outbound internet traffic.

Benefits

  • Residential network changes (router reboots, WiFi reconfiguration) do not affect xsubi services
  • xsubi services can be reached consistently regardless of residential network state
  • Foundation for physical location independence — if the infrastructure moves, the VLAN structure moves with it

Zero-Downtime Cutover Strategy

The migration strategy maintains rollback capability at every step:

  1. Deploy parallel: each phase deploys alongside existing connectivity, not replacing it
  2. Test in parallel: verify the new path works while the old path remains active
  3. Cut traffic incrementally: DNS changes affect some traffic first (low-traffic subdomains, then main domain)
  4. Keep old path hot: old path remains active for 72 hours after cutover — instant rollback if issues emerge
  5. Remove old path: only after 72-hour observation window with no issues

The same incremental, rollback-preserving approach applies to the hardcoded IP reference elimination — update one service at a time, verify, then proceed.

Architectural Alignment

The migration plan embodies the same architectural thinking as robonet:

  • Isolate concerns: each phase addresses one concern (public connectivity, internal routing, physical isolation)
  • Migrate incrementally: no big-bang migrations, each step is independently deployable and reversible
  • Maintain rollback: every step can be undone without affecting the step before it
  • Remove hardcoded state: IP addresses are configuration, not code — same principle as environment variables over hardcoded connection strings

The blast radius analysis (47 files, categorized by type) is the same decomposition pattern used for robonet architecture analysis — understand the full scope before touching anything, categorize by impact, address highest-impact items first.