{"id":8701,"date":"2026-08-14T15:37:00","date_gmt":"2026-08-14T13:37:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=8701"},"modified":"2026-08-13T14:29:50","modified_gmt":"2026-08-13T12:29:50","slug":"automated-docker-deployments-raspberry-pi-local-first-8701","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/en\/raspberry-pi\/automated-docker-deployments-raspberry-pi-local-first-8701\/","title":{"rendered":"Automated Docker Deployments on the Raspberry Pi: Local-First Dev Environments"},"content":{"rendered":"\r\n

Operating self-hosted services\u2014such as Home Assistant, Node-RED, and local analytics tracking environments\u2014on a Raspberry Pi often involves manual software updates and ad-hoc configuration adjustments. This traditional approach consumes significant maintenance time and introduces operational risks, including configuration drift, dependency conflicts, and unexpected downtime.<\/p>\r\n\r\n\r\n\r\n

To establish a resilient, deterministic local infrastructure, services must be decoupled from the host operating system. Containerizing the entire smart home and analytics tool landscape via Docker Compose<\/strong> paired with automated deployment pipelines\u2014using local Watchtower<\/strong> setups or structured CI\/CD workflows via GitHub Actions<\/strong>\u2014ensures reproducible, zero-downtime edge environments.<\/p>\r\n\r\n\r\n\r\n

1. Containerizing the Edge Landscape with Docker Compose<\/h2>\r\n\r\n\r\n\r\n

Docker Compose serves as the declarative baseline for local-first edge architectures. By defining all services, persistent volume mounts, and network bridges within a single version-controlled configuration file, infrastructure state becomes fully reproducible.<\/p>\r\n\r\n\r\n\r\n

# docker-compose.yml: Integrated Smart Home & Local Tracking Stack\r\nservices:\r\n  homeassistant:\r\n    container_name: homeassistant\r\n    image: ghcr.io\/home-assistant\/home-assistant:stable\r\n    volumes:\r\n      - \/opt\/homeassistant\/config:\/config\r\n      - \/etc\/localtime:\/etc\/localtime:ro\r\n    restart: unless-stopped\r\n    network_mode: host\r\n\r\n  nodered:\r\n    container_name: nodered\r\n    image: nodered\/node-red:latest\r\n    environment:\r\n      - TZ=Europe\/Warsaw\r\n    volumes:\r\n      - \/opt\/nodered\/data:\/data\r\n    ports:\r\n      - \"1880:1880\"\r\n    restart: unless-stopped\r\n\r\n  watchtower:\r\n    container_name: watchtower\r\n    image: containrrr\/watchtower:latest\r\n    volumes:\r\n      - \/var\/run\/docker.sock:\/var\/run\/docker.sock\r\n    environment:\r\n      - WATCHTOWER_CLEANUP=true\r\n      - WATCHTOWER_SCHEDULE=0 0 4 * * *\r\n    restart: unless-stopped<\/code><\/pre>\r\n\r\n\r\n\r\n
A note on the maintenance status: the upstream project containrrr\/watchtower<\/code> was archived on 17 December 2025 and has been read-only since then, so the image receives no further updates or security fixes. The original maintainers have not designated a successor. Development continues in community forks \u2014 nickfedor\/watchtower<\/code> (also published as ghcr.io\/nicholas-fedor\/watchtower<\/code>) is configuration-compatible and still ships regular releases. The update path for this service should therefore be reviewed before productive use.<\/p>\r\n\r\n\r\n\r\n
In this architecture, persistent data directories reside on reliable external storage (such as a NAS share or SSD), ensuring that container updates never overwrite critical configurations or historical metrics.<\/p>\r\n\r\n\r\n\r\n
\n\"Diagram\n
The 3 building blocks of the article at a glance: Containerizing the Edge Landscape with Docker\u2026, Automated Maintenance: Watchtower vs. CI\/CD\u2026, Implementing a GitHub Actions Deployment Pipeline.<\/figcaption>\n<\/figure>\n\n
2. Automated Maintenance: Watchtower vs. CI\/CD Pipelines<\/h2>\r\n\r\n\r\n\r\n
Automating deployment and lifecycle management can be achieved through two primary architectural patterns, depending on system complexity and governance requirements:<\/p>\r\n\r\n\r\n\r\n
Deployment Pattern<\/th>Execution Mechanism<\/th>Best Suited For<\/th>Key Advantage<\/th><\/tr><\/thead>
Local Automation (Watchtower)<\/strong><\/td>A background daemon polls image registries daily and restarts updated containers automatically.<\/td>Standard off-the-shelf images (Home Assistant, Node-RED, Eclipse Mosquitto).<\/td>Zero external infrastructure required; fully autonomous edge maintenance.<\/td><\/tr>
GitOps \/ CI\/CD (GitHub Actions)<\/strong><\/td>Code commits trigger remote build pipelines that SSH into the Raspberry Pi and execute deployments.<\/td>Custom software builds, proprietary analytics tools, or multi-node infrastructures.<\/td>Deterministic version control, automated testing before deployment, and easy rollbacks.<\/td><\/tr><\/tbody><\/table><\/figure>\r\n\r\n\r\n\r\n
3. Implementing a GitHub Actions Deployment Pipeline<\/h2>\r\n\r\n\r\n\r\n
For custom edge applications or structured infrastructure-as-code (IaC) repositories, deploying via GitHub Actions provides an audit trail of every configuration change. When updates are pushed to the main branch, a workflow connects securely to the Raspberry Pi over SSH to pull changes and reconstruct the stack.<\/p>\r\n\r\n\r\n\r\n
# .github\/workflows\/deploy-edge.yml\r\nname: Deploy Stack to Raspberry Pi\r\n\r\non:\r\n  push:\r\n    branches:\r\n      - main\r\n\r\njobs:\r\n  deploy:\r\n    runs-on: ubuntu-latest\r\n    steps:\r\n      - name: Execute Remote Deployment via SSH\r\n        uses: appleboy\/ssh-action@v1.0.0\r\n        with:\r\n          host: ${{ secrets.RPI_HOST }}\r\n          username: ${{ secrets.RPI_USER }}\r\n          key: ${{ secrets.RPI_SSH_KEY }}\r\n          script: |\r\n            cd \/opt\/edge-stack\r\n            git pull origin main\r\n            docker compose pull\r\n            docker compose up -d --remove-orphans\r\n            docker system prune -f<\/code><\/pre>\r\n\r\n\r\n\r\n
Summary<\/h2>\r\n\r\n\r\n\r\n
Transitioning a Raspberry Pi from a manually configured single-board computer into an automated, containerized edge server minimizes administrative overhead. Whether deploying autonomous updates via Watchtower or deterministic GitOps workflows via GitHub Actions, containerization guarantees a stable, secure, and low-maintenance operational environment for smart home and analytics infrastructures.<\/p>\r\n\n\n
\n
Sources<\/h2>\n