Finally Happy With My All-In-One Homelab 20 Services Local Ai And Way Too Much Tinkering

Finally Happy With My All‑In‑One Homelab 20 Services Local AI And Way Too Much Tinkering

Introduction

For years I chased the illusion of a perfectly isolated, self‑hosted environment that could replace every SaaS dependency. The journey was littered with broken containers, misconfigured networks, and endless “what‑if” scenarios. After countless iterations, I finally reached a point where my single‑server homelab runs twenty distinct services, hosts local AI workloads, and still feels stable enough to be shared with the community.

This post is a comprehensive, SEO‑optimized guide for experienced sysadmins and DevOps engineers who want to replicate a self‑hosted, all‑in‑one infrastructure that eliminates reliance on public clouds. You will learn:

• The rationale behind consolidating diverse workloads onto a single Ryzen‑based node.
• How to design a resilient architecture that separates concerns while sharing resources.
• Step‑by‑step installation and configuration of each service, with a focus on repeatability and maintainability.
• Security hardening, performance tuning, and monitoring strategies that keep the lab production‑ready.
• Practical troubleshooting techniques for common pitfalls in a high‑density homelab.

By the end of this guide, you should be able to spin up a similar setup, understand the trade‑offs, and adapt the approach to your own environment.

---

Understanding the Topic

What is a “single‑server do‑everything box”?

A single‑server homelab is a physical or virtual machine that hosts multiple independent services behind a unified networking layer. Instead of provisioning separate VMs or cloud instances for each function — such as password management, photo storage, code repositories, chat, and AI inference — you consolidate them onto one hardware platform.

Key characteristics:

Aspect	Description
Hardware	Ryzen 7 3800X, 48 GB RAM, 4 TB SSD array, dual‑port NICs for LAN and management.
Virtualization	Docker Engine with Compose for container orchestration; optional K3s for lightweight Kubernetes workloads.
Service Count	20 distinct containers, each exposing a specific port and functionality.
AI Integration	Local LLM inference via Ollama, text‑generation-webui, and vLLM, all accessible through a unified reverse proxy.
Networking	Separate VLANs for production, management, and IoT traffic, enforced via firewall rules.

History and Development

The concept of a homelab dates back to the early 2010s when hobbyists began repurposing old servers for VM labs. With the rise of Docker and Kubernetes, the focus shifted toward container‑native deployments. Over the past five years, the community has refined best practices for:

• Service isolation using user namespaces and seccomp profiles.
• Network segmentation with macvlan or ipvlan drivers.
• Persistent storage via NFS, SMB, or local ZFS datasets.

My implementation builds on these foundations, adding a local AI layer that leverages open‑source models without external API calls.

Key Features and Capabilities

1. Unified Reverse Proxy – Traefik handles TLS termination, path‑based routing, and automatic certificate management via Let’s Encrypt.
2. Service Mesh – Small‑scale service discovery using Docker networks and Consul for health checks.
3. AI Inference Stack – Ollama models served through a Web UI, accessible on port $PORT_AI.
4. Credential Vault – Bitwarden instance with encrypted backups stored on an external HDD.
5. Media Library – PhotoPrism and Nextcloud for personal media, both behind separate subdomains.
6. CI/CD Pipeline – Drone CI runs inside a container, triggering builds on push events.
7. Network Monitoring – Prometheus + Grafana stack for metrics collection and alerting.

Pros and Cons

Pros	Cons
Cost Efficiency – Single power draw, reduced hardware footprint.	Single Point of Failure – Hardware degradation impacts all services.
Simplified Management – One set of monitoring, logging, and backup scripts.	Resource Contention – CPU/GPU bursts can affect latency‑sensitive workloads.
Learning Opportunities – Deep dive into Docker, networking, and security.	Maintenance Overhead – Updates must be coordinated across all containers.
Self‑Hosted AI – No reliance on external LLM APIs, preserving privacy.	Scalability Limits – Vertical scaling is capped by RAM and CPU cores.

Use Cases and Scenarios

• Personal Cloud – Replace Dropbox, Google Drive, and iCloud with Nextcloud and Syncthing.
• Developer Workstation – Host GitLab, Gitea, and Drone CI for private repository management.
• Home Automation Hub – Run Home Assistant alongside MQTT brokers and Zigbee2MQTT.
• Local AI Research – Experiment with 7B‑parameter LLMs on a single GPU‑enabled node.

Current State and Future Trends

The homelab ecosystem continues to mature, with projects like Portainer and Watchtower simplifying container management. Emerging trends include:

• Edge Computing – Deploying lightweight services at the network edge for IoT.
• Serverless on Prem – Using K native frameworks to emulate serverless workloads locally.
• AI‑Optimized Containers – Pre‑built images that bundle model weights and inference servers.

---

Prerequisites

System Requirements

