The Self-Hosted Tools And Apps That I Rely On

The Self-Hosted Tools And Apps That I Rely On

Introduction

Every homelab enthusiast eventually reaches a point where the sheer volume of services, containers, and virtual machines demands more than a collection of one‑off scripts. The challenge is not just to run these components, but to do so in a way that is reproducible, maintainable, and secure. This is precisely the problem that a well‑curated self‑hosted stack solves.

In the context of a home lab or a small‑scale production environment, “self‑hosted” means you own the entire stack—from the underlying hardware to the orchestration layer—without relying on external SaaS offerings. The benefits are clear: complete control over data, the ability to tailor configurations to exact workload requirements, and the freedom to experiment with new technologies without licensing constraints.

This guide is built around the concrete setup described in the Reddit post that inspired this article: a Supermicro X14SBM‑TP4F board, 256 GB of DDR5 memory, a mixed‑capacity storage array built with Proxmox VE, and a suite of Docker‑based services that handle everything from media transcoding to monitoring. While the hardware specifics are unique to the author, the principles, tools, and best practices outlined here are universally applicable to any DevOps professional seeking a rock‑solid, low‑maintenance homelab.

Readers will walk through the entire lifecycle of a modern self‑hosted environment:

• Understanding the core concepts that make a stack reliable.
• Identifying the prerequisites—hardware, OS, network, and security considerations.
• Executing step‑by‑step installations with detailed explanations of each command.
• Configuring services for optimal performance and hardened security.
• Operating the stack day‑to‑day, including monitoring, backups, and scaling.
• Troubleshooting common issues with practical debugging techniques.

By the end of this piece, you should have a clear roadmap for building a homelab that feels as dependable as a well‑oiled machine, while also gaining insight into why each component was chosen and how it fits into the larger ecosystem.

Understanding the Topic

What “Self‑Hosted Tools And Apps” Actually Means

In the DevOps world, the term “self‑hosted” is often used synonymously with “on‑premises,” but the nuance matters. Self‑hosted implies that the software runs on resources you physically control—whether that’s a single‑board computer, a rack‑mount server, or a virtualized environment like Proxmox VE. The applications themselves can range from lightweight CLI utilities to full‑featured web platforms.

Key characteristics of a robust self‑hosted solution include:

• Isolation – Each service runs in its own environment, preventing one misbehaving container from taking down the entire host.
• Reproducibility – Configuration is version‑controlled, making it easy to recreate the exact same setup on another machine.
• Observability – Metrics, logs, and alerts are built‑in, allowing you to spot anomalies before they become outages.
• Extensibility – New services can be added without redesigning the entire stack.

Historical Perspective

The concept of running services locally dates back to the early days of Unix, when administrators would install tools like sendmail or apache directly on a server. The rise of containerization in the 2010s, spearheaded by Docker, transformed this paradigm. Containers offered a lightweight way to package an application with all its dependencies, ensuring that “it works on my machine” became a thing of the past.

Kubernetes further refined the model by introducing declarative orchestration, but for many homelab scenarios, Docker alone—augmented by a simple process manager like docker-compose—provides more than enough capability. The evolution from bare‑metal installs to container‑based deployments mirrors the broader shift toward automation, infrastructure as code, and immutable deployments.

Core Features and Capabilities

When evaluating any self‑hosted tool, consider the following dimensions:

Feature	Why It Matters	Typical Implementation
Modular Architecture	Allows you to replace or upgrade a single component without affecting others.	Use separate Docker containers for each service, each with its own configuration file.
Declarative Configuration	Makes the desired state explicit, enabling automated enforcement.	Store docker-compose.yml and environment files in Git; apply with docker compose up -d.
Resource Efficiency	Homelab hardware is often limited; efficient resource usage prevents bottlenecks.	Allocate CPU and memory limits via cgroups; use lightweight base images.
Security Hardening	Exposing services to the LAN or Internet requires careful isolation.	Run containers as non‑root users, use network namespaces, and employ TLS where applicable.
Observability	Early detection of failures reduces downtime.	Export metrics to Prometheus, logs to Loki, and alerts via Alertmanager.

Use Cases and Scenarios

Self‑hosted stacks shine in a variety of contexts:

• Media Servers – Transcoding and streaming of personal video libraries using tools like Jellyfin or Plex.
• CI/CD Pipelines – Running lightweight GitLab Runner or Drone instances for private repository builds.
• Monitoring & Alerting – Centralizing metrics with Prometheus and visualizing them via Grafana.
• Home Automation – Deploying Mosquitto for MQTT brokerage or Home Assistant for smart‑home orchestration.
• Development Environments – Providing on‑demand development sandboxes with pre‑configured toolchains.

Each scenario demands a different set of resources, but the underlying principles—modularity, reproducibility, and observability—remain constant.

Pros and Cons

Advantages	Drawbacks
Full control over data, updates, and configuration.	Requires initial hardware investment and ongoing maintenance.
Ability to run legacy or niche applications not offered by SaaS.	Learning curve can be steep for newcomers to networking and container orchestration.
Community‑driven open‑source ecosystem provides abundant alternatives.	Resource contention may arise if the host is undersized for the workload.
Customization enables unique integrations (e.g., LAN‑wide backups).	Debugging can become complex when multiple containers interact.

Current State and Future Trends

The self‑hosted landscape is vibrant, with new projects emerging regularly. Trends to watch include:

• Edge Computing – Deploying lightweight services at the network edge for low‑latency access.
• Serverless Frameworks – Bringing function‑as‑a‑service concepts to on‑prem environments via projects like OpenFaaS.
• AI‑Assisted Automation – Using LLMs to generate Dockerfiles or troubleshoot configurations.
• Zero‑Trust Networking – Implementing service meshes (e.g., Istio) to enforce strict communication policies.

