This repository documents my personal Linux homelab, built for hands-on practice with Linux administration, Docker, DNS, reverse proxying, monitoring, troubleshooting, and technical documentation.
The environment is centered around a repurposed Lenovo ThinkPad T440p running Ubuntu Server, with Docker-based services used to learn container deployment, local DNS management, reverse proxy routing, service monitoring, and infrastructure documentation.
I built this lab to gain practical, hands-on experience with infrastructure and networking by running real services in a self-hosted environment and troubleshooting problems as they came up.
Rather than treating the lab as just a collection of containers, I use it as a platform for learning:
- Linux server administration
- Docker and Docker Compose
- Local DNS and hostname resolution
- Reverse proxy configuration
- Service monitoring
- File permissions and ownership
- Layered troubleshooting
- Documentation of issues, fixes, and lessons learned
- Host: Lenovo ThinkPad T440p
- OS: Ubuntu Server
- Runtime: Docker and Docker Compose
- Access: SSH from a client workstation
- Documentation: Obsidian and GitHub
- Primary Use Cases: infrastructure learning, containerized services, local DNS, monitoring, reverse proxying, and troubleshooting practice
- Local DNS records managed through Pi-hole
- Reverse proxy routing handled by Nginx Proxy Manager
- Local services accessed through
.homehostnames - Service monitoring handled through Uptime Kuma
- Sensitive network values are replaced with placeholders such as
<server-ip>and<admin-user>
- Portainer — Docker container management interface
- Pi-hole — local DNS and DNS filtering
- Nginx Proxy Manager — reverse proxy routing for internal services
- Uptime Kuma — service monitoring and uptime checks
- Homepage — central dashboard for homelab service access
flowchart TD
Client[Client Workstation] --> Network[Local Network]
Network --> Server[ThinkPad T440p Ubuntu Server]
Server --> Docker[Docker Services]
Docker --> Portainer[Portainer]
Docker --> PiHole[Pi-hole]
Docker --> NPM[Nginx Proxy Manager]
Docker --> Kuma[Uptime Kuma]
Docker --> Homepage[Homepage]
This documentation focuses on:
- how the lab is structured
- why major design decisions were made
- how Docker services are organized
- how DNS and reverse proxy routing work together
- how services are monitored
- problems encountered during setup
- how those problems were diagnosed and fixed
- lessons learned that apply to IT infrastructure work
00 - Dashboard/ Project workflow and documentation standards
01 - Infrastructure/ Current infrastructure overview
02 - Networking/ DNS, reverse proxy, and traffic flow
03 - Docker/ Docker stack and service deployment notes
04 - Monitoring/ Monitoring overview and health checks
05 - Troubleshooting/ Issue-based troubleshooting writeups
06 - Active Directory/ Future Windows/AD lab planning
07 - Diagrams/ Architecture and topology diagrams
08 - Screenshots/ Sanitized supporting screenshots
- DNS and reverse proxying are separate layers
- A running container does not always mean the application is reachable
- Stable service access depends on DNS, proxy routing, and application behavior working together
- Docker port assignments must be tracked carefully
- Linux file ownership matters when managing service configuration files
- Browser cache can make a fixed proxy route appear broken
- Troubleshooting works best when isolating one layer at a time
Planned future additions:
- Homepage dashboard widgets
- additional Uptime Kuma monitoring checks
- backup strategy documentation
- more complete Docker service notes
- Active Directory lab planning
- Linux administration practice notes
- scripting and automation improvements
This is a public repository, so sensitive information is intentionally excluded.
The documentation uses placeholders instead of exposing private details:
<server-ip>
<admin-user>
<service-name>
<api-token>
This repository does not include passwords, API keys, tokens, private keys, real IP addresses, usernames, router credentials, MAC addresses, or screenshots exposing sensitive values.