Homelab & Infrastructure | Derek Armstrong — Software Engineer · AI · Infrastructure

Self-Hosting Plausible Analytics with Podman and Cloudflare Tunnels

Sat, 23 May 2026 00:00:00 +0000

I needed website analytics for my blog. Not Google Analytics — I don’t want user data leaving my control, I don’t want the ads ecosystem, and I don’t need per-user behavioral tracking for a personal site. I needed something that tells me which posts show up in search and which ones I should stop writing. Plausible fills that gap.

The open-source Community Edition is free, runs on commodity hardware, and has been supported by the Plausible team for years. The stack runs PostgreSQL, ClickHouse, and the application. Not hard, but enough infrastructure that it’s worth writing down how I set it up, what broke, and how I make sure I don’t lose data.

The Stack

Three containers, two databases, one app:

PostgreSQL 16 — application metadata: sites, users, event configuration, settings
ClickHouse 24.12 — time-series event data: page views, referrers, exit pages, browser data
Plausible App v3.2.1 — the web UI and tracking endpoint that serves the script tag

The Plausible team provides a docker-compose file you can copy. The modifications for podman were minimal.

Podman Quirks on Rocky Linux

It’s supposed to be a drop-in replacement for docker-compose. Same YAML, same commands, just swap the container engine. The issue is rootless pods.

Rocky Linux’s podman doesn’t handle rootless pods well. I hit two issues:

Pod lifecycle crashes — pods would create successfully, but the containers inside would crash immediately with SIGTERM
Network mode host conflicts — network_mode: host caused port binding failures because the containers competed for the same ports

The solution for the pod issue is podman-compose up --in-pod=false, which tells podman to run the containers without grouping them into a pod. Each container runs independently, shares the network via a standard user-defined bridge. Same networking, no pod bugs.

The solution for the network issue is a named bridge network defined in the compose file, with explicit port mappings. No host mode.

The Setup

The deployment lives in a subdirectory on prodweb. The compose file defines three services, four named volumes for each database, and one bridge network. The app container publishes port 8000, which Cloudflare’s tunnel connects to.

The environment file handles the sensitive bits: SECRET_KEY_BASE, BASE_URL, and DISABLE_REGISTRATION. The secret key is generated on first deploy with openssl rand -base64 48. Registration is disabled after the initial admin account is created.

That’s it. No secrets management, no TLS certificates to maintain, no nginx or traefik layer. Cloudflare’s tunnel handles HTTPS termination and routing. I prefer the dashboard for the tunnel config.

Integration with Hugo

The Hugo site uses a theme that supports Plausible out of the box — the Blox theme has a built-in Plausible integration that lets you set the domain and it loads from your self-hosted instance. I changed the script source to point to my Plausible instance and updated the CSP content security policy to allow the tracking script to load from analytics.derekarmstrong.dev.

The tracking script is minimal:

<script async defer data-domain="derekarmstrong.dev" src="https://analytics.derekarmstrong.dev/js/script.js"></script>

That goes in the head, and that’s it. Plausible handles the rest. No cookies, no GDPR notices, no dark pattern consent banners. It’s just page views.

Privacy First

The DISABLE_REGISTRATION=true flag is non-negotiable. Access is restricted to anyone with an account and a valid session token. Plausible scrubs IP addresses by default, storing only a cryptographic hash. The only identifiable data is the domain name and referrer. No user-level tracking, no behavioral analytics. Just aggregate counts.

Backing Up

This is the part most guides skip. Boring but important. There’s two databases, five podman volumes, one compose file, and one .env file. All of it matters. As long as the PostgreSQL and ClickHouse data stays consistent, restoring is straightforward: export the volumes, copy the files, restore on a new server, start the containers, done.

The backup.sh script handles this:

Stops the containers (so the database writes are durable)
Exports each podman volume to a tar archive
Copies .env and compose.yml to the backup
Streams the backup off the host to a local machine
Restarts the containers

The restore.sh script reverses the process: extract the backup, import the volumes, copy the config, start the containers.

Both scripts are idempotent. The backup completes in under 2 minutes for my site. If you’re running a high-traffic site with large event tables, you might want to adjust the STALE_DAYS variable to keep more recent backups around.

Running It

The workflow is:

# Fresh deploy
./deploy.sh

# Backup to local machine
./backup.sh

# Restore from backup
./restore.sh backup-20260523.tar.gz

That’s it. Deploy once, back up regularly, restore when needed.

What I Learned

The Podman rootless pod bugs on Rocky Linux were a real blocker. The ClickHouse config volume mounts don’t work with rootless podman — the workaround is to not mount external configs for ClickHouse at all. Less customization, but it works.

The .env file is the single point of failure for the deployment. If you lose the .env, you lose the installation. The volume data exists on prodweb, but you can’t authenticate to the UI without the config. Every deploy script I’ve written since then backs up .env explicitly. Back it up separately from the volume data.

Plausible itself is solid. The UI is clean, the data is useful, and the privacy-first approach feels right for a personal blog. I’ve been running it for months and it hasn’t given me any trouble.

Key Takeaways

Plausible CE is privacy-first analytics: no cookies, no GDPR banners, no user-level tracking — just aggregate page view counts
Podman rootless pods on Rocky Linux crash; run containers with --in-pod=false to avoid the bug
ClickHouse config volume mounts don’t work with rootless podman — skip external config mounts for ClickHouse
The .env file is the single point of failure; back it up separately and explicitly on every deploy

— self-hosted AI infrastructure on the same homelab
— quick reference for managing containers with Podman

This is a personal blog post about my homelab and self-hosted infrastructure. It reflects what I’ve actually deployed and what has worked in production.

The Proxmox Utility Toolkit: Stop Cloning That VM by Hand

Thu, 09 Apr 2026 00:00:00 +0000

If you’ve been running Proxmox for more than six months, you’ve typed some version of qm clone followed by a bunch of flags you half-remember from the last time, missed a step, and spent twenty minutes wondering why cloud-init isn’t picking up your IP. You’re not alone. I’ve done it enough times that I considered making it a cardio routine.

After enough repetitions, the sensible answer isn’t “memorize the flags better.” It’s to build a toolkit, document it properly, and stop trusting your past self’s memory. So that’s what I did — and now it lives at .

What the Repository Actually Is

The is a collection of shell scripts and documentation targeting Proxmox VE 8.x on Debian 12. It isn’t an abstraction layer, and it isn’t trying to replace the Proxmox web UI. It’s a set of opinionated scripts that handle the tedious parts — templating, cloning, backups, network reporting — so you can focus on what you’re actually trying to learn or build.

The structure follows a clear division: scripts/ is where the automation lives, and the top-level directories (backup/, gpu-passthrough/, networking/, security/, automation/) are documentation bundles that explain the why behind the how.

proxmox/
├── scripts/
│ ├── vm/ # Cloud-init templates, clone, snapshot, destroy, console
│ ├── containers/ # LXC creation and management
│ ├── backup/ # Single-VM, bulk, pruning, status reports
│ ├── k8s/ # Oracle Linux Kubernetes cluster deployment
│ ├── api/ # API token creation, curl wrappers
│ ├── network/ # Network config reporting across VMs/containers
│ └── storage/ # Disk usage and cleanup
├── backup/ # Strategy docs: 3-2-1, GFS retention, PBS setup, verification
├── gpu-passthrough/ # NVIDIA CUDA, AMD ROCm, gaming VMs, troubleshooting
├── networking/ # VLAN, firewall rules, SDN configuration guides
├── automation/ # Ansible playbooks, Terraform configs, learning path
├── security/ # Zero trust, CIS benchmarks, auditing, incident response
└── learning-paths/ # Skill progression from "create a VM" to "zero trust"

One config file drives everything. Copy config.example.sh to config.sh, fill in your storage pool, bridge interface, SSH key path, template IDs, and backup retention settings. Set it once, use it across every script.

VM Templates and Cloning

This is where most people spend the most time repeating themselves. Two cloud-init flavors are supported out of the box:

# Ubuntu 24.04 — pull the SHA256 from the Ubuntu cloud images page
bash scripts/vm/create_cloud_init_template.sh -i 9000 --sha256 <ubuntu_sha>

# Oracle Linux 9 — checksum is bundled; this one just works
bash scripts/vm/create_cloud_init_template.sh -i 9100 --os ol9

Once you have a template, cloning is one line:

bash scripts/vm/clone_vm.sh -s 9000 -d 150 -n web01 -i 192.168.1.60/24 -g 192.168.1.1

Source template, destination ID, hostname, IP/mask, gateway. Your static IP and SSH key are baked into the VM before it boots. This is the “set it up correctly once and never think about it again” approach to ops. The rest of the VM scripts handle the supporting cast: snapshot.sh for point-in-time recovery, destroy_vm.sh when you’re done, console.sh for quick access, and find_ip.sh for when you can’t remember which IP you assigned to what.

