Proxmox-GitOps

xtend, .. 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.

automated, container-based infrastructure. 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.

initially driven by the question of what a Proxmox-based GitOps automation could look like and how it could be organized. Core Concepts: - Recursive Self-management: Control plane seeds itself by pushing its monorepository onto a locally bootstrapped instance, triggering a pipeline that recursively provisions the control plane onto PVE. - Monorepository: Centralizes infrastructure as comprehensive IaC artifact (for mirroring, like the project itself on Github) using submodules for modular composition. - Single Source of Truth: Git represents the desired infrastructure state. - Loose coupling: Containers are decoupled from the control plane, enabling runtime replacement and independent operation. It's a noncommercial, 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? I'd love to hear your thoughts!

m 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. Core Concepts - Recursive Self-management: Control plane seeds itself by pushing its monorepository onto a locally bootstrapped instance, triggering a pipeline that recursively provisions the control plane onto PVE. - Monorepository: Centralizes infrastructure as comprehensive IaC artifact (for mirroring, like the project itself on Github) using submodules for modular composition. - Git as State: Git repository represents the desired infrastructure state. - Loose coupling: Containers are decoupled from the control plane, enabling runtime replacement and independent operation. Over the past few months, the project stabilized, and I’ve addressed many questions you had in Wiki, summarized to documentation, which should now covers essential technical, conceptual, and practical aspects. I’ve also added a short demo that breaks down the theory by demonstrating the automation of an IaC stack (Home Assistant, Mosquitto bridge, Zigbee2MQTT broker, snapshot restore, reverse proxy, dynamically configured via PVE API), with automated container system updates and service checks. What am I looking for? It's a noncommercial, 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? I'd love to hear your thoughts!

GitOps automation could look like and how it could be organized. Github: https://github.com/stevius10/Proxmox-GitOps On point: 75sec hands-on demo [video]: https://youtu.be/2oXDgbvFCWY It's a noncommercial, 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? I'd love to hear your thoughts!

or an elegant, self-contained system. It's an attempt to build a generic IaC abstraction that manages its own lifecycle, initially driven by the question of what I wanted my own GitOps home automation to look like. This is 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: How do we want our home automation to be? I‘d love to hear your thoughts! —— - Recursive self-management: the control plane executes within the managed containers to maximize reproducibility and minimize drift. - Git as current desired state: operations map to standard Git workflows (commit, merge, rollback) in a stateless management model. - Convention-based extensibility: add a service by copying a container definition from libs, adding a minimal cookbook and `config.env`; the pipeline handles provisioning, configuration, and validation. - Loose coupling: containers remain independently replaceable and continue to function without manual follow-up.

- Recursive self-management: the control plane executes within the managed containers to maximize reproducibility and minimize drift. - Git as current desired state: operations map to standard Git workflows (commit, merge, rollback) in a stateless management model. - Convention-based extensibility: add a service by copying a container definition from libs, adding a minimal cookbook and `config.env`; the pipeline handles provisioning, configuration, and validation. - Loose coupling: containers remain independently replaceable and continue to function without manual follow-up. Environment - Proxmox VE 8.4–9.0, Debian 13 LXC per default. - Local bootstrap via Docker; further actions are repository-driven. Install - Configure Proxmox credentials in `./local/config.json`. - Run `./local/run.sh` to seed the environment. - Accept the initial PR in the seeded Gitea instance at `localhost:8080/main/config`. - Push changes to trigger provisioning, convergence, and validation on Proxmox VE. Trade-Offs - The recursive bootstrap increases complexity to preserve rebuild‑from‑repo semantics and deterministic behavior. - On Proxmox 9, stricter token privileges limit certain operations; automation uses root‑context API access where tokens are insufficient.

ainer defs (e.g., Home Assistant stack: MQTT broker, Zigbee bridge, reverse proxy). - *Recursive self-management:* Pipeline runs inside its own containers; push code to auto-provision and configure. - *IaC consistency:* Ansible for provisioning, Chef for internal config; shared env vars propagate automatically. - *Extensible:* Add custom containers via Cinc (Ruby) cookbooks - *Stateless & reproducible:* Git as state engine; snapshots for backups/rollbacks.

ent container base configuration: default app/config users, automated key management, tooling — deterministic, idempotent setup - Application-logic container repositories: app logic lives in each container repo; shared libraries, pipelines and integration come by convention - Monorepository with recursively referenced submodules: runtime-modularized, suitable for VCS mirrors, automatically extended by libs Pipeline concept: - GitOps environment runs identically in a container; pushing the codebase (monorepo + container libs as submodules) into CI/CD - This triggers the pipeline from within itself after accepting pull requests: each container applies the same processed pipelines, enforces desired state, and updates references - Provisioning uses Ansible via the Proxmox API; configuration inside containers is handled by Chef/Cinc cookbooks - Shared configuration automatically propagates - Containers integrate seamlessly by following the same predefined pipelines and conventions — at container level and inside the monorepository - The control plane is built on the same base it uses for the containers, so verifying its own foundation implies a verified container base — a reproducible and adaptable starting point for container automation It’s still under development, so there may be rough edges — feedback, experiences, or just a thought are more than welcome!

guration is managed with Chef/Cinc cookbooks focused on application logic. Shared configuration is applied consistently across all services. Changes to the base system propagate automatically. It’s easily extensible, aiming to have all containers built the same way. There’s an explanation of how to do this in the README of the repository. This project is still young and there are most likely some bugs. I built it primarily for my own homelab, but I’d like to develop it further. Would really appreciate if you are interested in The project