Migration Roadmap

Current deployment update — 2026-09-16

GitchAlerts is deployed to production, confirmed by the owner and production run 64. Bundle 0.1.6 / app 0.12.4 passed rollout and HTTPS health after the same release passed dev run 63. Migration issues platform#28 and GitchAlerts#1 are complete. See GitchAlerts Migration for evidence limits. Remaining production-edge IaC reconciliation and reusable TLS onboarding are tracked in platform#45. Older dated platform prerequisites below are historical and do not imply the deployed apps need to repeat initial setup.

Existing services continue running while platform capabilities are established, and every application cutover remains independently reversible. Track operational work in its owning repository and prioritize it on the Homelab Roadmap.

Recorded state — 2026-09-02

• RKE2, MetalLB Layer 2, TrueNAS CSI NFS/iSCSI and UDS Core with tenant/admin gateways have been established according to the completed build records.
• The Homelab organization, application/support repository shell, shared board and initial platform configuration are established.
• platform#1, formerly public issue 20, reports the legacy allowlist/passthrough, unknown-host rejection, HTTP redirect, native test routing, and dev DNS with a valid certificate complete. Production ingress cutover remains open.
• OpenBao, ESO, and cert-manager automation are scaffolded, not confirmed deployed. A valid existing dev certificate is distinct from automated issuance/renewal.
• This is a record of source evidence, not a new live health audit.

Immediate platform work

1. Establish recoverable OpenBao placement, durable storage, initial TLS and unseal/recovery procedures that do not depend on the CSI credential stored inside OpenBao.
2. Package and test OpenBao/ESO with pinned versions, narrow Kubernetes auth/policies and harmless test-secret reconciliation; validate backup/restore.
3. Securely populate runtime credentials in OpenBao and test controlled adoption of the TrueNAS CSI secret while preserving working storage.
4. Implement cert-manager Cloudflare DNS-01 automation with an ESO-sourced token; prove staging issuance, trusted issuance, renewal and gateway reload. Reconcile the working dev route before changing ownership.
5. Complete the outstanding ingress checks below and build/test the corresponding UDS deployment artifacts.
6. Establish controlled artifact publishing and deployment workflows, then follow the application-specific migration plan.

Track OpenBao/ESO and certificate automation as separate platform work items with explicit dependencies. Their issue IDs have not yet been recorded here. They are the next chosen platform automation work; the ingress checklist must continue to distinguish them from dev DNS/TLS that already works. Existing working ingress need not be dismantled to introduce automation.

Remaining primary-edge acceptance

The current checklist in platform#1 remains authoritative. Outstanding items at this update are:

• Capture current public NAT/forwarding and LAN DNS settings and an explicit rollback record before changing them.
• Point production HTTP/HTTPS forwarding at tenant VIP 10.0.0.241 and validate externally.
• Ensure LAN production names resolve directly through the chosen LAN resolver/local resolution path rather than depending on router hairpinning.
• Confirm admin VIP 10.0.0.240 remains inaccessible from the public edge.
• Verify every retained production hostname, certificate and application behavior, with logs distinguishing native routing from NPM passthrough.
• Validate rollback to the prior direct-NPM routing to the agreed extent.
• Review the final architecture and per-host handoff procedure in Mat's migration plan, then attach implementation evidence to the issue.

The documentation procedure is provided by this update; it does not certify that cutover or rollback has been executed. Recheck live conditions immediately before any change.

Application migration order

Mat's Homelab Application Migration Plan owns workload placement and sequencing. Actual Budget is the initial migration pattern; this supersedes the older roadmap's TradeGumi-first proposal. The current TradeGumi deployment is slated for retirement and its replacement is a separate development/deployment track.

Every application owns its package, configuration, issue and release evidence. Use development-host validation, preserve production hostnames and existing datasets, coordinate single-writer behavior, and retain the old deployment and backups through the observation period. The shared migration/rollback work captures reusable procedure.

Independent and follow-on work

• Storage/data-protection conventions can progress independently of ingress.
• GPU enablement is required for the relevant GPU workloads, not as a prerequisite for UDS Core or every application.
• ComfyUI local PV planning and Satisfactory local PV planning remain application-owned.
• Secret scanning and Linux runner migration belong in workflows. Linux migration completed on owner acceptance on 2026-09-10; workflows#2 and platform#32 are closed. Global Kubernetes ci/deploy pools now provide four CI slots plus one deployment slot. Retain the Windows runner on Windows Hyper-V. The project cards still need moving from In Progress to Done by a board editor; kiyi could close the issues but could not move the cards.
• Technitium is the selected replacement for Pi-hole in the application plan; validate actual DHCP/client resolver use, filtering and split DNS before declaring that replacement complete.

Delivery and recovery gates

UDS bundles are the target delivery model. Pin/test packages and images, promote the same artifact, and document adoption of currently kubectl-managed resources. Raw manifests remain transitional; the repository's full-platform example is not an enabled installer. Keep external AIStor and PostgreSQL recoverable independently, test OpenBao recovery, and validate data recovery separately from configuration rollback.