[PR #651] Add Proxmox-GitOps to Continuous Integration & Continuous Deployment #630

New Issue

GiteaMirror · 2025-11-06T17:05:01-06:00

GiteaMirror commented

2025-11-06 17:05:01 -06:00

📋 Pull Request Information

Original PR: https://github.com/awesome-foss/awesome-sysadmin/pull/651
Author: @stevius10
Created: 10/21/2025
Status: 🔄 Open

Base: master ← Head: feat/add-proxmox-gitops

📝 Commits (1)

2faf5ac Adds Proxmox-GitOps, a self-contained GitOps framework, to the

📊 Changes

1 file changed (+1 additions, -0 deletions)

View changed files

📝 README.md (+1 -0)

📄 Description

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.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/awesome-foss/awesome-sysadmin/pull/651 **Author:** [@stevius10](https://github.com/stevius10) **Created:** 10/21/2025 **Status:** 🔄 Open **Base:** `master` ← **Head:** `feat/add-proxmox-gitops` --- ### 📝 Commits (1) - [`2faf5ac`](https://github.com/awesome-foss/awesome-sysadmin/commit/2faf5ac4e9b619d8c215e92ef2d98702a804b6c6) Adds Proxmox-GitOps, a self-contained GitOps framework, to the ### 📊 Changes **1 file changed** (+1 additions, -0 deletions) <details> <summary>View changed files</summary> 📝 `README.md` (+1 -0) </details> ### 📄 Description  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: - [x] Your additions are [Free software](https://en.wikipedia.org/wiki/Free_software) `MIT` - [x] 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._ - [x] 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](https://en.wikipedia.org/wiki/Letter_case#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` `` - [x] Additions are inserted preserving alphabetical order. - [x] Additions are not already listed at [awesome-selfhosted](https://awesome-selfhosted.net) - [x] 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. - [x] You have searched the repository for any relevant [issues](https://github.com/awesome-foss/awesome-sysadmin/issues) or [PRs](https://github.com/awesome-foss/awesome-sysadmin/pulls), including closed ones. - [x] Any category you are creating has the minimum requirement of 3 items. - [x] Any software project you are adding to the list is actively maintained. - [x] 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. <img width="593" height="469" alt="Bildschirmfoto 2025-10-21 um 10 56 13" src="https://github.com/user-attachments/assets/41710803-86f1-42d2-8683-094a77ac874a" /> - **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... ?** <img width="820" alt="image" src="https://github.com/user-attachments/assets/f270a7f6-3407-4128-9767-a423be1eca96" /> 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. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

GiteaMirror added the pull-request label 2025-11-06 17:05:01 -06:00

GiteaMirror referenced this issue

2025-11-19 21:11:04 -06:00

[PR #630] Add ArgoCD and Argo Workflows to Continuous Integration & Continuous Deployment #1243

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/awesome-sysadmin#630