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.*