Aside: Cloud-init is one of those technologies that makes complete sense once you understand it and is maddening until you do. The most common trap is expecting cloud-init to re-run after the VM has already booted once — it won’t without being told to. If your config isn’t applying, cloud-init clean followed by a reboot will save you a significant amount of frustrated tab-completion.

There’s also check_template.sh to validate your template before you clone twenty VMs from it. Speaking from personal experience: validate the template.

Backups You’ll Actually Verify

Backups are one of those things everyone says they have until the moment they actually need one. The toolkit handles the whole lifecycle:

# Single VM or container
bash scripts/backup/backup_vm.sh --vmid 150

# Everything on the node
bash scripts/backup/backup_all.sh

# Prune per your retention policy
bash scripts/backup/prune_backups.sh

# Report on what's actually protected
bash scripts/backup/report.sh

The backup strategy documentation covers the 3-2-1 approach (local backup, offsite copy, one offline or air-gapped) and GFS retention — Grandfather-Father-Son — which defines exactly how long daily, weekly, monthly, and yearly backups survive before pruning. It’s the structure commercial backup products charge extra to explain.

The piece I’d read first, though, is backup/verification.md. It covers how to confirm a backup is actually usable before you’re under pressure to find out. “I think it ran” is not a backup strategy. Running a restore drill in a test environment once and confirming it succeeds is.

GPU Passthrough Without the Three-Hour Research Session

GPU passthrough in Proxmox has a well-earned reputation for being complicated. The gap between “works in theory” and “works for my specific GPU and motherboard combo” is where most people give up and just run the GPU on bare metal. The documentation in the toolkit covers both major paths:

NVIDIA + CUDA — for AI/ML workloads on a dedicated GPU inside a VM, with the driver configuration that actually sticks
AMD + ROCm — the open-source path for inference and compute work, including ROCm setup inside the guest
Gaming VMs — single GPU passthrough for a Windows gaming VM is a completely reasonable use of hardware you own, and there’s a dedicated guide for it

There’s a troubleshooting guide for when IOMMU groupings don’t cooperate, which on consumer hardware is more of a “when” than an “if.” ACS override options, VFIO binding order, and the usual suspects are all covered.

Kubernetes on Top of Proxmox

One script deploys a full Oracle Linux Kubernetes cluster:

bash scripts/k8s/deploy_ol_k8s_cluster.sh --config config.k8s.sh

It targets the 192.168.1.50-99 homelab IP range by default, handles VM provisioning, and walks through the Kubernetes bootstrapping sequence. This is explicitly a learning-path feature — it’s not production-hardened, and it doesn’t pretend to be. What it is good for is understanding how Kubernetes actually comes together piece by piece, without a managed service abstracting away the interesting parts.

If your goal is to understand what kubeadm init is doing and why, this is a faster path to that knowledge than starting from scratch.

Security Worth Taking Seriously

Security docs in most homelab repos are an afterthought dropped in because someone mentioned it in a pull request. This one treats security as first-class content:

Document	Coverage
`security/zero-trust.md`	Network segmentation, identity verification, least-privilege access
`security/cis-benchmarks.md`	Host hardening guidelines for the Proxmox node itself
`security/auditing.md`	What to check, how often, and what to do with the results
`security/incident-response.md`	What to do when something actually goes sideways

The honest caveat: these are guides, not automation. The expectation is that you read them, understand the reasoning, and implement with intention — not apply them blindly and assume you’re done. Security posture is a continuous practice, not a one-time configuration.

Automation: Ansible, Terraform, and API Access

Once you’re past one-off scripts and want repeatable, idempotent infrastructure, the toolkit has an on-ramp:

Ansible playbooks — configuration management for Proxmox nodes and the VMs running on them
Terraform + HCL — infrastructure-as-code for provisioning, with a main.tf and example patterns to build from
API helpers — create_api_token.sh and a minimal curl wrapper for the Proxmox API, useful when you’re scripting against the REST interface and don’t want to build that boilerplate yourself

The automation/learning-path.md lays out the progression: scripts first, Ansible when you need repeatability across multiple nodes, Terraform when you’re ready to think declaratively about what infrastructure should exist. That order matters — jumping straight to Terraform before you understand what it’s abstracting will bite you.

Learning Paths: There’s an On-Ramp for Everyone

This is the part that makes the toolkit useful across experience levels rather than just to people who already know what they’re doing:

Path	What You’re Building
Beginner	VM and container basics, simple backups, basic networking
Intermediate	VLANs, firewall rules, automated backup retention, Ansible
Advanced	Proxmox Backup Server, GPU passthrough, Terraform IaC
Expert	Zero trust architecture, CIS benchmark compliance, automated incident response

Most resources assume you’re either totally new or already building production clusters. The learning paths here acknowledge that the interesting ground is in between — where you understand enough to ask the right questions but haven’t yet built the muscle memory for the complex stuff.

Getting Started

git clone https://github.com/dereklarmstrong/proxmox.git
cd proxmox
cp config.example.sh config.sh # Edit with your storage pool, bridge, SSH key path
./scripts/test.sh # Run the test suite — worth doing before you rely on any of this

The logical starting point from there is enabling the community repository:

bash scripts/setup/pve_community_repo.sh

Then create_cloud_init_template.sh to build your first template. Everything else in the toolkit follows from having a good, verified base template to clone from.

Key Takeaways

Clone any cloud-init VM — Ubuntu 24.04, Oracle Linux 9 — with a single command, static IP and SSH key pre-configured, no copy-paste required.
Full backup coverage out of the box: per-VM, bulk, GFS retention policies, and a status report so you actually know what’s protected.
GPU passthrough documentation for NVIDIA CUDA and AMD ROCm in one place — AI/ML and gaming paths covered.
Structured learning paths from beginner to expert so the toolkit grows with you rather than overwhelming you on day one.
This is a learning playground, not a production blueprint. Complexity is a liability. The scripts exist to build skills, not to run your business.

— Once your VMs are provisioned, you need databases. This post covers picking and securing stores that stay boring (in a good way).

Nagios: A 10-Year Retrospective on Infrastructure Monitoring

Wed, 05 Nov 2025 00:00:00 +0000

Back in 2015 I installed Nagios in my homelab and pushed it out to a few servers at work. That was ten years ago, and even then Nagios felt like an OG, a little venerable. But the thing about Nagios is simple: it tells you when stuff is broken, loudly and reliably. It’s the tape measure of monitoring, not flashy, but it does the job.

The Strategic Validation Approach

I first deployed Nagios in my homelab to validate it as a viable enterprise solution before proposing it for production use. This homelab-to-production pipeline became a pattern I’d use throughout my career, prove the concept in a controlled environment, demonstrate value, then scale to production.

The homelab deployment served multiple purposes:

Risk mitigation: Test configurations and failure scenarios without production impact
Knowledge building: Understand operational characteristics and maintenance requirements
Documentation creation: Build runbooks and procedures before production deployment
Stakeholder confidence: Demonstrate concrete results to secure buy-in

This validation approach proved invaluable when it came time to deploy at scale.

Production Deployment: Transforming IT Operations

In 2015, I implemented Nagios Core for a multi-location restaurant chain’s enterprise infrastructure, monitoring mission-critical systems supporting Marketing, Accounting, Operations, and IT departments. With on-premises rack infrastructure hosting critical business applications, visibility and rapid incident response were non-negotiable.

Architecture and Scale

The deployment monitored:

Physical infrastructure: Network switches, routers, and edge devices across multiple locations
Virtualization platform: VMware ESXi hosts and guest VMs running core business services
Application services: Payment processing, point-of-sale integration, inventory management, and business intelligence platforms
Network health: Bandwidth utilization, latency metrics, and connectivity monitoring

Business Impact: From Reactive to Proactive

The transformation was measurable:

Mean Time to Detection (MTTD): Reduced from hours (waiting for user reports) to minutes (automated alerts)
Mean Time to Resolution (MTTR): Improved significantly through early problem detection and automated escalation
IT team efficiency: Support team shifted from constant firefighting to proactive maintenance and strategic projects
Business continuity: Critical application downtime decreased substantially through early intervention

The key insight: Monitoring isn’t just about knowing when things break, it’s about preventing disruptions before they impact business operations.

Quick Personal Setup

My homelab configuration provided the foundation:

Nagios Core on a small VM (2 vCPU, 4GB RAM, remarkably lightweight)
NRPE (Nagios Remote Plugin Executor) on Linux servers for remote checks
SNMP monitoring for network switches and printers
Host/service groups, email alerts, basic escalation rules
Stable, low-maintenance, perfect for static infrastructure

This same architecture scaled to production with minimal modifications, a testament to Nagios’s solid foundation.

Purpose and Architecture

Nagios Core performs periodic checks of hosts and services, runs plugins to test availability and health, and alerts when thresholds are breached. It’s rule-based monitoring with dependency handling, escalations, and a massive plugin ecosystem that covers virtually any service or device.

