Show HN: Proxmox-GitOps: IaC Container Automation for Proxmox (Recursive Docker)

I want to share my container automation project Proxmox-GitOps — an extensible, self-bootstrapping GitOps environment for Proxmox.

It is now aligned with current Proxmox 9.0 and Debian Trixie - which is used for containers base configuration per default. Therefore I’d like to introduce it for anyone interested in a Homelab-as-Code starting point

GitHub: https://github.com/stevius10/Proxmox-GitOps

It implements a self-sufficient, extensible CI/CD environment for provisioning, configuring, and orchestrating Linux Containers (LXC) within Proxmox VE. Leveraging an Infrastructure-as-Code (IaC) approach, it manages the entire container lifecycle—bootstrapping, deployment, configuration, and validation—through version-controlled automation.

- One-command bootstrap: deploy to Docker, Docker deploy to Proxmox

- Ansible, Chef (Cinc), Ruby

- Consistent 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!