Hudu Migration — CHANGELOG

2026-07-15

Action: docker compose up on app2 (152.53.39.202)
Obstacle: App pods needed pulling (~400 MB), took 5+ minutes
Fix: Waited. All 4 containers healthy.
Obstacle: DB restore failed — hudu_production didn't exist on fresh PostgreSQL
Fix: CREATE DATABASE hudu_production then restore. 21 companies, 3 users verified.
Obstacle: App was redirecting to https://...:81/ — port 81 baked into old SWAG/Rails config
Fix attempted: RAILS_FORCE_SSL=false, HOST/PORT env vars — didn't work
Root cause not fixed needed: Port 81 redirect only occurs on HTTP. When Caddy handles SSL termination and proxies to the app over HTTP, the Rails app responds correctly. No further fix needed.

Obstacle: UNMS nginx owned 80/443 on app2, blocking Caddy for Hudu/Traccar
Decision: Move UNMS off 80/443, install native Caddy as single SSL terminator
Fix: Removed 80:80 and 443:443 from UNMS nginx compose, recreated container with only 81:81 and 8089:8089
Installed: Native Caddy (systemd) owning 80/443
Domains:
- hudu.itpropartner.com → localhost:3000 (HTTPS ✅)
- gps.fleettracker360.com → localhost:8082 (HTTPS ✅)
- unms.forefrontwireless.com → localhost:8089 (HTTPS ✅)
SSL: Let's Encrypt auto-provisioned, no manual cert management
Bonus: UniFi Controller enabled through Caddy — unifi.itpropartner.com → localhost:8443
Status: ✅ Complete — Hudu, Traccar, UNMS, UniFi all serving HTTPS via Caddy

Always check port ownership before deploying web services
SWAG containers can't co-exist with another reverse proxy on 80/443
A single Caddy instance serving multiple domains is cleaner than per-service SWAG
Rails force_ssl + missing reverse proxy headers = mysterious port redirects
Project documentation (this file) was created mid-migration — should've been day 1

Obstacle: Original pg_dump only captured companies table — assets (135), asset_passwords (125), and asset_fields (410) were all zero on app2
Diagnosis: Compared both servers via API. Tables existed but were empty — schema-only dump. Companies matched (21 identical IDs).
Fix: pg_dump --data-only from old server for assets, asset_passwords, asset_fields. Imported to app2. PASSWORD_KEY matched on both servers.
Result: 135 assets across all 21 companies restored. Verified with company-asset counts (IT Pro Partner: 51, Liberty: 28, etc.)
Status: ✅

Obstacle: Asset layout "API" and 17 other custom layouts were missing on app2
Diagnosis: Old server had 18 custom layouts (IDs 1-53). App2 only had built-in defaults (IDs 54-86)
Fix: pg_dump asset_layouts + asset_layout_fields from old server, imported to app2 (no ID conflicts)
Result: All 18 custom layouts restored: API, Network Devices, VoIP, Wireless, People, VPS, Wasabi, Stripe, etc.
Status: ✅

Action: Created hudu-backup.sh — daily pg_dump from app2 Docker to S3 (3 AM ET)
Target: s3://hermes-vps-backups/hudu/backups/ — 30-day retention
Test: 488KB dump verified in S3
Status: ✅ Daily cron active