The architecture is refreshingly straightforward:

Scheduled checks: Predictable, configurable monitoring intervals
Plugin ecosystem: Extend monitoring to any service or protocol
State management: Clear host/service states (OK, Warning, Critical, Unknown)
Dependency handling: Prevent alert storms through intelligent parent/child relationships
Escalation policies: Route alerts appropriately based on severity and duration

Key Benefits

Proven and stable: Decades in production across countless organizations
Lightweight architecture: Minimal resource consumption, even at scale
Huge plugin ecosystem: Likely a plugin exists for whatever you need to monitor
Predictable alerting model: Host/service states, dependencies, escalations, no surprises
Fully on-premises: Great for air-gapped or regulated environments
Open source (Nagios Core): No vendor lock-in for basic monitoring needs

Free Tiers / Editions

Nagios Core: Free and open source (self-hosted)
Nagios XI: Commercial with evaluation/demo; paid tiers for enterprise features and polished UI
Other Nagios products: Fusion, Log Server, Network Analyzer are commercial or trial-based

When to Choose Nagios

Strategic fit for:

Small to medium static IT environments (servers, VMs, network gear)
Labs, classrooms, SMBs, and conservative or regulated organizations
On-premises / air-gapped environments where SaaS is prohibited
Teams wanting straightforward up/down availability checks and predictable alerts
Organizations needing comprehensive community checks without building from scratch

When Not to Choose Nagios

Consider alternatives for:

Cloud-native, highly dynamic infrastructure (ephemeral containers, autoscaling)
Rich time-series metrics, long-term trend analysis, anomaly detection, or high-cardinality telemetry
Large, high-scale environments with heavy metric volumes (Prometheus-style stacks scale better)
Modern UIs, automated incident correlation, integrated logs/metrics/traces, or extensive SaaS integrations

Industries Where Nagios Shines

Education & labs: Easy management of classroom PCs, lab servers, and fixed infrastructure
SMBs and small IT shops: Low cost, low complexity
Government or regulated organizations: On-premises-only monitoring requirements
Traditional enterprises: Stable, non-ephemeral infrastructure (datacenters, network device uptime)

Industries Where It Struggles

Cloud-native SaaS companies: Modern DevOps teams with ephemeral infrastructure
Large web platforms: Requiring high-volume telemetry and advanced analytics
Organizations demanding modern observability: Integrated traces, logs, and metrics with automated anomaly detection

Quick Pros & Cons

Pros: Dependable, extensible plugin library, lightweight, fully on-premises

Cons: Old-school configuration model, limited metric retention/analysis, dated UI, not ideal for dynamic fleets

Alternatives and Comparison

Metrics + alerting for modern infrastructure: Prometheus + Grafana

Modernized Nagios-style: Icinga2, Check_MK, Zabbix

SaaS / deep integrations: Datadog, New Relic, LogicMonitor

Flexible checks + event handling: Sensu

Criteria	Nagios	Prometheus	Zabbix
Primary focus	Availability checks (hosts/services)	Time-series metrics & alerting	Unified monitoring: metrics, traps, availability
Best for	Small/SMB/static infra, labs	Cloud-native, containerized, microservices	Mid-to-large infra needing both metrics & legacy device support
Scale	Small → medium (with effort)	High (designed for scale; federation)	Medium → large (scales with clustering)
Data model & retention	Check states, limited metric history	TSDB (Prometheus), short-term retention by default; long-term via remote storage	Built-in history storage with configurable retention
Metrics visualization	External tools (Grafana) or basic UI	Grafana or built-in graphing; strong ecosystem	Built-in dashboards; Grafana integration
Alerting & correlation	Basic alerts, escalations, dependencies	Powerful rule-based alerts; Alertmanager for grouping/dedup	Flexible triggers, escalations, notifications
Dynamic/cloud-native support	Poor for ephemeral infra	Excellent (service discovery, scraping)	Good (agent, SNMP, auto-registration)
Setup & maintenance	Simple for small installs; config heavy	Pull model needs scrape config + storage planning	Agent + server setup; GUI config but can be complex
Extensibility/plugins	Huge plugin ecosystem	Exporters + client libs; many integrations	Templates, user parameters, scripts
On-premises friendliness	Excellent (air-gapped friendly)	Good (self-hosted)	Excellent (on-premises first)
Typical use cases	Labs, SMBs, network device uptime, regulated envs	Metrics for microservices, SRE workflows, high-cardinality monitoring	Mixed environments: servers, network, apps, SNMP devices
Not suitable when	Need long-term metrics, dynamic infra, advanced analytics	Need raw host/service plugin checks or heavy SNMP device mgmt	Need extreme TSDB scaling or cloud-native ephemeral service auto-discovery

Quick Pick Guide

Choose Nagios if you want simple, reliable up/down checks, on-premises only, and a massive plugin library for legacy devices
Choose Prometheus if you run cloud-native, containerized apps and need high-resolution metrics, service discovery, and modern alert routing
Choose Zabbix if you need an all-in-one on-premises system covering metrics, SNMP, traps, and history without stitching many components together

Architectural Lessons Learned

After a decade of Nagios deployments, key insights emerged:

Configuration as code: Treat Nagios configs like application code, version control, peer review, automated testing

Dependency modeling: Properly configured dependencies prevent alert fatigue and focus attention where it matters

Escalation policies: Well-designed escalations ensure the right people are notified at the right time without overwhelming anyone

Plugin standardization: Custom plugins should follow consistent interfaces and error handling patterns

Monitoring the monitor: Nagios itself needs monitoring, use external health checks to ensure your monitoring system is operational

Final Thought

Monitoring is boring until it saves your day, then it’s priceless. Nagios is old school, but if you want a no-nonsense, on-premises sentinel that simply tells you “this server is down,” it still earns its keep. Use it for stability and simplicity; choose a newer stack when you need rich metrics, scale, and modern observability features.

After ten years, the homelab installation that validated an enterprise deployment is still running. That’s the kind of stability and reliability that defines Nagios: unglamorous, dependable infrastructure monitoring that just works.

Key Takeaways

Validate in a homelab first — prove the concept at small scale before committing to production deployment
Nagios is still relevant for static infrastructure: on-premises labs, SMBs, regulated environments where SaaS monitoring is off the table
When infrastructure is ephemeral or highly dynamic, Prometheus or Zabbix are better fits than Nagios
Good dependency modeling and escalation policies prevent alert fatigue; bad configuration turns monitoring into noise

— homelab-to-production in action with a completely different workload
— how the underlying infrastructure was built

Podman Cheat Sheet

Wed, 21 May 2025 00:00:00 +0000

Start and Stop Containers

Start a container:
```
podman start <container_name_or_id>
```
Stop a container:
```
podman stop <container_name_or_id>
```

Build an Image

Build an image from a Dockerfile:
```
podman build -t <image_name:tag> .
```

Run a Container

Run a container:

podman run --name <container_name> <image_name:tag>

Run a container and remove it after it exits:
```
podman run --rm <image_name:tag>
```

Remove Containers and Images

Remove a container:
```
podman rm <container_name_or_id>
```
Remove all stopped containers:
```
podman container prune
```
Remove an image:
```
podman rmi <image_name_or_id>
```

Podman Compose (if using `podman-compose`)

Start containers with Podman Compose:
```
podman-compose up
```
Stop containers with Podman Compose:
```
podman-compose down
```
Build images with Podman Compose:
```
podman-compose build
```

Additional Useful Commands

Inspect

Inspect a container (view details about a running or stopped container):
```
podman inspect <container_name_or_id>
```

Logs

View logs for a container:
```
podman logs <container_name_or_id>
```

List Containers and Images

List all containers:
```
podman ps -a
```
List running containers:
```
podman ps
```
List all images:
```
podman images
```

Key Takeaways

Podman is a drop-in replacement for Docker with a CLI that maps 1:1 for common container operations
podman-compose handles multi-container setups, but requires the separate podman-compose package
Rootless podman is the default and preferred mode — no daemon running as root is a security improvement over Docker
Commands group by lifecycle: start/stop, build/run, remove, inspect/logs, and list

— a real-world Podman deployment with troubleshooting notes
— container basics and why they matter for development workflows

Gitea: Git on Your Own Terms

Wed, 23 Apr 2025 00:00:00 +0000

Welcome, fellow home lab enthusiasts! If you’re anything like me, you’ve probably caught yourself thinking, “You know what my server rack needs? More services to tinker with!” Well, today we’re diving into one of my favorite self-hosted applications: a personal Git server with Gitea. It’s like having your own mini GitHub, without the corporate overlords or surprise “updates” to the terms of service.

Why Gitea? The Little Git Server That Could

In the world of self-hosted Git solutions, Gitea stands out like a sane person at a cryptocurrency convention. Written in Go, Gitea is ridiculously lightweight, blazing fast, and requires minimal resources - perfect for that dusty Raspberry Pi or the VM you’ve allocated just 512MB of RAM to.

