Applications and migration inventory

Inventory reconciled 2026-09-25; Renovate updated 2026-10-04; base images updated 2026-10-06; Harbor preparation updated 2026-10-13. A production URL or repository does not imply that its Kubernetes migration is complete. Internal owning issues and live service checks govern current status.

Accepted RKE2 application deployments

Acceptance is bounded. Actual's owner confirmed login, existing data, sync and restart persistence, but no fresh external-network or unauthorized-user test was reported in that cutover. GitchAlerts' production run does not establish every webhook/provider, group-revocation, backup/restore or certificate-renewal behavior. Keep these gaps in the owning repositories.

Renovate's enabled schedule and bot activity do not establish every repository or dependency manager, a real lockfile update, deduplicated reruns or tested alert/rotation/rollback behavior. Those details continue in private Homelab/renovate #15; see delivery and operations.

In progress

Image Gitchistry (Harbor) is prepared for initial service deployment, with registry migration and consumer cutover deferred. Private Homelab/the-gitchistry PR #3 merged Harbor 2.15.0, native UDS/GitchAuth OIDC, Valkey, the selected blue-cylinder/flat-cat-ear logo, TrueNAS S3 blobs, shared PostgreSQL and CSI state. Production is selected at registry.app.gitchegumi.com on the tenant gateway; isolated dev remains registry.dev.gitchegumi.com, matching the current platform gateway's recorded *.dev.gitchegumi.com coverage. Live DNS/TLS acceptance remains required.

On 2026-10-13 the owner reconfirmed that Terraform state/KMS, the PostgreSQL provisioner and dev bucket/database/runtime credentials are not set up. Private the-gitchistry PR #5, source 441bf2836c9894684b4b2e69af3f1d33c56fca69, now prepares all four owning callers for the promoted stable-v1 channel, with its initial v1.36.0 snapshot and the same accepted security tool image. Scan/job names, default dev, managed identity, image digests and promotion of one signed dev/prod archive are preserved. Local source checks and 21 regressions passed; generated application manifests are unchanged. Hosted checks for the new source, signed bundle publication and live acceptance remain required. The owner is adopting stable callers as bundles change, rather than performing an unrelated repository-wide migration.

The reusable storage source is merged in private Terraform PR #3; its five stable callers are prepared separately. PostgreSQL PR #9's membership fix and disposable provider test at ea60bc5bab2fd160e7255dd5d7bafe45db9f5272 passed disposable provider CI run 36 on 2026-10-13: two non-superuser applies, unchanged plans, retained creator membership, PUBLIC revokes and password-free state. This is fixture acceptance, not a Homelab database apply. The released engine still permits storage resources only: a reviewed combined PostgreSQL/storage profile and one runtime writer are required before Harbor database provisioning. One private provisioner bootstrap is accepted; repeated manual per-application SQL setup is not the selected delivery path.

A secret-free signed bundle can be built before these runtime prerequisites exist. Deployment waits for backend/KMS, scoped provisioning, managed application onboarding, external services and live DNS/TLS/CSI/ESO readiness. Private the-gitchistry issue #1 and docs/service-deployment.md in that repository's main branch own the operator sequence, acceptance and recovery details. The current caller revision is under review; use that PR's verified source for the proposed changes.

Documentation site: direct browser inspection on 2026-10-17 confirmed that doc.app.gitchegumi.com/docs/architecture/ serves the public architecture record without an SSO redirect. The exact deployed release and external-network path were not audited. Configuration uses a Next.js server on the standard UDS tenant gateway. The server reads reviewed Markdown from this repository's public main branch and discovers new pages without rebuilding the image. The owner confirmed chart release and deployment on 2026-10-17, and browser inspection that day confirmed both SVGs load. Chart links now read the SVG content directly from reviewed main, so later Markdown and diagram edits need only merge and page refresh; application code and layout changes still require release and deployment. On 2026-09-24, scanned-image run 13 published git.gitchegumi.com/homelab/documentation@sha256:a85ab0ab6b6b502e230676c455d217462ddd0b07cf4bf392dca3ecbcfaf525ee with signed evidence. After the digest was pinned, signed bundle release ci-cad9a4195befd865d78322ecff4a227ae2201834-4910 was published. Those historical releases alone do not identify the current deployment. The site deliberately has no SSO. Build and deployment procedure.

