Create Blog “inside-my-proxmox-lab-a-practical-self-hosted-environment”
This commit is contained in:
@@ -0,0 +1,236 @@
|
||||
---
|
||||
title: "Inside My Proxmox Lab: A Practical Self-Hosted Environment"
|
||||
date: 2025-12-16T10:27:00.000-06:00
|
||||
description: A look at my Proxmox-based home lab, what I’m running, and what I’m
|
||||
learning by building and breaking real systems.
|
||||
draft: false
|
||||
---
|
||||
### Why I Built This Lab
|
||||
|
||||
|
||||
|
||||
Over the years, I’ve learned that the best way to truly understand infrastructure is to \*\*build it yourself\*\*, operate it, and occasionally break it. Documentation and diagrams are helpful, but nothing replaces the lessons learned from running real services under real constraints.
|
||||
|
||||
|
||||
|
||||
This Proxmox environment is my personal lab — a place to experiment, learn, and refine how modern infrastructure fits together.
|
||||
|
||||
|
||||
|
||||
It’s not meant to be perfect. It’s meant to be \*useful\*.
|
||||
|
||||
|
||||
|
||||
\---
|
||||
|
||||
|
||||
|
||||
### The Foundation: Proxmox VE
|
||||
|
||||
|
||||
|
||||
At the core of this setup is \*\*Proxmox VE\*\*, which I use to manage virtual machines and containers. Proxmox gives me the flexibility to:
|
||||
|
||||
|
||||
|
||||
\- Run multiple isolated workloads
|
||||
|
||||
\- Snapshot before risky changes
|
||||
|
||||
\- Allocate resources intentionally
|
||||
|
||||
\- Treat infrastructure as something I can iterate on
|
||||
|
||||
|
||||
|
||||
Everything else in this lab builds on top of that foundation.
|
||||
|
||||
|
||||
|
||||
\---
|
||||
|
||||
|
||||
|
||||
### Core Services I’m Running
|
||||
|
||||
|
||||
|
||||
#### Git & Source Control (Gitea)
|
||||
|
||||
|
||||
|
||||
I run a self-hosted \*\*Gitea\*\* instance for source control. This powers:
|
||||
|
||||
|
||||
|
||||
\- Version control for my websites and projects
|
||||
|
||||
\- Authentication for Decap CMS
|
||||
|
||||
\- A private, self-contained development workflow
|
||||
|
||||
|
||||
|
||||
Hosting my own Git server forces me to think about identity, access, TLS, and availability in ways that cloud-hosted Git never exposes.
|
||||
|
||||
|
||||
|
||||
\---
|
||||
|
||||
|
||||
|
||||
#### This Website: seans.cloud
|
||||
|
||||
|
||||
|
||||
This site is built with \*\*Astro\*\* and intentionally kept simple. It serves as:
|
||||
|
||||
|
||||
|
||||
\- A place to document what I’m learning
|
||||
|
||||
\- A long-term knowledge archive
|
||||
|
||||
\- A testing ground for ideas before they become something bigger
|
||||
|
||||
|
||||
|
||||
Content is written in Markdown and managed through Decap CMS, which commits directly to Gitea. That means everything here is versioned, reviewable, and reproducible.
|
||||
|
||||
|
||||
|
||||
\---
|
||||
|
||||
|
||||
|
||||
Browser-Based Editing with Decap CMS
|
||||
|
||||
|
||||
|
||||
One of my goals was to make writing frictionless. With \*\*Decap CMS\*\*, I can:
|
||||
|
||||
|
||||
|
||||
\- Write blog posts from a browser
|
||||
|
||||
\- Save drafts without publishing
|
||||
|
||||
\- Commit content directly to Git
|
||||
|
||||
\- Let the site build itself
|
||||
|
||||
|
||||
|
||||
This setup blends the convenience of a traditional CMS with the reliability of Git-based workflows.
|
||||
|
||||
|
||||
|
||||
\---
|
||||
|
||||
|
||||
|
||||
#### Media & Personal Services
|
||||
|
||||
|
||||
|
||||
Alongside the “serious” infrastructure, I also run services that support daily life and experimentation:
|
||||
|
||||
|
||||
|
||||
\- \*\*Jellyfin\*\* for personal media streaming
|
||||
|
||||
\- A \*\*Minecraft server\*\* for shared worlds and tinkering
|
||||
|
||||
\- Supporting services behind a reverse proxy with TLS
|
||||
|
||||
|
||||
|
||||
These services might seem unrelated, but they provide real traffic patterns, real users, and real failure modes — which makes them excellent learning tools.
|
||||
|
||||
|
||||
|
||||
\---
|
||||
|
||||
|
||||
|
||||
### Networking & Access
|
||||
|
||||
|
||||
|
||||
I rely on a layered approach to access and security:
|
||||
|
||||
|
||||
|
||||
\- Reverse proxying with TLS
|
||||
|
||||
\- Internal-only services where possible
|
||||
|
||||
\- Controlled exposure of public endpoints
|
||||
|
||||
\- Clear separation between management and user-facing services
|
||||
|
||||
|
||||
|
||||
Debugging OAuth flows, certificates, and proxy behavior has been one of the most educational parts of this lab.
|
||||
|
||||
|
||||
|
||||
\---
|
||||
|
||||
|
||||
|
||||
### What This Lab Teaches Me
|
||||
|
||||
|
||||
|
||||
This environment constantly reinforces a few core lessons:
|
||||
|
||||
|
||||
|
||||
\- \*\*Small decisions compound quickly\*\*
|
||||
|
||||
\- \*\*Security is a system, not a feature\*\*
|
||||
|
||||
\- \*\*Documentation matters — especially your own\*\*
|
||||
|
||||
\- \*\*Operational simplicity beats cleverness\*\*
|
||||
|
||||
|
||||
|
||||
Running your own infrastructure forces you to think holistically: networking, identity, storage, automation, and human workflows all intersect.
|
||||
|
||||
|
||||
|
||||
\---
|
||||
|
||||
### What’s Next
|
||||
|
||||
|
||||
|
||||
This lab will continue to evolve. Some things I’m actively working toward:
|
||||
|
||||
|
||||
|
||||
\- More automation and infrastructure-as-code
|
||||
|
||||
\- Better observability and logging
|
||||
|
||||
\- Expanding content and experiments on this site
|
||||
|
||||
\- Turning lessons learned into reusable patterns
|
||||
|
||||
|
||||
|
||||
This site — and this lab — are living systems. They exist to support learning, reflection, and growth.
|
||||
|
||||
|
||||
|
||||
If you’re building something similar, I hope this gives you ideas — or at least reassurance that imperfect systems are still incredibly valuable teachers.
|
||||
|
||||
|
||||
|
||||
\---
|
||||
|
||||
|
||||
|
||||
\*Thanks for reading. More experiments to come.\*
|
||||
Reference in New Issue
Block a user