While GitLab offers a more comprehensive DevOps platform with all the bells and whistles (and resource requirements to match), Gitea focuses on doing one thing extremely well: being a Git server that doesn’t make your hardware weep. As one user aptly put it: “Gitea + SQLite is perfect for home lab. Zero maintenance overhead”.

The interface will feel familiar to GitHub users, which makes the transition nearly painless. Plus, the project is actively maintained with regular updates and security patches.

The Pros: Why You’d Want Your Own Git Fortress

Data Sovereignty: Your Code, Your Rules

Having your own Git server means you’re not subject to a third party’s policies, outages, or sudden pricing changes. No third party has access to your data, ensuring security (which can still be questionable), and you have unlimited repository size.

Mirror, Mirror on the Wall, Who Has the Most Repos of All?

One of Gitea’s killer features is its mirroring capability. You can:

Mirror repositories from GitHub, GitLab, or other services to create automatic backups
Push changes from your private Gitea instance to public repositories
Keep everything in sync with minimal effort

Gitea makes it trivial to mirror a repo. You just choose ’new migration’ from under the ‘+’ menu, and then click on the service you’re migrating from.

Unrestricted Runner Minutes: CI/CD without the Meter Running

Unlike GitHub, which meters your CI/CD minutes like a stingy taxi driver, your self-hosted Gitea instance lets you run your CI/CD pipelines as long as your hardware can handle it. Want to set up a 3-hour build process that compiles your personal project on seven different architectures? Go wild!

Offline Access: Because Internet Outages Are a Thing

Another great reason to host your own Gitea instance is that it’s available offline. When your internet decides to take an unscheduled vacation, you can still commit changes, browse code, and reference documentation.

Unlimited Private Repositories

You don’t need to pay for private repositories or worry about limits from third-party services. With your own server, you have full control and can create unlimited private repositories at no extra cost. This lets you organize projects your way, whether they’re small or large, and customize your workflow to fit your needs.

The Cons: The Price of Freedom

Maintenance: You Break It, You Fix It

Self-hosting means being your own system administrator. When things go sideways, there’s no support ticket to file (unless you count yelling at your server rack).

Backups: Don’t Be That Person

You absolutely need a backup strategy. “Just wondering what everyone is doing to back up a gitea container?” is a question you should answer before, not after, a disk failure.

Security: With Great Power Comes Great Responsibility

Security - continuous monitoring just in case someone gets curious…and lucky. If you’re exposing your Gitea instance to the internet, you need to be vigilant about security. Do your homework, understanding how to impliment good security is a high value skill!

Protecting Your Code Castle

If you’re keeping your Gitea instance local, behind your firewall, security is relatively simple. But if you’re exposing it to the internet, consider:

Using Cloudflare Zero Trust tunnels to avoid opening ports
Enforcing two-factor authentication for all accounts
Keeping your instance updated religiously
Implementing strong password policies

Remember: The first registered user automatically gets admin privileges, so set up your account immediately after installation!

Setting Sail with Docker Compose

Getting started with Gitea is as easy as creating a docker-compose.yml file. Here’s a basic example to get you started:

version: "3"

services:
 server:
 image: gitea/gitea:latest
 container_name: gitea
 environment:
 - USER_UID=1000
 - USER_GID=1000
 restart: always
 volumes:
 - ./gitea:/data
 - /etc/timezone:/etc/timezone:ro
 - /etc/localtime:/etc/localtime:ro
 ports:
 - "3000:3000"
 - "2222:22"

Save this to a file, run docker-compose up -d, and voilà! Your Gitea instance will be available at . The first user to register will become the admin.

For those who prefer a more rootless approach (because who doesn’t like added security?), Gitea also offers a rootless Docker image that uses Gitea’s internal SSH instead of OpenSSH.

Customization: Making It Your Own

The beauty of self-hosting is customization. Want to change the theme? Go for it. Need to integrate with your existing authentication system? It’s possible. Want to add a dancing cat gif to the login page? Weird, but technically doable.

All configuration is stored in the app.ini file, which you can find in the custom directory of your Gitea installation.

Backup Strategies: Because Stuff Happens

Gitea provides a built-in dump command that creates a ZIP file containing everything needed to restore your instance. However, for a more robust solution, consider:

Regular database backups
Volume snapshots if you’re using a filesystem that supports them
Repository mirroring to another location
Automated backup scripts that run on a schedule

Remember: a backup you haven’t tested restoring from is just a file taking up disk space.

Conclusion: To Git or Not to Git?

Self-hosting Gitea is like brewing your own craft beer. Sure, you could just buy it from the store, but where’s the fun in that? Plus, you get to brag about it to your friends who don’t care but politely nod anyway.

The control, flexibility, and ownership you gain makes it worth the effort, especially if you’re already maintaining a home lab. So fire up that Docker container and start gitting on your own terms. Your code deserves a home where it’s treated like the precious resource it is, not just another tenant in a massive cloud datacenter.

References

Gitea Documentation. (2023). Repository Mirror.
Gitea Documentation. (2023). Installation with Docker (rootless).
Stack Overflow. (2017). Which are the pros (and cons) of self-hosting your repositories.
XDA Developers. (2024). 5 reasons you should host your own Git server at home using Gitea.
. (2022). Mirroring With Gitea.
phoenixNAP. (2025). How to Install Gitea with Docker on Ubuntu.
Reddit. (2019). Pros & Cons: Self Hosted Git.

Key Takeaways

Gitea is lightweight enough for a Raspberry Pi or a 512MB VM. Written in Go, it does one thing well without the resource drain of GitLab.
Repository mirroring is a killer feature. One-click mirroring from GitHub or GitLab gives you automatic backups and offline access.
Self-hosted CI/CD means unlimited runner minutes. Build pipelines run as long as your hardware can handle them.
Security is your responsibility. Cloudflare Zero Trust tunnels, 2FA, and strong password policies are the bare minimum when exposing Gitea to the internet.
A backup you have not tested restoring from is just a file taking up disk space. Test restores regularly.

— the server infrastructure that makes self-hosting services practical.
— VM management tools for the homelab that runs alongside container services.

Dev Magic with Docker

Wed, 19 Feb 2025 00:00:00 +0000

Docker removed the “it works on my machine” problem by packaging applications with all their dependencies into containers. If you’ve spent time debugging why a service runs on one machine but not another, Docker is the solution that made that problem disappear.

So, What’s Docker?

Docker is this awesome open-source platform that helps you package up your application, along with EVERYTHING it needs to run—like libraries, dependencies, and settings—into little units called containers. Think of a container like a “to-go” box for apps. You put all the ingredients inside, close the lid, and boom! It works the same wherever you take it—on your laptop, your data center, or even the cloud. No more “but it worked on my machine!” excuses (we’ve all been there). Now, here’s the extra-cool part: Unlike virtual machines (VMs), which are big, bulky, and carry an entire operating system with every app instance, Docker containers share the host OS. They’re lightweight, resource-friendly, and stupid fast. You could say Docker is like upgrading from a clunky wagon to a sleek sports car.

Why Do Developers Love Docker?

Here’s the deal: Docker makes life way simpler. It’s packed with features that hit all the right developer feels. Let’s break it down:

1. It’s Lightweight, Like REALLY Lightweight

Imagine running multiple apps on one computer without it feeling like it’s gasping for air. Instead of bulky VMs, Docker containers are super slim because they piggyback off the host system’s OS. Think of a VM as an entire mansion for one app, but Docker? It’s like cool tiny homes that share utilities but still have their own kitchens. Efficient, right?

2. Speed Is Its Middle Name

Want faster development cycles? Done! Docker containers start up in literal milliseconds. Forget waiting around for a VM to boot (“Go grab coffee” fast). Docker’s more like a “Blink and it’s ready” vibe.

3. It Works Everywhere (No Drama)

Ever wasted hours debugging why your app works on dev but not prod? With Docker, what you build works EXACTLY the same wherever you take it. Linux, Windows, cloud, data centers—it’s all the same to Docker. No nasty surprises when moving your app from your laptop to a server.

4. It’s Amazingly Efficient

Each container is tiny, using only the resources it needs—nothing more, nothing less. That means you can run a ton of containers on the same system without feeling like you’re playing Jenga with your server.

5. Scaling Is a Breeze

If your app goes viral overnight (lucky you!), no worries. Scaling with Docker is as easy as spinning up a few more containers. Bonus: They’re already optimized to run super-smooth on minimal resources.

Docker vs Virtual Machines: Who Wins?

Let’s get real: VMs aren’t bad. They’re great if you need the full OS-within-an-OS thing. But for most modern app development, Docker wipes the floor with VMs.