Component	Minimum Specification	Recommended
CPU	8‑core processor (e.g., Ryzen 5 3600)	Ryzen 7 3800X (8 cores, 16 threads)
RAM	16 GB	48 GB DDR4 (dual‑channel)
Storage	500 GB SSD	4 TB NVMe array (RAID‑1)
NIC	1 GbE	Dual‑port 1 GbE (one for LAN, one for management)
OS	Ubuntu 22.04 LTS	Ubuntu 22.04 LTS (kernel 5.15+)
Virtualization	KVM support	KVM + nested virtualization (if needed)

Required Software

Software	Version	Purpose
Docker Engine	24.0+	Container runtime
Docker Compose	2.20+	Multi‑service orchestration
Traefik	2.11+	Reverse proxy & TLS
Consul	1.15+	Service discovery
Prometheus	2.50+	Metrics collection
Grafana	10.2+	Dashboarding
Ollama	0.2.0+	Local LLM inference
Bitwarden	1.33+	Password vault
PhotoPrism	2024.3+	Media indexing
Nextcloud	28.0+	File sync & sharing

Network and Security Considerations

• Assign static IPs to each container via Docker networks.
• Restrict inbound traffic using ufw or iptables to only required ports.
• Enable SELinux (enforcing) on the host for additional confinement.
• Use AppArmor profiles for each container to limit syscalls.

User Permissions

• Create a dedicated homelab group for Docker access.
• Add your user to this group and reload group membership (newgrp docker).
• Run containers as non‑root users wherever possible (user: "$UID:$GID").

Pre‑Installation Checklist

1. Verify hardware compatibility (lshw -class cpu,memory).
2. Install Ubuntu Server and apply latest security patches.
3. Configure static IP addresses for eth0 and eth1.
4. Enable SSH key authentication and disable password login.
5. Set up a firewall rule set that allows only necessary ports (e.g., 22, 80, 443, 8080).
6. Install Docker Engine and add your user to the docker group.
7. Pull the base Docker Compose file (docker compose pull).

---

Installation & Setup

1. Clone the Repository

git clone https://github.com/yourusername/homelab-config.git
cd homelab-config

2. Initialize Docker Compose

docker compose up -d

Explanation: This command starts all twenty containers in detached mode. Each service is defined in its own service.yaml file, ensuring modularity.

3. Verify Container Status

docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Image}}\t{{.Ports}}"

Sample output:

$CONTAINER_NAMES    $CONTAINER_STATUS    $CONTAINER_IMAGE    $CONTAINER_PORTS
traefik             Up 2 hours           traefik:latest      ["80->80/tcp","443->443/tcp"]
bitwarden           Up 1 hour            bitwardenrs:latest  ["127.0.0.1:8080->80/tcp"]
ollama              Up 30m                 ollama:latest       ["11434/tcp"]

4. Configure Environment Variables

Create a .env file in the project root:

TRAEFIK_DOMAIN=lab.example.com
BITWARDEN_ADMIN_EMAIL=admin@example.com
OLLAMA_MODEL=llama3:7b

Note: Replace placeholder values with your own domain and credentials.

5. Deploy Traefik with Dynamic Configuration

docker run -d \
  --name traefik \
  --restart unless-stopped \
  -p "80:80" -p "443:443" \
  -v "/var/run/docker.sock:/var/run/docker.sock:ro" \
  -v "./traefik.yml:/traefik.yml:ro" \
  -l "traefik.enable=true" \
  traefik:latest

traefik.yml example:

log:
  level: INFO

entryPoints:
  web:
    address: ":80"
  websecure:
    address: ":443"

providers:
  docker:
    endpoint: "unix:///var/run/docker.sock"
    exposedByDefault: false

6. Set Up Bitwarden

docker run -d \
  --name bitwarden \
  --restart unless-stopped \
  -p "127.0.0.1:8080:80" \
  -e "ADMIN_TOKEN=$(openssl rand -hex 12)" \
  -v "./bitwarden-data:/data" \
  bitwardenrs:latest

7. Deploy Local AI Stack

docker run -d \
  --name ollama \
  --restart unless-stopped \
  -p "11434:11434" \
  -v "./ollama-data:/root/.ollama" \
  ollama/ollama:latest

Pull a model:

docker exec -it ollama ollama pull llama3:7b

Serve the model via a lightweight web UI:

docker run -d \
  --name text-generation-webui \
  --restart unless-stopped \
  -p "7860:7860" \
  -v "./webui-data:/app/outputs" \
  -e "OLLAMA_HOST=http://host.docker.internal:11434" \
  ghcr.io/lm-sys/text-generation-webui:latest

8. Verify All Services

Navigate to https://$TRAEFIK_DOMAIN and confirm that each subdomain resolves to the correct service. Use curl to test endpoints:

curl -s -o /dev/null -w "%{http_code}" https://bitwarden.example.com/api/v1/health

Expected output: 200.

---

Configuration & Optimization

1. Service‑Specific Configuration

Service	Configuration File	Key Parameters	Impact
Traefik	traefik.yml	entryPoints.web.address, providers.docker.exposedByDefault	Determines routing behavior and TLS handling.
Bitwarden	bitwarden.yml	ADMIN_TOKEN, DB_PATH	Controls security token and data persistence.