ComfyUI is running in production on the media GPU worker. On 2026-09-25, the owner confirmed the application works and loads newly downloaded models; the comfy-ui pod was Running/Ready with the published image. Models are mounted read-only from /mnt/assets/ComfyUI/models, while dev and prod have separate writable state. A production settings-write failure was traced to root-owned user directories on the state volume and resolved by restoring UID/GID 1000 ownership. Its host is comfyui.app.gitchegumi.com on the standard UDS tenant gateway. Full GPU workflow coverage, SSO negative cases, off-node backup/restore, and automatic candidate/email acceptance remain open in private Homelab/Comfy-UI issue #1. One physical GPU means dev and prod run sequentially; the prior terminal installation remains a rollback source until migration acceptance.

Base images are a separate private Homelab/base-images track. Published, signed PyTorch/CUDA and comfy-python images are pinned by digest in the running ComfyUI image; its production startup and model loading confirm this integration. On 2026-10-06, the owner accepted the published Ubuntu 26.04 LTS amd64 foundation, base-ubuntu-v2026.10.06-r6354, after its source and full-image scans passed and fresh ClamAV scanning was clean. General Python and Node images can now build on that accepted digest; their publication remains pending in base-images #3 and #4. The runner tool definitions were consolidated to tools/main-runner after their tool requirements proved identical. On 2026-10-07 it was published as tool-main-runner-v2026.10.07-r6415 in the separate homelab/tool-images/main-runner OCI namespace, with passing source/full-image gates and clean fresh ClamAV evidence. Source stays in Homelab/base-images. The existing ci and deploy labels and security pools remain separate; hosted compatibility acceptance and runner-label adoption remain pending. See delivery and operations for the publication evidence and adoption boundary.

ReadMeABook remains on TrueNAS, with configuration/path validation reported on 2026-09-21. End-to-end acquisition, restart persistence and restore have not been separately accepted. It shares the retained audiobook library with Audiobookshelf. Platform issue #26 records the owner decision.

Selected placement for remaining workloads

This is a planning inventory, not the 29-host deployed NPM allowlist. Existing production hostnames are retained during migration; some services may still be served by TrueNAS/NPM. Reconcile live DNS, NPM and Istio before any cutover.

MinIO/AIStor, shared PostgreSQL, NocoDB, qBittorrent/Gluetun, Sonarr, Radarr, Prowlarr, FlareSolverr, ReadMeABook and shared media remain on TrueNAS under the migration plan. Authentik is to be replaced by UDS Keycloak, and NPM by Istio only after their actual consumers have migrated. Owner decision, 2026-09-16, reconfirmed 2026-10-18: Pi-hole is retained for LAN split DNS and ad blocking; no Technitium migration is planned. This supersedes the older migration plan's DNS selection. Preserve existing resolution, filtering and the actual DHCP/client DNS path. See the DNS boundary; private platform #25 records the owner cancellation and is closed. The current TradeGumi deployment and several obsolete apps are retirement targets; no deletion is implied by that plan.

Per-application handoff

Use a dev hostname when appropriate while the original production route remains intact. Before the production handoff, record data backup, authentication, route/certificate, writer ownership and rollback. Platform removes a hostname from every legacy Gateway/VirtualService/validation list in the same reviewed change that the app activates its native route. Verify trusted TLS, redirects, application behavior and other legacy hosts, then keep the old route and deployment through an observation period. A routing rollback does not reverse data writes. Detailed handoff procedure is historical reference; future instance updates belong here and in the owning runbooks.