Feature	Docker	Virtual Machines
Startup Speed	Milliseconds!	Minutes (go grab a snack)
Resource Usage	Lightweight and shared OS	Heavy. Every VM carries an OS
Portability	Works consistently EVERYWHERE	Needs specific setup
Scalability	Piece of cake	Lots of moving parts. More $$$
Isolation	Strong enough for most cases	Maximum (but overkill for many apps)

In short? Docker wins for modern apps, microservices, and cloud-native stuff. VMs are fine, but Docker’s just better.

The Secret Sauce to Docker: Best Practices

Docker’s fantastic out of the box, but if you want to go pro-level, let’s talk best practices. These handy tricks will help you avoid common mistakes and squeeze every bit of awesome out of Docker.

Image Optimization: Keeping It Tidy

Go Minimal: Big images are bad. Use lightweight options like alpine to save storage—trust me, your hard drive will thank you.
Multi-Stage Builds: Reduce bloat by separating build and run steps, so the final container is lean and clean.
Clean Up After Yourself: Combine steps to avoid extra Dockerfile layers. Basically, don’t hoard unnecessary stuff.

Performance Hacks: Make It Fly

Set Resource Limits: Stop containers from acting greedy with your CPU and memory. (Yes, you can tame them.)
Get Smart with Layer Caching: Order your Dockerfile to maximize the caching magic and speed up builds.
Add Health Checks: Docker can automatically check if your app is running properly. No more manual box-checking.

Security Tips: Stay Safe Out There

Don’t Go All “Root”: Running as root = bad idea. Create a specific user for your app instead.
Stick to Trusted Images: Use official or verified images from Docker Hub for peace of mind.
Lock it Down: Use restricted privileges and read-only flags whenever possible. Better safe than sorry!

But Wait… There’s More

Docker’s not just a one-trick pony. Once you master the basics, there are all these cool advanced features you can dive into:

Use Docker Swarm or Kubernetes: Running tons of containers? Tools like Swarm and Kubernetes let you orchestrate your containers so everything stays organized and smooth. It’s like being the conductor of your own app orchestra.
Routing Mesh: No matter where your containers live, Docker ensures incoming requests find them. It’s basically traffic control for your app.
Shrink Images (Without Tears): Tools like docker-slim trim all the unnecessary fat from your images. Think weight loss for software.

Real-Life Cool Stuff You Can Do with Docker

Docker’s powering everything from indie apps to enterprise giants. Here’s just a glimpse of how people are using it:

Microservices: Break big monolithic apps into smaller pieces. Develop, test, and deploy them in neat little chunks.
Cloud Stuff: Containers and the cloud go together like peanut butter and jelly. Developers love how portable and scalable Docker is.
CI/CD Pipelines: Test and ship faster by rolling containers through build pipelines like a factory assembly line. Fun fact: This is why a lot of DevOps teams have Docker tattoos. Probably.

Wrapping It Up (With a Bow )

Docker isn’t just software; it’s a movement—a better way of doing things. Whether you’re looking to clean up your dev workflow, scale your app like a pro, or just stop screaming “Why won’t this work!?” at your computer, Docker’s there for you. Start small, follow best practices, and before you know it, you’ll be deploying apps like a rockstar. Ready? Grab a coffee, install Docker, and dive into the world of containers. Your future self will thank you. More consistency. More speed. More fun. That’s Docker.

Key Takeaways

Docker containers package your app with all its dependencies, eliminating the “it works on my machine” problem by design.
Containers are lightweight because they share the host OS kernel, unlike VMs that each carry a full OS — result is faster startup and more instances per server.
Use alpine base images, multi-stage builds, and ordered Dockerfiles to keep image size down and build times fast.
Never run containers as root, pin trusted base images, and use read-only flags where possible. Security starts at build time.

— why your Docker installation method matters
— a real-world example of running containers with backup策略

Comparing Docker.io and Snap Docker on Ubuntu

Wed, 04 Sep 2024 00:00:00 +0000

Docker is a game-changer for developers and DevOps folks. It lets you package applications into containers, making them super portable and easy to manage. But when it comes to installing Docker on Ubuntu, you have a couple of options: and snap docker. Let’s take a look at both to see what fits your needs and project!

Overview of and snap docker in Ubuntu

First up, we have . This is the classic way of installing Docker using the APT package manager. You just run sudo apt install , and boom, Docker is ready to roll. It’s like ordering your favorite pizza and having it delivered right to your door.

Then there’s snap docker. Snap is a package management system that makes it easy to install and update software. You can get Docker via Snap by running sudo snap install docker. It’s a more modern approach and has some cool features, but it also comes with a few quirks. Think of it as getting a gourmet pizza with some unique toppings – exciting, but maybe not for everyone.

Comparison of and snap docker in terms of file access permissions

Here’s where things get interesting. One of the key differences between and snap docker is how they handle file access permissions.

: This version of Docker has more traditional file access permissions. It can access files outside of your home directory if needed. This is handy for certain use cases where you need Docker to interact with system files or directories. Imagine having a master key that lets you into any room in the house.
snap docker: Snap packages are designed with security in mind, so they come with stricter confinement. Snap docker is limited to accessing files within the $HOME directory. This means it can’t poke around in system directories, which can be a good thing for security but might be a limitation for some advanced use cases. Think of it as having a key that only lets you into your bedroom – safe, but a bit restrictive.

Implications for DevOps and security professionals

For DevOps and security pros, the choice between and snap docker can have significant implications.

Security: Snap docker’s confinement model adds an extra layer of security by restricting file access. This can help prevent malicious containers from messing with your system files. If security is a top priority, snap docker might be the way to go. It’s like having a security guard at your door, making sure only the right people get in.
Flexibility: On the flip side, offers more flexibility. If your workflows require Docker to access files outside the home directory, is the better choice. It’s more aligned with traditional Docker setups and might be easier to integrate into existing systems. Think of it as having the freedom to roam around your entire house without restrictions.

Key Takeaways

docker.io (APT) gives you unrestricted file access — necessary when containers need to interact with system directories or bind-mount outside your home folder.
Snap Docker runs in a confined sandbox limited to $HOME. Better security for isolated work, but a dealbreaker for workflows that need broader access.
For most DevOps setups and CI/CD pipelines, docker.io is the practical choice. Snap Docker fits personal or highly restricted environments.

— why Docker matters for local development and infrastructure
— the production infrastructure using container management

Redirecting Root Domain with Cloudflare

Wed, 28 Aug 2024 00:00:00 +0000

You know the old saying, “It’s always DNS”? Well, it’s true. And the more you dabble in the wonderful world of web management, the more you realize just how much your digital kingdom rests on those little DNS settings. Whether you’re managing a massive web empire or just tinkering with your personal site, knowing how to tame your network infrastructure is like having the keys to the castle. So let’s get into it and setup a redirect at the root level domain together!

Example Scenarios

Redirecting a root domain using Cloudflare is a common practice in various scenarios, especially when managing web traffic, branding, or SEO. Here are some scenarios where someone might need to do this:

1. Branding and Consistency

Redirecting Non-www to www: Because we all want to look sharp and consistent, right? You might want all traffic to go to instead of . This helps ensure that users always see the same version of your site, like having all your socks match—because mismatched URLs are just as bad as mismatched socks.
Redirecting www to Non-www: Or maybe you’re a minimalist and prefer the sleek, no-frills as your primary URL. In that case, you’ll be redirecting everything from to . Just like ditching that unnecessary “www” clutter.

2. Domain Consolidation

Merging Multiple Domains: Got a handful of domains (e.g., , )? It’s like trying to herd cats. Consolidate them by redirecting all traffic to a single domain ( ), so everything points in the same direction. It’s domain feng shui.
Rebranding: Changing your domain from to ? Redirect the old root domain to the new one to keep all your loyal visitors (and your SEO rankings) in tow. Think of it like forwarding your mail after moving to a fancy new digital address.

3. SEO and Duplicate Content

Avoiding Duplicate Content: Google frowns upon duplicate content like a librarian shushing a noisy visitor. To avoid penalties, you’ll want to redirect all traffic to a single canonical URL (e.g., redirects to ). Because let’s be honest, duplicate content is just unnecessary noise.
Maintaining SEO Rankings: Migrating to a new domain? Redirect the old root domain to the new one, and watch as your hard-earned SEO rankings follow you to your shiny new home. It’s like changing the address on your business card but with way more techy jargon involved.

4. Traffic Management

Temporary Redirects During Maintenance: Sometimes your website needs a little TLC. Set up a temporary redirect to a maintenance page ( ) so your visitors know you haven’t vanished into the digital abyss.
Redirecting to a Regional or Language-Specific Site: Got a global audience? Redirect users from the root domain to region-specific sites ( to for U.S. visitors). It’s like rolling out the red carpet, tailored to each visitor.

5. Domain Migration

Moving to a New TLD: Making the leap from .com to .dev? Redirect the old domain ( ) to the new one ( ), and keep everyone on the right track. Think of it as leaving breadcrumbs for your visitors to follow.
Transition from a Development or Staging Environment: Your site is graduating from staging ( ) to production! Redirect the root domain to ensure all traffic flows to your up-to-date masterpiece.

