2.4 KiB
2.4 KiB
KiteStacks Homelab Documentation v1.3.922
Version: 1.3.922 Updated: 2026-06-09 Previous: v1.3.921 docs
Change Summary
Cloud Migration Backup Pushed to Forgejo
- Created Forgejo repo
kenpat/kitestacks-cloud-migration, set to private (contains.envfiles, tunnel tokens, app credentials). - Pushed the full migration backup from
/home/kenpat/kitestacks-cloud(commit6ffcbea, ~4.3GB total). - Large files (archives + Docker volume exports, ~2.3GB across 14 files) tracked via Git LFS, since these were too big for normal git objects.
- Verified all 15 LFS objects are present server-side and match the OIDs/sizes recorded in
SHA256SUMS.
Repo Contents (kitestacks-cloud-migration)
archives/docker-bind-data.tar.gz—/home/kenpat/dockerbind-mounted service folders (compose files,.envfiles, app data)archives/syncthing-shared.tar.gz—/home/kenpat/SyncthingSharedarchives/kitestacks-scripts.tar.gz— local automation/script foldersarchives/host-etc-subset.tar.gz— selected host/etcconfigvolume-exports/*.tar.gz— Docker named volume exports (kite-ai/open-webui, openproject db/pgdata/assets/logs, portainer, uptime-kuma, etc.)inventory/*— Docker, network, disk, config, and host inventory snapshotsrestore/RESTORE.md— first-pass restore procedureSHA256SUMS— checksums for all files in the backup
Known Issue: Cloudflare Tunnel LFS Upload Limit
- Forgejo's public hostname
gitforge.kitestacks.com(via Cloudflare Tunnel) returns HTTP 413 for LFS uploads/downloads over ~100MB. - Workaround used for upload: PUT large LFS objects directly to
http://100.90.13.55:3006/...(local Tailscale IP), bypassing Cloudflare. - Same limit will likely apply to
git lfs pullfor the 3 large objects (docker-bind-data.tar.gz ~967MB, kite-ai_open-webui.tar.gz ~963MB, syncthing-shared.tar.gz ~165MB) when accessed via the public hostname — pull via the local IP/Tailscale instead.
Migration Plan (Tracked Going Forward)
- Phase 1 (current): Full server backup archived in
kenpat/kitestacks-cloud-migrationon Forgejo. Goal — be able to pull this repo onto a new desktop and physically relaunch the homelab from it. - Phase 2 (planned): Stand up an Oracle Cloud VPS and load the server stack into the cloud, so services stay up even when the desktop is asleep/off.