# Homelab: Linux Infrastructure and Self-Hosting Public project summary | September 2026 ## About this document This is a new, privacy-edited summary of the visible homelab project discussions, not a line-by-line redaction of the original private master-context file. That earlier Markdown file was not available for this edition. The notes describe documented work and explored ideas; they are not a live inventory, security assessment, or claim that every discussed service is deployed. Personal identifiers, contact information, addresses, hostnames, network identifiers, credentials, device identifiers, and exact deployment paths are excluded. This document is intentionally independent of the portfolio owner's identity. ## Project overview The project centers on restoring and extending an Ubuntu Server homelab on a Lenovo ThinkStation P520. Discussion topics include Linux administration, local storage, containerized applications, GPU-assisted media workloads, private remote access, identity management, and operational documentation. The practical focus is troubleshooting across layers: physical storage, filesystems, host services, container configuration, application behavior, and client access. Private repository records and current server reports remain the appropriate sources for exact configuration and operating state. ## Storage and Linux operations The project discussions show three ext4 data volumes and a mergerfs storage pool. Storage work included checking mount state, discussing redistribution of files among underlying disks, and planning a one-time maintenance job with an additional check for active use. A discussion about scheduling maintenance is not evidence that the job later completed. Related restoration and troubleshooting topics include service status, boot-related service behavior, filesystem visibility, permissions, and preserving a usable operational record. Exact device paths, filesystem identifiers, capacity figures, and mount paths are intentionally not reproduced. ## Containerized application workflows Docker is used in the homelab discussions to inspect and manage application services. The visible material includes media applications, file access, a service homepage, an identity provider, and a reverse proxy. A recurring troubleshooting topic is consistency between the paths an application expects and the directories available inside its container. The project includes investigation of application import errors, service connectivity, and the distinction between a host-side path and a container-visible path. This public document omits media filenames, account information, download-source details, and private service URLs. ## GPU and media infrastructure The project includes NVIDIA-related container and media-transcoding troubleshooting, including Jellyfin workflows. GPU assignment and NVIDIA Container Toolkit configuration appear among the restoration documentation topics. These notes do not establish a verified current driver version, exact GPU inventory, throughput, or number of concurrent streams. Client playback and streaming alternatives were also explored. Options considered in a discussion are not presented here as hardware purchases or completed deployments. ## Identity and application access The visible project discussion confirms a successful authentication flow for the service homepage through Authentik. Nginx Proxy Manager appears in the associated service-connectivity testing. Authentication scope was considered per application rather than assumed to apply uniformly. Private application endpoints, account details, and application-specific access exceptions are omitted from this public edition. The documentation is a case study, not an access map to the running environment. ## Networking and remote administration The project describes UniFi networking and a move from an earlier remote-access approach to UniFi-based VPN access, including WireGuard and Teleport clients. It also includes a reported working device access schedule and discussion of the effect of private device addresses on access policies. Further ideas included time-limited guest credentials and a home-server-backed authentication flow. These were exploratory topics; a completed guest authentication service is not established by the available discussion. No public or private network addresses, interface identifiers, wireless network names, VPN profiles, forwarding rules, or management endpoints are included. ## Operational approach The discussions emphasize observing actual command output, reviewing logs and container configuration, checking mounts and application paths, and distinguishing planned work from completed changes. Requests for a canonical context document also identify the server repository and reports as the preferred authority when recollections conflict. Public case notes retain the engineering topics while leaving exact commands, sensitive outputs, secrets, and operational recovery artifacts in private records. This summary does not claim measured uptime, a verified backup recovery point, or completed restore testing. ## Ideas still being evaluated Topics explored but not established as deployed in the visible material include an externally hosted monitoring dashboard with local data collection, expanded document and receipt storage, additional photo storage, cloud-hosted supporting services, and dedicated game-streaming hardware. Storage expansion and cloud capacity were discussed as constraints. Automated update tooling and local-model work also appear as draft or approval-bound topics in the requested restoration record. They are not treated as completed deployments here. ## Publication boundary This public edition intentionally excludes personal and household details; email addresses and telephone numbers; all literal network addresses; private hostnames and domains; account names; wireless identifiers; hardware serials and unique device identifiers; credentials and keys; exact filesystem paths; service administration links; and raw logs or configuration files. The portfolio website and public resume identify the professional owner separately. This Markdown document does not. Replacing this summary with the original master-context file requires a fresh review of the full file, its code blocks, hyperlinks, and embedded configuration before publication.