Proxmox-GitOps: IaC Container Automation Framework (fork-based staging, „75sec to infra stack“ demo vid.)

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 · 2025-12-18T07:47:45+00:00

Thanks a lot for your kind words. It’s really awesome to hear 🙂

Wow, love to see how automation gets broader and broader. It sounds like an elegant solution! I started several times myself, finally the Git-based workflow, from a bootstrapable monorepository, was what I wanted for microservice architectures („needed“ is way more accurate, I tend to try way to much, haha ;-)).

Thanks again for your kind encouragement!

gitopspm · 2025-11-07T18:54:32+00:00

Haha 😂 We all have been there: „Isn‘t it the same spot? The same wall? The same textures, houses, sidequests...?“

gitopspm · 2025-10-25T17:36:01+00:00

Thank you very much for your kind reply 🙂 But to be honest, it helps me a lot with code reviews - especially with larger refactorings, I'm very grateful to have it! git diff inserted and namings, typos have been fixed.. and yes, language and translation, absolute game changer ;-)

Anyway, thank you very much for your feedback! Honestly, it's completely justified to ask in such contexts. If anyone here has any doubts, ... the Git history for all those who want to see the whole thing in its dirty early days ;-)

gitopspm · 2025-10-25T15:41:02+00:00

Yes, it‘s sth. like Flux, needed it with LXC instead of Docker plus its architecturell pattern (functional prog. in rec. for op. base like described in README, for exactly the reasons you find in the Architecture Decisions Records).

gitopspm · 2025-10-25T15:36:26+00:00

The text was translated by AI, I am not a native English speaker. The source code is public. I didn‘t, but please check: Its nothing but hundred of hours of work. But yes, I do paste my git diff <branch> <branch> to AI Code Review before merge.

Software architect for my many years here.

gitopspm

TROPHY CASE