Homelab status,
in the open.

Summary

The workstation photo service now starts through a supervised Windows task after its owner signs in. The previous launcher remains available for rollback, and the change does not affect household Internet or Wi-Fi.

Validation

• Installed a stable, access-restricted copy of the reviewed launcher.
• Registered a passwordless task for the same account that owns the Linux subsystem.
• Prevented duplicate launchers while retaining the previous shortcut for rollback.
• Terminated the subsystem once and restored all healthy photo-service containers.
• Confirmed local and mobile endpoints, graphics visibility, and one active supervisor.

Next actions

• Add an independent backup target and complete a media-plus-database restore test.
• Keep pre-sign-in recovery pending unless a suitable account-credential design is selected.

Summary

The private photo application now has a working mobile endpoint through a dedicated, failure-isolated ingress service. The existing static gallery remains online and unchanged, and ordinary household connectivity does not depend on either photo component.

Validation

• Started the complete application stack and confirmed every service is healthy.
• Validated local browser access and graphics acceleration for photo analysis.
• Completed the application's protected first-run administrator setup.
• Proved that the saved startup path restores the service after a Linux subsystem restart.
• Allowed only the dedicated ingress service to reach the workstation origin.
• Validated cellular sign-in and representative uploads through the mobile app.
• Confirmed the edge service's documented large-upload limit for videos.
• Returned a clear offline response while the workstation slept and recovered after resume.
• Stopped the ingress service and proved that only the mobile photo endpoint failed.
• Restored the endpoint automatically without affecting the static gallery or other services.
• Corrected the photo-analysis service path and validated fast GPU-backed semantic search, face recognition, and text extraction.

Next actions

• Add an independent backup target and complete a media-plus-database restore test.
• Move workstation startup from sign-in-only launch to a tested boot-time task.
• Select a direct private transport for videos above the edge upload limit if needed.

Summary

The remote-access design for the future photo service now uses a dedicated, owner-only VPN path. Application HTTPS and Google login stay with the photo service itself, while the current static gallery remains unchanged.

Design decisions

• Reserved a small isolated guest to terminate the private VPN.
• Defined one independently revocable VPN identity per owner-controlled device.
• Limited the initial private route to the photo service and required name resolution.
• Kept HTTPS, Google authentication, application state, and media on the photo VM.
• Avoided publishing the photo application's HTTPS service directly to the Internet.

Next actions

• Create the VPN guest and validate both permitted and denied destinations.
• Deploy the empty photo application and prove backup and restore behavior.
• Validate Google login and large-file transfer from the mobile app.

Summary

A dedicated, isolated guest baseline now exists for the future photo service. Its full-VM baseline is running while capacity, backups, and recovery are designed, and the current static gallery remains the safe rollback service.

Validation

• Reserved a separate identifier for the future management VPN.
• Created a full virtual machine for the photo service with no application or personal media.
• Validated fixed networking, filesystem expansion, and guest-agent recovery.
• Followed the upstream full-VM recommendation and recorded storage constraints.
• Enabled automatic recovery for the family egress VM after a host reboot.

Next actions

• Install the container runtime and validate the application baseline.
• Design persistent media storage and independent backups.
• Prove restore behavior before importing irreplaceable photos.

Summary

Uptime Kuma now has separately scoped protected remote access, and the Homepage dashboard links to it cleanly. The dedicated family egress VM also now has a restricted proxy path validated from an external cellular client, plus gateway-managed dynamic DNS and recovery snapshots. Real China-network and split-routing tests remain pending.

Validation

• Confirmed authenticated browser access to the private monitoring UI.
• Confirmed unauthenticated requests are redirected to the Access policy.
• Validated authenticated family proxy egress and denied private-network access.
• Confirmed the public endpoint from cellular without relying on home Wi-Fi.
• Kept the monitoring origin available directly on the trusted LAN.
• Kept Tunnel credentials and monitoring credentials outside Git.
• Created validated checkpoints for the management, dashboard, and monitoring guests while retaining scheduled backup and restore testing as separate recovery work.
• Built the isolated VM for the parents' restricted Internet-egress service, keeping its credentials private and its access boundary independent from ordinary household connectivity.
• Installed and checksum-verified Debian, established key-only administration and console recovery, validated the default-deny guest firewall, and then confirmed the finished proxy path from an external cellular client.

Next actions

• Configure and test an actionable monitoring notification channel.
• Back up monitoring state and complete an isolated restore test.
• Add an external heartbeat for complete host or monitoring-guest outages.

Summary

The management LXC now has a UniFi-enforced fixed address, a local baseline snapshot, and a versioned Debian 13 bootstrap path. These changes make the administrative environment easier to rebuild without adding it to the household network's critical path.

