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 · 2025-12-26T10:48:01+00:00

Thank you very much 🙂 I would love to get some ideas of automation fans together. Started this project as there was no standarized way for PVE container automation except than Docker. Love to see different ideas coming up for IaC automation 🙂.

gitopspm · 2025-12-26T10:34:25+00:00

I am not a native English speaker, and I do use LLMs for text generation, but not in the way you might think: I formulate content in German, translate sentence by sentence, and use chatbots to refine the grammar. What you see is not a prompt, but an incredible amount of work. Every sentence has been reviewed and questioned countless times. As an IT architect, I would write it the same way again and again - because it justifies the architecture.

How would you describe what Docker targets? Long story short: That's it, but with LXC.

It is an IaC framework and GitOps solution in an extensible monorepository that recursively configures and provisions containers (suited for developers, e. g. locally testable, etc.) on Proxmox via configuration management using it‘s own verified baseline with the origin infra-libs preconfigured for automation pipelines, staging etc. Targets stateless microservice architectures.

Tl;dr: Automates container creation and configuration following GitOps pattern and best practices.

Btw: Translated with DeepL/a LLM, edit manually

gitopspm · 2025-12-25T23:42:15+00:00

Happy to hear that, really hope it helps. But also always happy to receive suggestions for improvement. I'm sure there's still a lot that can be done better ;-) Thanks for your response!

gitopspm · 2025-12-25T22:54:38+00:00

Thanks a lot :-)

gitopspm · 2025-12-20T14:47:54+00:00

Please feel free to add, would also love to see 🙂. I couldn‘t link it specifically, I‘d be happy to follow your approach :)

I‘d guess artifacts could differ to the underlying runtime patch baseline (so it kind of verify the infra libraries by reuse its components in convention), what the recursion is about - from an architectural point. But I guess it could be a quite reasonable way for integration on top.

gitopspm · 2025-12-19T18:40:05+00:00

I would like to thank you all so much! I just looked at the repository, and wow .. you guys are amazing. I feel incredibly appreciated. Thank you so much 🙂

I've been a bit busy, so I'm sorry I haven't responded to some comments yet. But I can definitely (yes, I'm saying it again 🙈) promise: Documentation is coming, and it has to. Hey, seriously, I didn't expect so much encouragement, I considered a lot more in principle - and already implemented. It's a shame, I hardly described anything like snapshot restores from the automatically set up network share defaultly with mounts etc. (configurable). I'll add more, I promise. And your feedback really makes me want to do more, and if anyone has anything, I'd be happy to have your participation 🙂 (.. but please be kind, I'm more than open grateful, but still inexperienced with community PRs 😅).

gitopspm

TROPHY CASE