6. Preventing Domain Squatting

Protecting a Brand: Own multiple variations of your domain to protect your brand? Redirect those variations to the main site to prevent confusion and keep domain squatters at bay. Because nobody likes a digital trespasser.

7. Simple URL Forwarding

Redirecting to a Social Media Profile: Not quite ready for a full website? Redirect your root domain to a social media profile ( to ). It’s like handing out your business card, but online.
Redirecting to a Third-Party Service: If your domain is just a gateway to another service (e.g., a blog hosted on Medium or a store on Shopify), redirect it there ( to ). Because who said you need to build everything from scratch?

8. Dealing with Expired Services

Redirecting After Expiring or Discontinuing a Service: If a service or site is no more, its root domain can be redirected to another service or a page explaining the change. It’s like leaving a “We’ve Moved” sign up for your digital neighbors.

Step-by-Step Guide to Redirect a Root Domain Using Cloudflare

Alright, enough scenarios. Let’s get down to business and set up that redirect!

1. Log in to Cloudflare

First things first, log in to your .

2. Select Your Domain

From your list of domains, click on the one you want to redirect.

3. Set Up DNS Records

To make sure traffic to flows smoothly through Cloudflare, set up these DNS records:

Root Domain A Record ( ):
- Type: A
- Name: @
- IPv4 Address: 192.0.2.1 (Just a placeholder, doesn’t actually matter)
- TTL: Auto
- Proxy status: Proxied (Orange Cloud)
www Subdomain A Record ( ):
- Type: A
- Name: www
- IPv4 Address: Same as above (192.0.2.1)
- TTL: Auto
- Proxy status: Proxied (Orange Cloud)

Pro Tip: Prefer a CNAME? No problem. Use this instead:

CNAME Record for Root Domain:
- Type: CNAME
- Name: @
- Target:
- TTL: Auto
- Proxy status: Proxied (Orange Cloud)

4. Create a Page Rule for the Redirect

Now for the fun part: setting up the Page Rule to actually do the redirecting.

In your domain’s dashboard, head over to Page Rules.
Click Create Page Rule.
In the “If the URL matches” field, enter (This little wildcard * will capture everything after the root domain).
Under “Then the settings are”, select Forwarding URL.
Choose your redirect type:
- 301 - Permanent Redirect: This is your “Forever” option.
- 302 - Temporary Redirect: Just temporary? Use this.
In the “Enter destination URL” field, type the URL you want to send folks to, like
1. The $1 is the bit that keeps all your existing links like example.com/some/path working. In short it keeps your old paths intact.
Click Save and Deploy.

5. Test the Redirect

Now’s the moment of truth. Go to in your browser and make sure you land at or wherever you’ve decided to send your traffic. If it works, give yourself a high-five—you’ve just mastered DNS redirection like a pro.

To redirect both and example.com to newdomain.com, you need to create a separate page rule for each address.

Summary Example Configuration

Here’s a quick recap of what you’ve just done:

DNS Settings:
- A Record: @ → 192.0.2.1 (Proxied)
- A Record: www → 192.0.2.1 (Proxied)
Page Rule:
- URL Pattern:
- Setting: Forwarding URL → (301 - Permanent Redirect)

Congrats! By following these steps, you’ve ensured that your root domain is successfully redirected using Cloudflare’s DNS and Page Rules features. Go forth and redirect with confidence—because when it comes to DNS, you’re now in the driver’s seat!

Key Takeaways

You can redirect a root domain with Cloudflare using Page Rules (or DNS with a CNAME at the root, since root-level CNAMEs aren’t always supported)
Set up an A record for @ pointing to a placeholder IP, enable proxy (orange cloud), then create a Page Rule to forward the URL to your target domain
The $1 placeholder in the forwarding URL preserves the original path—so /about becomes example.com/about instead of dropping to the root
You need separate rules for each domain. If you’re redirecting example.com and www.example.com to the same place, create two rules with each source domain
Cloudflare’s pricing determines rule counts: Free tier gets 3 Page Rules, Pro gets 20, Business gets unlimited

— another Cloudflare integration, this time for routing traffic through tunnels
— infrastructure that benefits from proper DNS and domain management

All-in-One Unraid HomeLab Server

Fri, 26 Jul 2024 00:00:00 +0000

Overview

I have tried a ton of different HomeLab configurations and setups of all types of hardware. But this one is my personally preferred solution for its versatility, reliability, and proven battle-tested track record. Built from gaming PC hardware, it’s an extremely powerful HomeLab that can fit many different needs and is highly customizable. Whether you’re a tech enthusiast, a developer, or someone looking to consolidate multiple functions into a single machine, this Unraid HomeLab server offers a robust and flexible solution.

![]( align=“center”)

Hardware Specs

Components	Part Links
Operating System (OS)
Case
Fans
Motherboard	Gigabyte X470 AORUS ULTRA GAMING-CF
PSU
CPU
CPU Cooler
RAM - 64 GB Total
Storage NVMe - Docker and NAS writes
Storage NVMe - Gaming VM
Storage SSD - Lab VMs
Storage HDD - NAS Array - 64 TB Total
GPU 1 - Gaming VM
GPU 2 - AI Models and Video Transcoding

Key Features

Easy Setup and Management

Unraid OS makes setting up and managing your server a breeze with its user-friendly web interface. Even if you’re not a tech wizard, you’ll find it easy to navigate and configure your server thanks to its intuitive design. From the moment you start the installation to your everyday tasks, the interface guides you step-by-step, taking the hassle out of server management.

Everything you need, like setting up storage, creating virtual machines, and managing Docker containers, is right there in the web interface. No need to mess with complicated command lines. Plus, the dashboard gives you a real-time snapshot of your system’s performance, resource usage, and storage health, so you always know what’s going on.

Flexible Storage Options

Supports a mix of different drive sizes and types, allowing for easy expansion and customization. Not all drives have to be the same size. The parity drives just must be the largest ones. This really allows a huge amount of flexibility and a great place to use random old hard drives laying around if you can fit them. Saving costs and reducing electronic waste at the same time.

Data Protection

Provides robust data protection with parity-based redundancy, ensuring data integrity even if a drive fails. With multiple parity drives, you can have multiple disk failures at once. But even with a single parity drive, I have had multiple disks fail on me. Even when waiting on a warranty disk. The system will emulate the data from the failed drive until you are able to get a replacement drive reinstalled. I cannot stress how important this is and how much peace of mind you get when you know even if a drive fails, it’s no big deal and it will be perfectly fine. I have yet to lose any data due to disk failures 5+ years later.

Virtualization

Allows you to run multiple virtual machines (VMs) simultaneously, making it ideal for testing and development environments. The hypervisor capabilities are highly functional and work great for lab experimentations or a few production VMs. I have a gaming VM that performs amazingly with hardware pass-thru on the GPU and NVMe Storage too. For more complex VM clusters of servers, I would recommend Proxmox running on a Xeon CPU enterprise server as a much better solution. See my article on the Enterprise HomeLab Server Cluster and Rack I built.

Docker Support

Seamlessly integrates with Docker, enabling you to run a wide range of containerized applications.

Community App Store

Although unofficial, this is a searchable template database for all sorts of applications that run using Docker containers. This makes deploying self-hosted services and even your own custom Docker-based applications a breeze. With a highly active and helpful community behind them, the App Store is what makes Unraid stand out with the simple ease of use and updates by the community.

Efficient Resource Utilization

Optimizes the use of hardware resources, ensuring efficient performance. Advanced capabilities such as CPU pinning are available for use with VMs and Docker from directly within the UI and are beyond simple to use. I have not seen a better implementation of this feature on any other hypervisor I have worked with.

Scalability

Easily scalable to accommodate growing storage needs without requiring a complete system overhaul. Have a few extra hard drives laying around or need to upgrade an existing one? It is as simple as installing the new drives and doing some simple drop-down menu configuration via the GUI. I’ve never had an easier time working with storage arrays ever. It’s so easy it actually seems too easy.

Community Support

Backed by a strong community of users and developers, providing extensive resources and support. The community is great to be a part of and everyone is always helpful. Never a bad experience.

Plugin System

Offers a wide range of plugins to extend functionality, from media servers to backup solutions. The plugins are what make Unraid so awesome and sometimes they even get put into the OS itself.

Low Power Consumption

Designed to be energy-efficient, reducing overall power consumption. It only uses the power it needs and will even spin down drives that are not in use after a certain amount of time which is configurable as well.

Hardware Compatibility

Compatible with a wide range of hardware, including consumer-grade components. I’ve never had a component or item not at least generally work right out of the box. Support is very broad for most hardware.

Data Recovery

Features robust data recovery options, minimizing the risk of data loss. As well as having a highly resilient storage array system using parity disks to maintain data integrity even during a failure by failing over and emulating the data it cannot access at the time. It simply never skips a beat.