Management baseline

• Fixed the unprivileged management LXC at 192.168.10.100 through UniFi address management.
• Address plan superseded: the Proxmox host was finalized at 192.168.10.10, replacing the earlier planned 192.168.10.30 reservation recorded in the historical report.
• Saved a known-good Proxmox snapshot after the initial management tooling, repository, shell, and SSH-access bootstrap.
• Retained local console and USB Ethernet as the required host recovery path; the management LXC remains dependent on the Proxmox host and its network.

Reproducible tooling

• Consolidated recovery and container-provisioning tools under a dedicated bootstrap/ directory, including an idempotent Debian 13 management-node bootstrap for CLI, Node.js, Codex, Git, and shell setup.
• Added a dry-run-first application-container workflow with sequential IDs, explicit resource overrides, fixed-address preflight, and unprivileged Debian defaults.
• Added versioned LXC profiles for a non-critical small-apps container and a separately scoped monitoring container, with explicit Docker feature handling.
• Kept SSH keys, Git authentication, private inventory, deployment credentials, networking, and firewall policy outside the automated bootstrap.
• Documented the distinction between a quick local snapshot rollback and a scheduled backup with an isolated restore test.

Small-apps foundation

• Created the unprivileged apps LXC from the reviewed, versioned profile for Homepage and similar small Docker utilities.
• Validated its CPU, memory, thin-provisioned storage, Docker-oriented LXC features, and fixed-address configuration, then brought the guest online.
• Confirmed IPv4, gateway, DNS, and Internet access without changing household routing; dual-stack validation still has an IPv6 routing follow-up.
• Installed Docker Engine, Compose, and Buildx from the official Debian repository; validated container execution and daemon restart, and added bounded log rotation to protect the guest disk. No application has been deployed at that point.
• Deployed a pinned Homepage release as the first small application. It is limited to the trusted LAN, runs without a Docker-socket mount or embedded credentials, and remains separate from household routing, Wi-Fi, and DNS.
• Added an outbound-only Cloudflare Tunnel and a dedicated Access policy for authenticated remote Homepage access, without publishing the household WAN address, opening an inbound port, or requiring DDNS. The LAN fallback remains available.
• Verified both permitted and denied Access paths without publishing identity details, and confirmed the Tunnel reconnects while the direct LAN fallback remains healthy.

Monitoring plan

• Planned a separate unprivileged monitoring LXC for Uptime Kuma, Prometheus, and Grafana so it can observe failures of the small-apps container.
• Defined a conservative initial resource envelope, short metrics retention, persistent application data, backup requirements, and LAN-only access.
• Recorded the remaining shared failure mode: a future external heartbeat is needed if monitoring must report a complete monitoring-guest or host outage.
• Created the separate monitoring guest with the reviewed resource and isolation profile, leaving it stopped until its fixed address is confirmed in UniFi. No monitoring application has been installed yet.
• Confirmed the fixed address, started the monitoring guest, and validated IPv4, gateway, DNS, Internet access, time synchronization, and boot policy.
• Installed and validated Docker with bounded local logs, then deployed a pinned Uptime Kuma release with persistent local data and LAN-only access. Completed private first-run setup and five initial network, infrastructure, application, and public-portal checks. Prometheus, Grafana, notifications, backup, and restore testing are still planned.
• Added the private monitoring service to the Homepage dashboard as a credential-free LAN link, without exposing container-control access.

Next actions

• Back up the working Proxmox network, DKMS, repository, and boot configuration.
• Configure scheduled backup and validate an isolated management-LXC restore.
• Complete the remaining UniFi and TELUS reachability inventory.
• Establish the separate Michael-only WireGuard management path.

Summary

The Beelink SER8 arrived and became the first operational Proxmox host. A no-link condition on the integrated 2.5GbE adapter was isolated and repaired without placing the household network in the failure path.

Host deployment

• Installed Proxmox VE 9.2.4 directly on the SER8.
• Activated host pve at 192.168.10.10.
• Moved vmbr0 onto the integrated Realtek RTL8125 interface and verified a 2500Mb/s Full Duplex link.
• Confirmed the host remains reachable after reboot while ordinary household routing continues to stay independent of Proxmox.

RTL8125 recovery

