Add Proxmox-GitOps to Continuous Integration & Continuous Deployment

[stevius10]

Thank you for taking the time to work on a PR for Awesome-Sysadmin!

To ensure your PR is dealt with swiftly please check the following:

• Your additions are Free software MIT
• Software you are submitting is not your own, unless you have a healthy ecosystem with a few contributors (which aren't your sock puppet accounts).
  While I am the author and have read the guidelines, I believe this community-driven open-source project provides a unique solution for the Proxmox community that is not yet represented. It has already demonstrated the beginnings of a healthy community and generated active discussion and interest (especially on r/proxmox), structured with clear contributing guidelines to encourage collaboration.
• Submit one item per pull request. This eases reviewing and speeds up inclusion.
• x ] Format your submission as follows, where Demo and Clients are optional.
  Do not add a duplicate Source code link if it is the same as the main link.
  Keep the short description under 80 characters and use sentence case
  for it, even if the project's webpage or readme uses another capitalisation.
  Demo links should only be used for interactive demos, i.e. not video demonstrations.
  - [Name](http://homepage/) - Short description, under 250 characters, sentence case. ([Demo](http://url.to/demo), [Source Code](http://url.of/source/code), [Clients](https://url.to/list/of/related/clients-or-apps)) `License` `Language`
• Additions are inserted preserving alphabetical order.
• Additions are not already listed at awesome-selfhosted
• The Language tag is the main server-side requirement for the software. Don't include frameworks or specific dialects. Ruby, Chef (Cinc) and Ansible, following Best Practices for industry automation patterns.
• You have searched the repository for any relevant issues or PRs, including closed ones.
• Any category you are creating has the minimum requirement of 3 items.
• Any software project you are adding to the list is actively maintained.
• The pull request title is informative, unlike "Update README.md".
  Suggested titles: "Add aaa to bbb" for adding software aaa to section bbb,
  "Remove aaa from bbb" for removing, "Fix license for aaa", etc.

---

Please take some time to answer the following questions as best you can:

• Why is it awesome?

Its conceptional and architectural strength is the self-contained composite monorepo architecture, which encapsulates an entire infrastructure stack as a single, version-controlled artifact. This makes infrastructure portable, reproducible, and auditable – having a in recursion proved operational base inherited by containers using configuration management standards.

• Have you used it? For how long?

Yes, as the author, I have been developing and using the project for over a year. It originated as a personal project to bring industrial automation patterns to home servers and is the core of my own infrastructure management.

• Is this in a personal or professional setup?

It is currently used in a personal (homelab) setup but is designed from the ground up with professional best practices like idempotency, loose coupling, and scalability in mind.

It manages Proxmox-based homelab and orchestrates the lifecycle of about a dozen LXC containers running various services (e.g., reverse proxy, MQTT broker, Home Assistant) which are also predefined included (e. g. examples or usage).
It gained popularity especially in Proxmox and architecture context as it is a solution which isn't generically available to Proxmox VE yet.

Replace this text with your answer.

• Biggest pros/cons compared to other solutions?

Pro

• Niche Proxmox GitOps Solution: It is one of the few, if not the only, open-source projects that provides a complete, end-to-end GitOps platform specifically for Proxmox VE and its LXC containers.

• The entire system can be bootstrapped from a single command.

• Recursive Self-Hosting Architecture: The control plane manages itself using the same tooling and base configuration it applies to other containers, ensuring unparalleled consistency and reproducibility.

• Composite IaC Monorepo: Encapsulates the entire infrastructure-from hypervisor-level provisioning to in-container application state—into a single, version-controlled Git repository. This simplifies backup, migration, and disaster recovery to standard Git operations.

• Loose coupling: Containers are decoupled from the control plane, enabling runtime replacement and independent operation.

• Git as a True Single Source of Truth: The Git repository is the desired state of the entire infrastructure.

• Integrated Baseline: The base role standardizes defaults in container configuration. The control plane leverages this baseline and uses built-in infrastructure libraries to deploy itself recursively, establishing an operational pattern that is reproduced in container libs.

• Abstraction, e. g. adoptable to Debian

Contra

• Complexity vs. Autonomy: Recursive self-replication increases complexity drastically to achieve integrated deterministic bootstrap and reproducible behavior.

• Git Convention vs. Infrastructure State: Uses Git as a state engine rather than versioning in volatile, stateless contexts. Monorepository representation, however, encapsulates the entire infrastructure as a self-contained asset suited for version control.

• API Token Restriction vs. Automation: With Proxmox 9, stricter privilege separation prevents privileged containers from mounting shares via API token; automation capabilities, however, are mainly within the root user context. As a consequence, root user-based API access takes precedence over token-based authentication.

• Any other comments about your use case, things you've found excellent, limitations you've encountered... ?

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?

Self-Contained Meta-Framework for Recursive Linux Container Automation as Composite IaC Monorepository.