Network Attached Storage (NAS)

Functions as a powerful NAS, supporting NFS and SMB file shares.

Media Server Capabilities

Ideal for setting up media servers like Plex or Jellyfin, with hardware pass-thru for optimal performance. Including tools and software through the community App Store that can be used to automatically re-encode your media to save space as well.

Automated Backups

Supports automated backups, ensuring your data is always protected. Via 3rd party plugins, it will back up your Docker volumes and container configurations automatically based on a schedule you create. As well as rotate and maintain the number of backups you want to keep.

Cost-Effective

Allows the use of existing hardware, reducing the need for expensive enterprise solutions. You can build a very capable system out of an old PC or a few older PCs that you then combine together. The part mix and match is unbeatable and you can swap things around anytime you want with very little effort or reconfiguration if at all.

Customizable

Highly customizable to fit specific needs and preferences. It’s your own playground. The broad part compatibility gives you almost unlimited amounts of different builds and configurations you can have.

Remote Access

Unraid provides options for remote access to the server GUI itself, making it easy to manage your server from anywhere. You can use Cloudflare Zero Trust tunnels to do this too since you will most likely have other services you will want to access remotely.

Security

Includes various security features to protect your data and network. Please be sure to follow best standard security practices for any system you put your personal data onto.

Performance Monitoring

Offers tools for monitoring system performance and resource usage. 3rd party plugins are available to help you monitor your GPU’s and hardware thermals as well.

Multi-User Support

Allows multiple users to access and use the system simultaneously.

Simplifies file sharing across different devices and platforms. Managing user access to SMB or NFS shares is extremely easy and simple to set up all through the GUI.

Backup Solutions

Integrates with various backup solutions to ensure data safety. There are many ways to sync your OneDrive, Google, or iCloud storage as well as host your own private cloud storage solutions.

Software Updates

Regular updates and patches to keep the system secure and up-to-date.

Usage and Ideas

Gaming VM

Unraid’s virtualization capabilities allow you to run a high-performance gaming VM. With hardware pass-thru for the GPU and NVMe storage, you can achieve near-native gaming performance. This setup is ideal for those who want to consolidate their gaming and server needs into a single machine.

Labs

Unraid is perfect for setting up lab environments for testing and development. Its support for multiple VMs and Docker containers makes it easy to create isolated environments for different projects. Whether you’re experimenting with new software, testing configurations, or developing applications, Unraid provides a flexible and powerful platform.

Storage and Backups

Unraid excels in providing robust storage solutions. With its flexible storage options, you can mix and match different drive sizes and types. The system’s parity-based redundancy ensures data integrity, even if a drive fails. Automated backups and data recovery options further enhance the reliability of your storage setup.

Media Server

Unraid is an excellent choice for setting up a media server. With support for applications like Plex and Jellyfin, you can easily stream your media collection to various devices. Hardware pass-thru ensures optimal performance, and the community App Store offers tools to automatically re-encode media to save space.

Personal Experiences

This build and setup not only is used by my entire family and extended family 24/7 for its media server, self-hosted AI Chatbots, and data backup capabilities. It really is production and in use by many people at all times. It also runs critical services like my Unifi network controller for all of my networking equipment. And non-critical services and VMs for all of my development and lab environments. Even a Gaming VM for when I want to relax a little between projects. And some would say, including myself before. Are you crazy!? That’s a single point of failure! It is but I can say after many years of using and maintaining this system. And trying many more others including more distributed setups. It is by far the most reliable and stable that I have ever built. Even after hardware failures and many different configurations I have gone through. It’s rock solid. It’s friendly and approachable by tech enthusiasts for general-purpose needs and beyond customizable for the hardcore tinkers and developers. Give it a try and if you want to share your own setup or story please leave a comment!

Key Takeaways

Unraid’s parity-based storage lets you mix drive sizes and survive drive failures without data loss — a practical advantage over traditional RAID.
The community app store turns Docker deployment into a template-based process, removing the manual configuration overhead.
For a single-server homelab that handles VMs, Docker, storage, and media in one box, Unraid hits the sweet spot between ease of use and capability.
If you need a large VM cluster, Proxmox on enterprise hardware is a better fit. Unraid excels at the all-in-one solo build.

Useful Resources

Some links are affiliate links that help support me to create this content.

— how AI infrastructure layers on top of this homelab
— manage access to your infrastructure without typing full hostnames every time

Streamlining SSH Connections: A Quick Guide

Sat, 08 Apr 2023 00:00:00 +0000

Maximizing efficiency in our daily tasks is a shared goal among developers. When it comes to SSH connections, wouldn’t it be great to reduce this…

ssh -i /path/to/your/keyfile

…to simply this?

ssh Server1

Today, I’m sharing a quick guide on how to set default values for host, user, and key file in your SSH connections.

Pro Tip: You can use these in VSCode or your favorite JetBrains IDE too!

Configuring the SSH Config File

The default path to the SSH config file is ~/.ssh/config. Let’s explore how to set it up:

# Set Default User for All Hosts
Host *
 User your_user

# Set Default User, HostName, and Key File
# You don't have to use a keyfile aka SSH Key, just comment it out
Host name-to-use # Name you want to use - ssh Host
 HostName 10.10.10.10 # The IP address or FQDN of the destination server
 # HostName servername.domain.com
 IdentityFile /path/to/your/key/KeyFile.pem # Key File
 User your_user # Default User

By implementing these configurations, you can make your SSH connections more efficient and easier to manage. This approach is especially useful when you’re frequently connecting to the same servers or clusters.

Remember, efficiency is key in any development environment. I hope this guide proves useful in your daily tasks. Do you have more tips to streamline SSH connections? Feel free to share in the comments!

Key Takeaways

An SSH config file at ~/.ssh/config lets you define aliases, default users, and key paths so you can connect with ssh Server1 instead of typing full hostnames and key paths every time
Setting a wildcard Host * block establishes defaults for all connections, reducing repetition when you frequently use the same user or key
The config works with VSCode Remote-SSH and JetBrains IDEs — whatever tool you use to connect, it reads the same config file

— SSH config is useful; combined with Docker remote hosts, your workflow compresses even further
— the infrastructure you’ll need to SSH into

Setting up Cloud Init Ubuntu Image on Proxmox

Sat, 15 Oct 2022 00:00:00 +0000

This post shows a compact, repeatable flow for creating a Cloud-Init based Ubuntu template in Proxmox so you can spin up configured VMs quickly.

Quick run: download an Ubuntu cloud image, import it into Proxmox, add a Cloud-Init drive, set boot order, convert to a template, then clone.

You will need:

A Proxmox VE host with LVM (or other writable storage like local-lvm)
SSH or shell access to your Proxmox host
A public SSH key (for injecting into cloud-init)

Quick checklist

Download cloud image
Create a small VM (temporary)
Import disk, attach to VM
Add cloud-init drive and configure user/ssh
Convert VM to template
Clone when needed

Step-by-step

1) Download the Ubuntu cloud image

Choose the release you prefer and download the cloud image. Example (Focal):

wget https://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64.img

2) Create a temporary VM to attach the image to

Adjust memory and CPU to taste — this VM will become the template.

qm create 8000 --memory 2048 --core 2 --name ubuntu-cloud --net0 virtio,bridge=vmbr0

3) Import the cloud image into storage

Import the downloaded image into a Proxmox storage pool (example uses local-lvm):

qm importdisk 8000 focal-server-cloudimg-amd64.img local-lvm

4) Attach the imported disk to the VM (SCSI recommended)

qm set 8000 --scsihw virtio-scsi-pci --scsi0 local-lvm:vm-8000-disk-0

5) Add the Cloud-Init drive

qm set 8000 --ide2 local-lvm:cloudinit

6) Make the VM boot from the disk

qm set 8000 --boot c --bootdisk scsi0

7) Add a serial console (optional, helpful for headless debugging)

qm set 8000 --serial0 socket --vga serial0

Don’t Start Yet

Warning — do not start the VM yet. Configure cloud-init and hardware first. Starting too early can record IDs/state you may not want in your template.

8) Configure Cloud-Init fields (hostname, user, SSH key)

You can set these with the GUI or via qm set. Example CLI:

qm set 8000 --ciuser ubuntu --sshkey "$(cat ~/.ssh/id_rsa.pub)"
qm set 8000 --citype nocloud

If you want to provide a full user-data/meta-data payload for NoCloud, you can supply files or use Proxmox GUI fields.

9) Convert the VM to a template

qm template 8000

10) Clone the template whenever you need a new VM

qm clone 8000 135 --name yoshi

Tips

Resize disks after cloning if you need per-VM different sizes; keep the template small.
Put idempotent provisioning (Ansible, cloud-init modules) in the guest rather than baking many steps into the template.

Troubleshooting

If you accidentally booted a template (or need a fresh machine-id inside a guest):

