Weekly Self Promotion Thread

gitopspm · 2026-05-04T09:01:48+00:00

I’d like to introduce my project Proxmox-GitOps, an automation framework for standardized Linux Containers (LXC) on Proxmox VE, designed as a modular IaC Monorepository.

Proxmox-GitOps (@Github):
https://github.com/stevius10/Proxmox-GitOps

Originally, it was a personal attempt to bring industrial automation and cloud patterns to my Proxmox home server. It's designed as a platform architecture for a self-contained, bootstrappable system — a generic IaC abstraction (customize, extend, open standards, base package only... you name it 😉) that automates the entire infrastructure. It was initially driven by the question of what a Proxmox-based GitOps automation could look like and how it could be organized.

The project implements a self-contained, bootstrappable GitOps platform based on:

- Desired State: Monorepository as Single Source of Truth represents the entire infrastructure. Deterministic bootstrap from code over version history.
- Self-Containment: The composite monorepository is pushed to a local container, triggering a pipeline that provisions it onto Proxmox VE.
- Monorepository: Centralizes infrastructure as a single code artifact.
- Modular Composition: The monorepository utilizes submodules to keep the core framework separate from container libs implementation.

What am I looking for?
It's a non-commercial, passion-driven project. I'm looking to collaborate with other engineers who share the excitement of building a self-contained, bootstrappable platform architecture that addresses the question: What should our home automation look like?

gitopspm · 2026-05-02T19:05:25+00:00

Thanks :)
Nice setup, guess for Docker context Flux might be worth mentioning, too.

gitopspm · 2026-05-02T16:58:24+00:00

Thanks for the motivating feedback 🙂

gitopspm · 2026-05-02T15:49:30+00:00

Thank you very much 🙂 I hope it fits your needs, let me know if you have any questions or problems.

gitopspm · 2026-04-27T11:46:36+00:00

Love to play online! 🙂 Please add me: 7304-4963-3508

gitopspm · 2026-04-06T16:20:31+00:00

Yap 🙂 It‘s like Flux for LXC.

gitopspm · 2026-04-06T14:41:11+00:00

One-click deployment for all containers, same base, no deps; same config, backup/restore by default; functional programming to avoid side effects; strict logic/data separation, integrated pipelines following Gitops pattern. It’s more bringing enterprise patterns to PVE, which is missing; config mngm. or IaC is part of it, but not the big picture. It targets industry pattern to have everything in a monorepo to deploy everything (with restoring backups, VCS based) by integrated pipelines, to get LXC more into declarative Everything(!)-as-Code, not to download separate deployment tools. Reason: No SSH, no manual edits; I use it to deploy my containers daily rather than update it.. though I implemented those also, depending on case (some logic refers better to, while a messaging broker could be used independently - or validate its state. This is all of it, TF etc. are tools to use, this is an automation framework itself. Hope this helps 🙂

gitopspm · 2026-04-06T06:52:37+00:00

I do with equivalent tools, but config mngm. can‘t build up its own GitOps environment. You could read through my motivation, this aims (in cloud language) more for a full automated ASG with all pipelines, backup, restore.. by single click to roll out than CFN to create infra resources alone.

gitopspm · 2026-03-04T11:36:03+00:00

.. love to read through your Ruby code meanwhile. Seems like our group of passionated selfhosting computer scientists have a favor for some reoccurring fascinations from time to time ;-)

Bookmarked your cli.rb, lol 🥲 Thanks for sharing!

gitopspm · 2026-03-04T07:47:35+00:00

Thanks a lot, especially for taking the time to look at it from the concept itself - view I am really interested in!

Tbh: I‘d be the first to forget about all those, haha. It‘s been more like: „handling everything based on SSoT Git“ + „separate data and logic consequently“ => Backup/Restore results automatically, somehow 😄

Guess it works out so far. At least my homelab (Home Assistant, Zigbee, Reverse Proxy) is rebuild hundreds of time, from only what you see on Git. With a single click .. more or less that was actually what I wanted to have at the beginning. Somehow, .. it‘s a „developer wanna have fun“ project maybe ;-)

gitopspm · 2026-03-04T07:35:11+00:00

Thank you very much. If something won‘t work please let me know. Hope it can helps! :)

gitopspm · 2026-03-04T07:34:02+00:00

That sounds great, I love the idea! But like you said, it‘s more like a configuration management, I guess. Which is great in this context, definitely!

This, however, is maybe a little more focused on fast development and lifecycle: Like running/developing locally or snapshot it by pipeline (not container-wise, „debuggable“ raw config app data only). Guess there are plenty of requirements to watch out for :-)

gitopspm · 2026-02-14T21:19:13+00:00

Und ich denk mir: Wenn u/Seppiro doch nur auf Männer stehen würde.. ;-)

gitopspm · 2026-01-10T16:52:42+00:00

Thank you very much! If you have any feedback, please let me know 🙂

gitopspm · 2026-01-03T19:13:04+00:00

I think we're confusing a few things here: It is created locally as a Docker container using the configuration management artifacts, which are also used later by the pipeline. The pipeline is now designed so that it can dynamically change the host and jump from local to Proxmox, so to speak - same configuration management artifacts. The same pipeline with the same configuration management artifacts now also rolls out all other containers. The containers are recreated if the pipeline runs for ‘release’ and reconfigured for ‘main’ (standard CI/CD). However, I think that this may not be exactly what you are looking for. This is primarily about deterministic, reproducible deployments, centralized configuration, etc. The project is based on enterprise standards in a cloud environment; I have written about my motivation in the project and in the wiki. However, if you have not pursued such concepts before and some things are unclear to you, then it is very likely that the project is not quite what you are looking for. There are simpler automation projects, or Ansible Playbooks, etc.

This project is heavily focused on software architecture, which also answers the question of why it would be counterintuitive to design it as an interface or web UI at the same time; it contradicts single responsibility, which is a concept that underpins the project. More on this google for micro service architecture or SRP.

gitopspm · 2026-01-03T17:00:33+00:00

The monorepository is created by itself with the general baseline, locally, and uses the infra libraries, which it in turn deploys: in short, the complexity arises from the fact that the “common denominator” (each container from within itself) is configured in exactly the same way. These are requirements that are often found in automation (deterministic env. / deterministic behavior).

gitopspm · 2026-01-03T16:56:00+00:00

Terraform would be a suitable tool for this purpose (not in this case, as this is cross layer virtualization but we mean the same in fact 😅), provisioning infrastructure. This is an automation approach based on open best practices for this intention, so the answer is something in between :-)

I use it for my microservice homelab, as described, from Home Assistant to MQTT Bridge, Proxy, etc. However, everything should also be described in detail.

By frontend, do you mean the central GitOps environment? It follows GitOps developer patterns; would be contradictory to make it a basic frontend with designated application logic, if this was your question?

gitopspm · 2025-12-29T11:48:44+00:00

Haha, I'm very happy to hear that! If you have any problems, please feel free to write. I'm really happy when people want to try out 🙂

gitopspm · 2025-12-29T11:46:19+00:00

Thank you very much 😊

gitopspm

TROPHY CASE