{"id":429,"date":"2026-08-31T07:45:00","date_gmt":"2026-08-31T05:45:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/?p=429"},"modified":"2026-08-13T14:27:48","modified_gmt":"2026-08-13T12:27:48","slug":"local-ci-cd-raspberry-pi-automating-docker-compose-en","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/en\/raspberry-pi\/local-ci-cd-raspberry-pi-automating-docker-compose-en\/","title":{"rendered":"Local CI\/CD for Raspberry Pi: Automating Docker Compose Deployments"},"content":{"rendered":"\r\n
Managing containerized infrastructure on edge devices such as a Raspberry Pi often involves repetitive manual SSH sessions, manual image pulls, and direct execution of Docker Compose commands. Transitioning to a localized CI\/CD pipeline automates the lifecycle of self-hosted services\u2014including Home Assistant, Nextcloud, and custom Python automation scripts\u2014by leveraging Git repositories, webhook listeners, and local deployment agents.<\/p>\r\n\r\n\r\n\r\n
1. Architecture of Local GitOps for Edge Devices<\/h2>\r\n\r\n\r\n\r\n
Adopting a GitOps methodology shifts the source of truth for all infrastructure configurations from local filesystem modifications to a centralized Git repository. Rather than editing YAML files directly on the server, deployment definitions are maintained in version control.<\/p>\r\n\r\n\r\n\r\n
\r\n
Declarative Configuration:<\/strong> Every service, network definition, and persistent volume is declared explicitly inside structured docker-compose.yml<\/code> files stored in a Git repository.<\/li>\r\n
Auditability & Rollbacks:<\/strong> Version control provides an immutable history of configuration changes, allowing immediate rollbacks to previous working states if an update causes service instability.<\/li>\r\n
Zero-Touch Edge Deployments:<\/strong> The edge server acts as a continuous consumer of repository states, eliminating the need for interactive shell access during routine updates.<\/li>\r\n<\/ul>\r\n\r\n\r\n\r\n\n\nThe edge device is the consumer, not the target: it pulls the repository state itself and converges its stack. The HMAC check is the gate \u2014 an unverified webhook never reaches the pull.<\/figcaption>\n<\/figure>\n\n
2. Automated Pulls and Deployments via Webhook Listeners<\/h2>\r\n\r\n\r\n\r\n
To eliminate manual SSH deployment commands, lightweight webhook servers (such as adnanh\/webhook<\/code> or dedicated automation daemons) can be deployed natively on the Raspberry Pi. These services listen for HTTP POST payloads triggered by code repository push events or CI\/CD pipelines.<\/p>\r\n\r\n\r\n\r\n
Webhook Execution Workflow<\/h3>\r\n\r\n\r\n\r\n
\r\n
Payload Verification:<\/strong> Incoming webhook requests are cryptographically validated using HMAC secret tokens to prevent unauthorized remote execution.<\/li>\r\n
Automated Git Fetch:<\/strong> Upon successful validation, the local daemon triggers a non-interactive pull sequence to update the local workspace from the remote branch.<\/li>\r\n
Stack Re-convergence:<\/strong> The orchestration daemon runs docker compose up -d --remove-orphans<\/code>, ensuring that only modified container images or updated service declarations are recreated while preserving active services.<\/li>\r\n<\/ul>\r\n\r\n\r\n\r\n
3. Container Lifecycle Management without SSH<\/h2>\r\n\r\n\r\n\r\n
Continuous deployment architectures for self-hosted environments benefit from dedicated local agents that monitor container image registries and automate container recreation without external intervention.<\/p>\r\n\r\n\r\n\r\n
\r\n
Automated Registry Polling:<\/strong> Tools of the Watchtower family periodically inspect base image digests for running containers and automatically restart services when newer builds become available. The original containrrr\/watchtower<\/code> repository was archived in December 2025 and the older Ouroboros project is no longer developed; maintained community forks such as nickfedor\/watchtower<\/code> continue as drop-in replacements.<\/li>\r\n
Local Build Automation:<\/strong> For custom Python scripts or microservices, local automation runners can execute Dockerfile builds directly on the ARM architecture, circumventing cross-compilation complexities.<\/li>\r\n
Health Checks & Auto-Recovery:<\/strong> Implementing native Docker health checks ensures that updated containers failing initial startup routines can be flagged immediately without requiring manual log inspections.<\/li>\r\n<\/ul>\r\n\r\n\r\n\r\n
4. Security Considerations for Local CI\/CD Pipelines<\/h2>\r\n\r\n\r\n\r\n
Exposing automated deployment endpoints within a home or enterprise network requires strict privilege separation. Webhook daemons should never run as root; instead, access to the Docker socket should be regulated through dedicated group permissions or read-only socket proxies. Furthermore, isolating deployment listeners within a restricted management VLAN ensures that build automation remains completely protected from untrusted client devices.<\/p>\r\n\n\n
![\"Vertical](\"https:\/\/www.lukaswojcik.com\/blog\/wp-content\/uploads\/diagrams\/raspberry-pi-local-cicd-pipeline-en.png\")
\n