sudo rm -f /etc/machine-id
sudo rm -f /var/lib/dbus/machine-id

Shutdown the VM and do not boot it; a new id will be generated on next boot. If it’s not generated automatically, run:

sudo systemd-machine-id-setup

If cloud-init doesn’t apply after cloning, verify the cloud-init datasource type and that Proxmox’s cloud-init fields are populated correctly for the new host.

Key Takeaways

Cloud-init templates save hours per VM when you deploy regularly
Never start a VM before configuring cloud-init — booting early bakes state into the template
Keep the template minimal; use idempotent provisioning (Ansible, cloud-init modules) for post-clone customization
Always use SCSI for the imported disk for performance
Reset machine-id after cloning if cloud-init doesn’t apply correctly

— tools and scripts for VM management, backups, and automation on Proxmox
— managing credentials homelab automation without scattered secrets

Maximizing Efficiency in IT: Simplifying Software and Infrastructure Development

Sat, 09 Apr 2022 00:00:00 +0000

In my years of crafting software, networks, and infrastructure, I’ve learned a key lesson: more features don’t always mean better functionality. Often, loading a system with too many extras leads to more problems than solutions. A system crammed with features can become a maze, where finding the cause of a problem is like searching for a needle in a haystack. This overcomplexity turns maintenance into a nightmare task, like trying to navigate a thick forest without a compass. If you ever have experienced this, you know the importance of simplicity and area focus in system design.

The Farm: A Lesson in Digital Simplicity

Envision your IT infrastructure as a lively, diverse farm. Each device is akin to a different animal, each with its unique requirements. As the farmer in this technology landscape, your tasks are multifaceted: nurturing your digital livestock, managing expenses efficiently, ensuring smooth functionality, and protecting against cyber threats. This metaphor highlights the day to day life of upholding a solid and secure IT environment. I often reflect on a saying: “It’s hard to see the forest when you’re amongst the trees.” This is a valuable reminder in our context. Rather than fixating on adding tons of features into a single project, it’s crucial to step back and embrace simplicity. It’s ok to focus in problem branches of a single tree but always remember to look at the forest and don’t get lost in the trees.

![]( align=“center”)

Case Study: Betsy, the Prized Product

Meet Betsy, the star and latest addition to our IT farm. She’s your crown jewel, be it a sleek software, a robust server, a seamless network, or a well-oiled DevOps pipeline. You’ve invested blood, sweat, and maybe a few tears into perfecting Betsy. Now, it’s all about keeping her producing and pleasing everyone. Sure, you’re tempted to deck her out with the latest features and fix every tiny bug, all while keeping a keen eye on her performance. But beware - every new bell adds a new layer of complexity. Resulting in even more monitors and alerts that turn a small problem into a high-tech hide and seek. Save yourself some stress and time. Stick to essential enhancements and simplicity, where less could actually mean more. Remember Betsy above. Does she really need all of those bells to provide an awesome product?

Managing Your IT Farm: A Balanced Approach

Imagine your IT infrastructure as a complex farm, where each component is a unique animal with specific needs. As the caretaker in this digital ecosystem, your role is to ensure every element is well-maintained and secure from potential threats, much like a farmer tending to diverse livestock. In the current landscape of rapidly evolving cloud-based solutions, choosing which tools and services are essential and which are superfluous can be challenging. It’s about striking a balance between enriching your infrastructure and being selective with the resources at your disposal, ensuring a stable and efficient operational environment. It’s a lot of work! Don’t make it harder on yourself with extra work that is not truly needed.

Adopting the 80/20 Rule and YAGNI

Regardless of your project’s stage, be it greenfield (starting from scratch) or brownfield (upgrading existing systems), two guiding principles can streamline your approach: the 80/20 rule and “YAGNI” (You Ain’t Gonna Need It). The 80/20 rule suggests concentrating on the vital 20% of tasks that deliver 80% of the results. Simultaneously, the YAGNI principle advocates for a minimalistic initial design, adding features only when they become necessary. This strategy enables quicker progression to the iteration phase, letting you make adjustments informed by practical feedback. Imagine trying to design and build your whole farm before you even know what problems you will face. What if no one even likes cows at all and they wanted chickens instead! O Geez! Now you have a whole system and area of your farm dedicated to something no one needs or wants. But no matter how much you plan and research, sometimes this does happen.

Adapting to the Unpredictable

It’s crucial to remember that you don’t know what you don’t know - there’s always going to be something unexpected that comes up. Being able to adapt your solution and make tweaks based on these unexpected challenges is key. And if the system simply doesn’t work, it’s even better that you didn’t waste more time on that solution! Don’t feel defeated though. Failure can be disguised as clarity to the solution and actually progress instead of a set back. Even a step back can be 2 steps forward if you pay attention to your footing.

The Virtue of Simplicity

Remember, you don’t need to use every feature or monitoring alarm. Overloading a design with features complicates maintenance and troubleshooting. Simplicity and efficiency often outperform complexity and over-engineering. Finally, managing costs and efficiently utilizing resources is key in building software, networks and infrastructure. Stay open to iteration and adaptation, and you’ll be well on your way to building robust, efficient, and manageable systems.

Top 5 Tips for Streamlining Your IT Projects

** MVP First**: Start with a Minimal Viable Product. Focus on core features that meet basic needs, then expand later.
** Regular Reviews**: Periodically evaluate your systems. Simplify or remove unnecessary components.
Cost Efficiency & Resource Management: Prioritize efficient cost control and smart resource utilization.
80/20 Rule & YAGNI: Focus on the essential 20% of features that meet 80% of needs, and embrace “YAGNI” (You Ain’t Gonna Need It) to avoid unnecessary complexities.
** Feedback and Adaptation**: Regularly seek and act on feedback. Stay agile and ready to make changes for continuous improvement.

Key Takeaways

Complexity is a maintenance burden — the simpler the system, the easier it is to fix when things break
Ship an MVP, get real feedback, then iterate; planning every detail up front wastes time on features nobody needs
The 80/20 rule and YAGNI are discipline, not buzzwords: focus on the 20% of features that deliver 80% of value, and skip what you don’t need yet
Costs and resources compound with every added component — monitoring, alerting, and operational overhead grow with feature count

— applies the same prioritization thinking to productivity and life decisions
— another practical approach to keeping things simple and focused

Homelab & Infrastructure | Derek Armstrong — Software Engineer · AI · Infrastructure

Self-Hosting Plausible Analytics with Podman and Cloudflare Tunnels

The Stack

Podman Quirks on Rocky Linux

The Setup

Integration with Hugo

Privacy First

Backing Up

Running It

What I Learned

Key Takeaways

Next

The Proxmox Utility Toolkit: Stop Cloning That VM by Hand

What the Repository Actually Is

VM Templates and Cloning

Backups You’ll Actually Verify

GPU Passthrough Without the Three-Hour Research Session

Kubernetes on Top of Proxmox

Security Worth Taking Seriously

Automation: Ansible, Terraform, and API Access

Learning Paths: There’s an On-Ramp for Everyone

Getting Started

Key Takeaways

Next

Nagios: A 10-Year Retrospective on Infrastructure Monitoring

The Strategic Validation Approach

Production Deployment: Transforming IT Operations

Architecture and Scale

Business Impact: From Reactive to Proactive

Quick Personal Setup

Purpose and Architecture

Key Benefits

Free Tiers / Editions

When to Choose Nagios

When Not to Choose Nagios

Industries Where Nagios Shines

Industries Where It Struggles

Quick Pros & Cons

Alternatives and Comparison

Quick Pick Guide

Architectural Lessons Learned

Final Thought

Key Takeaways

Next

Podman Cheat Sheet

Start and Stop Containers

Build an Image

Run a Container

Remove Containers and Images

Podman Compose (if using podman-compose)

Additional Useful Commands

Inspect

Logs

List Containers and Images

Key Takeaways

Next

Gitea: Git on Your Own Terms

Why Gitea? The Little Git Server That Could

The Pros: Why You’d Want Your Own Git Fortress

Data Sovereignty: Your Code, Your Rules

Mirror, Mirror on the Wall, Who Has the Most Repos of All?

Unrestricted Runner Minutes: CI/CD without the Meter Running

Offline Access: Because Internet Outages Are a Thing

Unlimited Private Repositories

The Cons: The Price of Freedom

Maintenance: You Break It, You Fix It

Backups: Don’t Be That Person

Security: With Great Power Comes Great Responsibility

Protecting Your Code Castle

Setting Sail with Docker Compose

Customization: Making It Your Own

Backup Strategies: Because Stuff Happens

Conclusion: To Git or Not to Git?

References

Key Takeaways

Next

Dev Magic with Docker

So, What’s Docker?

Why Do Developers Love Docker?

1. It’s Lightweight, Like REALLY Lightweight

Podman Compose (if using `podman-compose`)

But Wait… There’s More