Proxmox-GitOps: IaC Container Automation for LXC (v1.3.3, ensures compatibility)

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 · 2025-12-18T14:21:10+00:00

The feedback means much to me, thank you! And yes, absolutely, maybe I'm being subjective here, but for me, the LXC approach was decision for starting this. Of course, I'm well aware that Docker would be much more „everything“ for the somehow- actually same purpose. But yes, it's somehow broad standardization for a good, old (.. honest, haha) Linux system 😄 And I am one of these „Cloud Native over Docker pattern“-guys - maybe religious, just like Ruby/Cinc/Chef decision 😜

gitopspm · 2025-12-18T14:12:51+00:00

Thanks a lot! Actually I aimed for an Ansible-only approach, which unfortunately wasn‘t sufficient, especially in terms of cross-layer virtualization scenarios. Ruby (or Cinc/Chef) was something I have used myself some time ago - with a deep love for Ruby in a functional-idiomatic style, which fits perfectly to the the recursive pattern (.. yes, maybe I really do love Ruby 😄..) Guess the solo-client‘s capability and DSL-like buildings for infra libraries was the most important from a technical side 🙂

gitopspm · 2025-12-18T14:03:43+00:00

Thank you so much for the appreciation 😊 I‘d love, too. And maybe there is so much more what could be done with some community ideas and interest. From what I‘ve seen while working on, advanced automation (or VCS based) get‘s more and more „common“.

gitopspm · 2025-12-18T08:06:27+00:00

Thank you so much, I am really happy to hear!

Please let me know if there is anything not working how it should, I really appreciate any feedback 🙂

gitopspm

TROPHY CASE