These developments suggest that the boundary between “home lab” and “small production” will continue to blur, making a solid foundation in self‑hosted fundamentals increasingly valuable.

Prerequisites

Before diving into the installation steps, it is essential to verify that your environment meets the baseline requirements. The following checklist covers hardware, operating system, network, and security prerequisites.

Hardware Requirements

Component	Minimum Specification	Recommended Specification
CPU	4‑core x86_64 processor	6‑core or higher with virtualization extensions (e.g., Intel VT‑x)
Memory	8 GB RAM	16 GB+ (especially when running multiple containers)
Storage	2 × 1 TB SSD for OS	4 × 8 TB SSD/HDD in RAIDZ1 for primary storage, plus separate array for backups
Network	1 GbE NIC	2 × 1 GbE NICs (one for management, one for service traffic) or 10 GbE for high‑throughput workloads
GPU (optional)	None	Dedicated GPU for transcoding (e.g., NVIDIA RTX series)

The hardware described in the Reddit post—Supermicro X14SBM‑TP4F with dual 256 GB DDR5 modules, a RAIDZ1 array of four 8 TB NVMe drives, and a separate RAIDZ2 pool for media—represents a sweet spot for a medium‑scale homelab. It offers ample CPU cores, generous memory, and flexible storage options that can be leveraged for both VMs and container workloads.

Operating System and Base Software

• Proxmox VE – A Debian‑based hypervisor that simplifies VM and container management. Install the latest stable release (currently 8.x).
• Docker Engine – The industry‑standard container runtime. Use the official Docker repository to install version 24.x or newer, ensuring compatibility with the latest docker compose features.
• Docker Compose – Version 2.20+ is recommended for its native plugin support and improved CLI.
• Git – For version‑controlling your configuration files.
• Backup Tools – restic or borg for encrypted, incremental backups.

All of these components can be installed via the Proxmox web UI or through the command line using apt.

Network and Security Considerations

• Static IP Assignment – Reserve a static IP for the Proxmox host to simplify DNS records and firewall rules.
• Firewall Configuration – Use ufw or nftables to restrict inbound traffic to only the ports required by your services.
• TLS/HTTPS – Terminate TLS at a reverse proxy (e.g., Caddy or Traefik) to avoid exposing containers directly to the Internet.
• User Permissions – Create a dedicated docker group and add your admin user to it; never run containers as root unless absolutely necessary.

User Permissions and Access Levels

• Root Access – Required for installing Docker and Proxmox packages, but day‑to‑day operations should be performed by a non‑root user with sudo privileges.
• Service Accounts – Each container should run under a dedicated, low‑privilege user (e.g., appuser) to limit the blast radius of a container compromise.

Pre‑Installation Checklist

1. Verify hardware compatibility (CPU virtualization, RAM, storage).
2. Install Proxmox VE and apply the latest updates.
3. Configure a static IP and DNS entries for internal services.
4. Install Docker Engine and Docker Compose.
5. Create a non‑root admin user and add to the docker group.
6. Set up a firewall with default deny inbound and allow outbound policies.
7. Prepare a version‑controlled directory for all configuration files (e.g., ~/selfhost-config).

With these prerequisites satisfied, you are ready to move on to the installation and setup phase.

Installation & Setup

This section walks you through the actual deployment of the core components that make up a self‑hosted stack. Each step includes the exact commands, explanations of what they do, and guidance on common pitfalls.

Step‑by‑Step Docker Installation

Begin by updating the package index and installing Docker’s official repository:

# Update package list
apt-get update -y

# Install prerequisite packages
apt-get install -y ca-certificates curl gnupg lsb-release

# Add Docker’s official GPG key
curl -fsSL https://download.docker.com/linux/debian/gpg | gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

# Add Docker repository
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] \
  https://download.docker.com/linux/debian \
  $(lsb_release -cs) stable" | tee /etc/apt/sources.list.d/docker.list > /dev/null

# Refresh package index
apt-get update -y

# Install Docker Engine
apt-get install -y docker-ce docker-ce-cli containerd.io

# Verify installation
docker version

The commands above ensure that Docker is installed from the official repository, which guarantees the latest security patches. After installation, the docker version command confirms that both the client and server components are functional.

Next, install Docker Compose as a plugin to leverage the newer docker compose syntax:

# Create a directory for plugins
mkdir -p /etc/docker/cli-plugins

# Download the latest Compose plugin
curl -SL https://github.com/docker/compose/releases/latest/download/docker-compose-linux-$(uname -m) -o /etc/docker/cli-plugins/docker-compose

# Apply executable permissions
chmod +x /etc/docker/cli-plugins/docker-compose

# Verify the installation
docker compose version

Using the plugin approach eliminates the need for a separate docker-compose binary and integrates seamlessly with the Docker CLI.

Creating a Centralized Configuration Repository

A version‑controlled repository is the backbone of any reproducible setup. Clone a starter template or create your own:

# Clone a sample configuration repository (replace with your own if preferred)
git clone https://github.com/example/selfhost-config.git ~/selfhost-config

# Enter the directory
cd ~/selfhost-config

# List the structure
tree -L 2

Typical repository layout includes:

• docker-compose.yml – Top‑level compose file defining services.
• env/ – Directory containing per‑service environment files (e.g., .env.jellyfin).
• volumes/ – Subdirectory for named volume definitions.
• networks/ – Optional Docker network configurations.

Defining a Sample Service: Jellyfin Media Server

Below is a complete docker-compose.yml snippet for a Jellyfin server, annotated with comments that explain each section.

version: "3.9"

services:
  jellyfin:
    image: jellyfin/jellyfin:latest
    container_name: $CONTAINER_NAMES_JELLYFIN
    restart: unless-stopped
    environment:
      - TZ=