• Used a temporary USB Ethernet adapter as a fallback management path while diagnosing the integrated adapter.
• Determined that the default r8169 driver enumerated the adapter but did not establish physical link on this host.
• Installed and validated the pinned r8125 DKMS driver, then confirmed driver binding, bridge membership, gateway reachability, and reboot persistence.
• Added a sanitized debug runbook with recovery, kernel-upgrade validation, fallback-access, and rollback procedures; private device identifiers remain outside Git.
• Recorded the third-party RTL8125 DKMS module as the host's highest current operational risk: a failed kernel/module transition can disconnect Proxmox and every guest, including the management LXC.
• Required a known-good fallback kernel, local console or tested USB Ethernet, and explicit DKMS preflight before every kernel reboot.

Publishing boundary

The source repository is private and is intended to remain private. Cloudflare Pages publishes only each site's explicitly configured static output directory; infrastructure source, private configuration, and inventory are not part of the public deployment. Live Secrets remain outside Git.

Project operating contract

• Added a concise project startup document covering Zero Trust, Everything as Code, Docker-first deployment, and the preference for LXC over VM where isolation and workload requirements permit it.
• Recorded WireGuard as the remote LAN management path and reserved VLESS for the parents' Shadowrocket clients.
• Required explicit owner confirmation before firewall changes or new public service exposure, plus an impact and rollback explanation before destructive work.
• Updated the Codex startup order so each session begins with the project contract before loading detailed operating and architecture context.
• Deployed an unprivileged management LXC, cloned the private infrastructure repository, and securely imported its local Git-ignored inventory.

Next actions

• Back up the working Proxmox network, DKMS, repository, and boot configuration.
• Configure and validate scheduled backup and restore for the management LXC.
• Confirm the management LXC DHCP reservation.
• Complete the remaining UniFi and TELUS reachability inventory.

Summary

The project moved from pre-design into its first working public services. The Canada-side VPN architecture was clarified, the public domain was activated, and two static sites were deployed through a Git-driven Cloudflare Pages workflow.

Architecture and planning

• Produced a phased Proxmox and Canada–China connectivity design.
• Defined phase one as individual China devices connecting to a Canada-hosted tunnel endpoint for Canadian Internet egress.
• Deferred site-to-site routing until a Ubiquiti gateway can be installed locally in China during a future visit.
• Preserved a core reliability rule: homelab failures must not interrupt either household's ordinary local Internet.

Documentation and operations

• Added AGENTS.md as the operating context for future Codex and automation sessions running from the Proxmox management VM.
• Added docs/recommendations.md to consolidate the prioritized implementation backlog, reliability guidance, and follow-up decisions.
• Added docs/runbooks/google-cloudflare-access.md with sanitized Google OAuth and Cloudflare Access setup, validation, rotation, and recovery procedures.
• Kept credentials, personal account lists, Client IDs designated private, Client Secrets, and recovery material outside version control.
• Established the Wiki as a daily project changelog: multiple pushes on the same Vancouver calendar day update one consolidated Daily Status Report.
• Prepared a SER8 installation runbook covering factory Windows preservation, hardware validation, the Proxmox pre-wipe gate, and management VM bootstrap.
• Selected a clean-reinstall Windows recovery strategy: validate the hardware and preserve activation, driver, and system inventory before the Proxmox wipe, without retaining a full factory disk image.

Canada LAN address plan

The SER8 reservation is planned but will not become active until the hardware arrives. The gateway address, DHCP range, and VLAN inventory still need to be recorded before the Proxmox host is commissioned.

Public web foundation

• Registered and activated mzliu.ca with Cloudflare.
• Built a dependency-free static portal with a locally stored hero image.
• Deployed the portal from GitHub using Cloudflare Pages.
• Connected the apex domain to the production Pages deployment.
• Verified that GitHub pushes trigger automatic production deployments.

Pictures service

• Published a dedicated gallery at pics.mzliu.ca.
• Added a responsive grid with 16 pictures per page.
• Added a full-screen viewer with previous/next and keyboard navigation.
• Protected the gallery with Cloudflare Access and Google authentication.
• Restricted authorization to explicitly approved accounts.
• Planned the next stage: migrate pics.mzliu.ca to Immich hosted on the SER8 after storage, backups, authentication, and rollback are ready.

Remote connectivity roles

• The parents' devices will use Shadowrocket with a local ruleset: Chinese destinations go DIRECT through China Unicom, while non-Chinese destinations go through PROXY to a Canada-hosted VLESS server.
• VLESS will run in a dedicated Proxmox-managed VM and provide Canadian Internet egress without access to the Canada LAN or administration services.
• WireGuard is a separate Michael-only management path into the Canada LAN. The parents' devices will not receive WireGuard access.

Service namespace

Security posture

The public portal remains independent of the future SER8, while private or administrative services will receive individual access controls. Credentials, recovery material, public WAN addresses, and detailed private topology are excluded from this public wiki. The basic RFC 1918 LAN plan above is intentionally published as project documentation.