· 9 min read
Setting Up a Homelab with CasaOS
Building a personal homelab with Docker, CasaOS and useful self-hosted services.
Setting Up a Homelab with CasaOS
Turning an Old Laptop into My Own Home Server
I've always been interested in understanding how infrastructure works beyond simply using cloud services. Instead of relying entirely on hosted platforms, I wanted to build something at home where I could experiment with Linux, Docker, networking, DNS, reverse proxies, cloud services, and self-hosted applications.
That led me to build my own homelab using an old HP ProBook 650 G1.
The goal wasn't to build an expensive enterprise server. I wanted something practical, low-cost, and flexible enough to run different services while giving me a real environment to learn and experiment.
The result became my personal CasaOS-based homelab.
Why Build a Homelab?
A homelab is more than just a server sitting somewhere in your house. For me, it is a place to experiment without worrying about breaking a production environment.
It provides an environment where I can work with:
- Linux administration
- Docker and Docker Compose
- Reverse proxies
- DNS and network services
- Cloudflare
- Self-hosted applications
- Web servers
- Monitoring
- Automation
- Networking and security
- Git and development tools
As someone working in IT infrastructure, having a personal environment where I can test these technologies is extremely useful.
Instead of reading about something like Docker networking or reverse proxies, I can actually deploy it, break it, troubleshoot it, and rebuild it.
The Hardware
For the server, I decided to reuse an old laptop rather than purchase dedicated server hardware.
Homelab Server
| Component | Specification |
|---|---|
| Device | HP ProBook 650 G1 |
| OS | Debian GNU/Linux 13 (Trixie) |
| Kernel | 6.12.100+deb13-amd64 |
| Platform | x86_64 |
| Management | CasaOS |
| Containers | Docker |
| Container Management | Docker Compose |
Using an old laptop has a few advantages.
It is relatively power efficient compared with a traditional desktop server, already has a built-in UPS-like battery, and includes networking hardware, storage, and a display.
Most importantly, I already had the hardware.
So rather than leaving it unused, I turned it into a server.
Installing Debian
The first step was installing Debian GNU/Linux 13 (Trixie) as the base operating system.
I wanted a clean and lightweight Linux environment instead of installing a desktop operating system.
The idea was to keep the underlying system simple:
Hardware
│
▼
Debian Linux
│
├── Docker
│
└── CasaOS
│
├── Applications
├── Containers
└── Storage
This separation makes it much easier to manage applications independently.
If I need to remove or rebuild an application, I don't have to rebuild the entire server.
Installing CasaOS
After getting Debian running, I installed CasaOS as the management layer.
CasaOS provides a simple web interface for managing applications, storage, and Docker containers.
This was particularly useful because I didn't want every task to require manually working with Docker commands.
Instead of constantly using:
docker ps
docker start
docker stop
docker compose up -d
I could manage many applications through a graphical interface while still having full access to Docker underneath.
Why CasaOS?
The main reason I chose CasaOS was simplicity.
A homelab can quickly become complicated. You start with one container, then add another, then a reverse proxy, DNS server, monitoring system, database, and suddenly you're managing dozens of services.
CasaOS gives the environment a clean dashboard and makes the infrastructure easier to understand.
Docker: The Foundation of the Homelab
Once CasaOS was running, Docker became the main platform for deploying applications.
The architecture became roughly:
Internet
│
▼
Cloudflare
│
▼
Home Router
│
▼
Homelab Server
│
Debian Linux
│
Docker
│
┌───────────┼───────────┐
│ │ │
▼ ▼ ▼
AdGuard Home Nginx Proxy Other
Manager Services
Using containers means applications are isolated from each other.
For example, if I want to test a new application, I can create a container rather than installing everything directly into Debian.
AdGuard Home
One of the first useful services I deployed was AdGuard Home.
The idea was to turn the homelab into a local DNS service for my network.
AdGuard Home provides:
- DNS filtering
- Ad and tracker blocking
- DNS query monitoring
- Local DNS configuration
- Network-wide filtering
Instead of installing an ad blocker individually on every device, DNS filtering can operate at the network level.
This also gave me another opportunity to learn more about how DNS actually works in a real network.
Nginx Proxy Manager
Another important component of the homelab is Nginx Proxy Manager.
When you start hosting multiple web applications, you don't want to expose every application directly to the Internet.
Instead, a reverse proxy can act as the entry point.
For example:
app1.example.com ──┐
│
app2.example.com ──┼──► Nginx Proxy Manager
│
app3.example.com ──┘
│
▼
Docker Services
The reverse proxy receives the request and forwards it to the appropriate internal container.
This makes it possible to host multiple applications while using clean domain names.
Cloudflare DDNS
One of the challenges of running a server from home is that the public IP address can change.
My ISP connection doesn't necessarily provide a permanent static public IP.
That creates a problem:
Public IP changes
│
▼
DNS still points to old IP
│
▼
Service becomes unreachable
To solve this, I worked on a Cloudflare DDNS updater running as a Docker container.
The basic concept is:
Home Network
│
▼
Current Public IP
│
▼
DDNS Container
│
▼
Cloudflare DNS
│
▼
Domain → Current IP
The container periodically checks the public IP and updates the Cloudflare DNS record when necessary.
This means I can use a domain name without manually updating DNS every time my public IP changes.
Environment Variables and Configuration
For containers such as the Cloudflare DDNS service, I also started using environment files rather than hardcoding configuration directly into Docker Compose files.
For example:
.env
can contain configuration such as:
CLOUDFLARE_API_TOKEN=...
ZONE_ID=...
DOMAIN=...
And Docker Compose can consume those values.
This makes deployments cleaner and reduces the chance of accidentally committing sensitive information into Git.
It also makes the container easier to move between systems.
Docker Compose
For more advanced services, I started using Docker Compose rather than relying entirely on the CasaOS interface.
A typical Compose structure looks like:
services:
application:
image: example/application:latest
container_name: application
restart: unless-stopped
ports:
- "8080:8080"
volumes:
- ./data:/data
environment:
- TZ=Asia/Colombo
The major advantage is reproducibility.
Instead of remembering how an application was configured, the configuration can be stored in a file.
If something goes wrong, I can recreate the service.
Managing the Homelab Through Git
As the number of configurations increased, version control became increasingly important.
Instead of treating the server as a collection of random configuration files, I started keeping configuration and scripts organized into repositories.
This is particularly useful for:
- Docker Compose files
- Dockerfiles
- PowerShell scripts
- Bash scripts
- Configuration templates
- Documentation
- Deployment instructions
I also experimented with running Gitea as a self-hosted Git platform.
The idea was to make the homelab itself capable of hosting the tools needed to manage the homelab.
That's one of the things I find most interesting about self-hosting.
You can eventually build an entire ecosystem:
Homelab
│
┌─────────┼─────────┐
│ │ │
▼ ▼ ▼
DNS Git Proxy
│ │ │
▼ ▼ ▼
AdGuard Gitea Nginx
Networking
The networking side of the project has probably been one of the most interesting parts.
My home network uses a ZLT P11X router as the primary network device, with a Huawei B310s-925 repurposed as a Wi-Fi extender.
The homelab sits inside this network and provides services to other devices.
The challenge is connecting internal services with external access while keeping the network organized.
This required working with concepts such as:
- Private IP addresses
- Port forwarding
- DNS
- NAT
- Reverse proxies
- Firewall rules
- Public IP addresses
- Dynamic DNS
- TLS/HTTPS
These are concepts that are much easier to understand once you've actually configured them.
HTTPS and Domain-Based Access
One of the goals was to avoid accessing applications through addresses like:
http://192.168.x.x:8080
Instead, the goal is to use proper domain-based access:
https://service.example.com
The reverse proxy can terminate HTTPS and forward the request internally.
This creates a much more realistic environment similar to what is commonly found in enterprise infrastructure.
The Homelab Is Also a Learning Platform
The biggest benefit of the project isn't any single application.
It's the experience gained from building and troubleshooting the environment.
For example, when something doesn't work, I have to investigate:
DNS?
│
├── Correct?
│
▼
Network?
│
├── Reachable?
│
▼
Firewall?
│
├── Port allowed?
│
▼
Docker?
│
├── Container running?
│
▼
Reverse Proxy?
│
├── Correct upstream?
│
▼
Application?
This kind of troubleshooting process is very similar to what happens in professional IT infrastructure environments.
Things That Didn't Work Perfectly
A homelab isn't complete without things breaking.
I've had services that stopped running, containers that needed rebuilding, reverse proxy configurations that didn't behave as expected, and services that required additional troubleshooting.
For example, Nginx Proxy Manager was not always running as expected, while other containers such as AdGuard Home were operating normally.
Rather than seeing these problems as failures, they became part of the learning process.
That's one of the biggest advantages of a personal lab.
You can break things.
Then fix them.
Then break them again.
What I Learned
Building this environment helped me understand several technologies much more practically.
Linux Administration
Working directly with Debian improved my understanding of:
- Services
- Processes
- Permissions
- Filesystems
- Networking
- System logs
- Package management
Docker
I gained practical experience with:
- Images
- Containers
- Volumes
- Networks
- Environment variables
- Docker Compose
- Container troubleshooting
Networking
The project provided hands-on experience with:
- DNS
- NAT
- Port forwarding
- Private/public addressing
- Reverse proxies
- DDNS
- HTTPS
Cloudflare
I also gained practical experience integrating a home infrastructure environment with Cloudflare DNS and automation.
Infrastructure Thinking
Most importantly, the project encouraged me to think about infrastructure as a system rather than individual components.
A service isn't just an application.
It depends on:
Hardware
↓
Operating System
↓
Network
↓
DNS
↓
Docker
↓
Reverse Proxy
↓
Application
↓
Data
When something fails, understanding those dependencies makes troubleshooting much easier.
What's Next?
The homelab is still a work in progress.
There are several things I want to explore further:
- Better monitoring and alerting
- Centralized logging
- Automated backups
- More self-hosted applications
- Improved network segmentation
- Better Docker management
- Automated deployments
- Git-based infrastructure management
- Secure remote access
- Additional Cloudflare integrations
- Infrastructure documentation
I also want to experiment more with virtualization and eventually build a more structured environment that resembles a small enterprise infrastructure platform.
Final Thoughts
What started as an old HP ProBook 650 G1 became much more than a spare computer.
It became my personal infrastructure playground.
With Debian, CasaOS, Docker, AdGuard Home, Cloudflare, Nginx Proxy Manager, Git, and various self-hosted services, I now have an environment where I can experiment with technologies that are directly relevant to modern infrastructure and cloud administration.
The biggest lesson I've learned is simple:
You don't need expensive enterprise hardware to start learning infrastructure.
An old computer, a Linux distribution, some networking knowledge, and a willingness to troubleshoot can be enough to build a surprisingly capable homelab.
And the best part?
When something breaks, you get to learn how to fix it.