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
- 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!
melezhik•4mo ago
stevius•4mo ago
First, these aren't immutable containers – they're LXC containers treated as persistent, stateful systems (more VM-like than Docker-like).
Here's how the tools are used:
Ansible handles the "outside" (Proxmox host level): - Container provisioning via Proxmox API (`base/roles/container/`) - LXC lifecycle management (create, start, stop, destroy) - Base infrastructure setup (SSH keys, networking, storage mounts) - Host-to-container bootstrapping
Cinc (Chef) handles the "inside" (within each container): - Application-specific configuration (`config/recipes/`, `libs//recipes/`) - Service management and desired state enforcement - Runtime configuration updates - Cross-container state coordination (like the Git service managing repositories)
*Why this makes sense for LXC:* Unlike Docker's "build once, deploy everywhere" philosophy, LXC containers in this system are *long-lived infrastructure pieces* that need ongoing configuration management. Each container might run for months/years and needs to adapt to changing requirements, handle updates, manage state, etc.
The recursive self-containment aspect is particularly clever – the control plane (running in its own LXC container) uses the exact same base configuration and tooling as the containers it manages, ensuring consistency and enabling the whole system to bootstrap itself.
So while you're right that immutable containers don't typically need provisioning stages, this isn't really following the immutable container pattern – it's more like "Infrastructure as Code" for persistent container-based services, which absolutely benefits from both provisioning and configuration management layers.