Managing Raspberry Pi and Edge Nodes with Polycrate in IoT and Edge Computing

TL;DR

• You can centrally manage hundreds of Raspberry Pis and other edge nodes with Ansible—without an agent on the devices, just via SSH.
• Polycrate handles the entire Ansible setup for you: No need for Python or Ansible installation on your laptop, everything runs reproducibly in a container.
• With a single Polycrate block, you can build idempotent OTA updates (apt upgrade) including service restarts and distribute sensor and logging configurations across your device fleet.
• Using serial: 10, you can safely roll out updates in waves, for example, 50 Raspberry Pis in groups of 10—ideal for factory halls, smart home fleets, or Industry 4.0 setups.
• ayedo supports teams with practical workshops, ready-made Polycrate blocks, and consulting around IoT and edge automation—including compliance topics and secure workspace encryption.

The IoT Management Problem in Practice

Imagine a typical factory hall:

• 100 Raspberry Pis as edge nodes on machines
• a few industrial gateways in the control cabinet
• maybe 20 sensor boxes in the warehouse

All doing “something important”: collecting data, sending it to the cloud, triggering alarms. But:

• Updates are done manually (“when I get around to it”)
• Configurations are distributed via SCP or USB stick
• No one knows exactly which device is at what status

This is not only inconvenient but risky:

• Security updates are left undone
• Configuration errors are hard to find
• Errors are not traceable—no audit trail

Ansible is excellent for such tasks. But:
Many IoT and OT teams struggle to set up Ansible properly: Python versions, collections, SSH configuration, ansible.cfg, and so on.

This is where Polycrate comes in: You get a standardized Ansible environment in a container—without the installation marathon on your laptop. You focus on your devices, not your tooling.

Ansible for Raspberry Pi and Edge Nodes—Without Setup Stress

Raspberry Pis are indispensable in IoT and edge projects. They are ideal targets for Ansible:

• Standard Linux (e.g., Raspberry Pi OS, Ubuntu Server)
• SSH access possible
• Python is usually pre-installed

Important: The architecture (armv7, arm64) doesn’t matter to Ansible. Ansible controls the devices via SSH, and the modules run directly on the target system. So you need:

• on the target: SSH + Python
• on your laptop: a working Ansible environment

With “plain” Ansible, this means for you:

• Install Python (which version?)
• Install Ansible (which version fits your team?)
• Pull in collections (e.g., community.general)
• Maintain ansible.cfg and inventories

And then it works differently on your colleague’s laptop than on yours because versions vary slightly.

With Polycrate, it looks different:

• Ansible runs in a container that Polycrate starts for you
• The versions of Ansible, Python, and tools are fixed in the container image
• Everyone on the team uses the same toolchain—reproducible on every computer

More about Ansible integration can be found in the Polycrate documentation on Ansible integration.

A Workspace for Your Edge Fleet

We start with a simple Polycrate workspace for a small fleet of Raspberry Pis.

Assume your workspace is in a Git repository and is called acme-corp-automation. In the root directory of the workspace is your inventory as a YAML file inventory.yml:

# inventory.yml (Ansible YAML inventory)
all:
  children:
    edge:
      hosts:
        pi-01.acme-corp.com:
          ansible_user: pi
        pi-02.acme-corp.com:
          ansible_user: pi
        pi-03.acme-corp.com:
          ansible_user: pi
        pi-04.acme-corp.com:
          ansible_user: pi
        pi-05.acme-corp.com:
          ansible_user: pi

Notes:

• edge is the group you target from the block with hosts_group: edge.
• The inventory is always in the workspace root as inventory.yml.
• Polycrate automatically sets the environment variable ANSIBLE_INVENTORY to this file.
• For 50 or 100 devices, you extend the list under edge.hosts.

This gives you the “map” of your edge fleet centrally in one place.

Next, we define a block in Polycrate that uses exactly these hosts for OTA updates and configuration.

More about workspaces can be found in the documentation on Workspaces.

Polycrate Block for OTA Updates on Edge Nodes

We now create a block that:

• Performs OTA updates via apt upgrade
• Then restarts an edge service
• Rolls out updates in waves (e.g., 10 devices at a time)

Directory structure (simplified):

acme-corp-automation/
  workspace.poly
  inventory.yml
  blocks/
    registry.acme-corp.com/acme/iot/edge-ota/
      block.poly
      ota-update.yml
      deploy-config.yml
      sensor-config.yml.j2

(After polycrate pull registry.acme-corp.com/acme/iot/edge-ota:0.1.0, the block lives at this path.)

block.poly for the Edge-OTA Block

# blocks/registry.acme-corp.com/acme/iot/edge-ota/block.poly
name: registry.acme-corp.com/acme/iot/edge-ota
version: 0.1.0
kind: generic

config:
  hosts_group: edge
  service_name: edge-agent
  serial: 10
  config_path: /etc/edge-agent/config.yml
  logging_level: INFO

actions:
  - name: ota-update
    description: Perform apt updates on all edge nodes
    playbook: ota-update.yml

  - name: deploy-config
    description: Distribute configuration for sensors and logging
    playbook: deploy-config.yml

Important:

• config defines all changeable parameters of your block—ideal for different fleets (e.g., other services, other paths).
• actions are named entry points. Your colleagues will later simply run polycrate run edge-ota ota-update without needing to know Ansible CLI details.

More about blocks can be found under Blocks and Actions.

OTA Updates with Ansible—Idempotent and Staggered

The associated Ansible playbook ota-update.yml is located in the same block directory:

# blocks/registry.acme-corp.com/acme/iot/edge-ota/ota-update.yml
- name: OTA Updates for Edge Nodes
  hosts: "{{ block.config.hosts_group }}"
  serial: "{{ block.config.serial }}"
  become: true
  gather_facts: false

  tasks:
    - name: Update package index
      ansible.builtin.apt:
        update_cache: true
        cache_valid_time: 3600

    - name: Update system packages
      ansible.builtin.apt:
        upgrade: safe
      notify: Restart Edge Service

  handlers:
    - name: Restart Edge Service
      ansible.builtin.service:
        name: "{{ block.config.service_name }}"
        state: restarted

Key points:

• hosts: "{{ block.config.hosts_group }}"
  – we use the edge group from your inventory.yml. You can reconfigure it in the block if needed.
• serial: "{{ block.config.serial }}"
  – this is where the staggered rollout happens: Ansible processes, for example, always 10 hosts at a time.
  This prevents a failure from knocking out all 50 devices at once.
• apt tasks are idempotent: If a device is already up to date, Ansible does nothing further.
• The service restart is only executed if packages were actually updated (notify handler).

With “plain” Ansible, you would need to:

• Install Ansible and collections yourself
• Provide a suitable Python setup
• Correctly call the ansible-playbook CLI (-i inventory.yml ota-update.yml)

With Polycrate, it’s enough:

polycrate run edge-ota ota-update

The command:

• Starts a container with your Ansible toolchain
• Automatically loads your inventory.yml
• Executes the playbook against your edge fleet

No local Ansible installation, no Python conflicts, no “works only on my laptop”.

Configuration Management: Distributing Sensors and Logging

Updates are only half the battle. Equally important is central configuration:

• Sensor sampling intervals
• Logging levels (e.g., DEBUG vs. INFO)
• Target systems for logs (e.g., Syslog server)

With Polycrate, you control this via the same block—a second action distributes a configuration file.

Playbook for Configuration Deployment

# blocks/registry.acme-corp.com/acme/iot/edge-ota/deploy-config.yml
- name: Distribute Configuration for Edge Nodes
  hosts: "{{ block.config.hosts_group }}"
  become: true
  gather_facts: false

  tasks:
    - name: Create configuration directory
      ansible.builtin.file:
        path: "{{ block.config.config_path | dirname }}"
        state: directory
        owner: root
        group: root
        mode: "0755"

    - name: Deploy configuration file from template
      ansible.builtin.template:
        src: sensor-config.yml.j2
        dest: "{{ block.config.config_path }}"
        owner: root
        group: root
        mode: "0644"
      notify: Restart Edge Service

  handlers:
    - name: Restart Edge Service
      ansible.builtin.service:
        name: "{{ block.config.service_name }}"
        state: restarted

Jinja2 Template for Sensor Config

# blocks/registry.acme-corp.com/acme/iot/edge-ota/sensor-config.yml.j2
sensors:
  sampling_interval_ms: 1000

logging:
  level: "{{ block.config.logging_level }}"
  destination: syslog

edge:
  node_name: "{{ inventory_hostname }}"

Here you see Jinja2 templates in action:

• {{ block.config.logging_level }}
  – reads the configuration directly from block.config in your block.poly.
  If you change INFO to DEBUG there, the new setting will be rolled out to all devices.
• {{ inventory_hostname }}
  – refers to the hostname from the inventory (pi-01.acme-corp.com etc.).

Execution is again simple:

polycrate run edge-ota deploy-config

With two actions in one block, you now have:

• Reproducible OTA updates
• Reproducible configuration deployments

Everything is versioned, well-structured, and can be shared with your team—this is the “Sharable Automation” concept of Polycrate.

workspace.poly: Integrating and Configuring the Block

To let Polycrate know which block to use in this workspace, you enter it in the workspace.poly:

# workspace.poly
name: acme-corp-automation
organization: acme

blocks:
  - name: edge-ota
    from: registry.acme-corp.com/acme/iot/edge-ota:0.1.0
    config:
      hosts_group: edge
      service_name: edge-agent
      serial: 10
      config_path: /etc/edge-agent/config.yml
      logging_level: INFO

Explanations:

• from: registry.acme-corp.com/acme/iot/edge-ota:0.1.0
  – references the block in your OCI registry (fictional example); after polycrate pull …, it lives under blocks/registry.acme-corp.com/acme/iot/edge-ota/.
• config:
  – overrides or sets the default values from block.poly. This way, you can create a second block entry with a different service name for another hall.

You can push your own blocks to the same registry and share them with other teams—or make them accessible via PolyHub. Polycrate supports you in this; see Registry documentation and PolyHub documentation.

Security and Compliance: Workspace Encryption for IoT

Especially in OT environments, workspaces often contain sensitive data:

• SSH keys for edge nodes
• WLAN credentials for remote locations
• Credentials for central logging or cloud systems

Polycrate comes with built-in workspace encryption using age. You don’t need to run an external secret store like HashiCorp Vault, but you can use it additionally if you wish.

Typical process:

1. You place secret files under artifacts/secrets/, for example:

   artifacts/secrets/
     id_ed25519
     id_ed25519.pub

2. You encrypt the workspace:

   polycrate workspace encrypt

3. Before working, decrypt again:

   polycrate workspace decrypt

Polycrate integrates these secrets automatically so you can reference them in playbooks via workspace.secrets without hard-coding paths.

Read more in the documentation on workspace encryption and SSH integration.

That bridges IoT practice and compliance requirements (e.g., internal policies, ISO 27001, or industry-specific rules).

Plain Ansible vs. Polycrate: The “Aha” Moment for IoT Teams

To make the difference clear, consider what you would have to do with “plain” Ansible:

• Install and maintain Python locally
• Install Ansible and required collections
• Maintain different setups per OS (Windows, macOS, Linux)
• Manually coordinate ansible.cfg, inventory.yml, playbooks, and secrets
• Onboard colleagues (“Your playbook fails because of Python 3.12—you need 3.10…”)

With Polycrate:

• Install Polycrate once (binary)
• Check out the workspace
• Run polycrate run edge-ota ota-update or polycrate run edge-ota deploy-config

The rest runs in the container—including Ansible, Python, and additional tools. You get:

• reproducible automation
• less dependency chaos
• clear structure through the block model instead of ad-hoc playbook collections

Best practices for structuring blocks and workspaces are in Best practices.

Frequently Asked Questions

Do I need a special Polycrate or Ansible agent on the Raspberry Pis?

No. Ansible is agentless. On the devices you need:

• an SSH server
• a user with sufficient privileges (e.g., pi with sudo)
• Python (usually already present on common Raspberry Pi Linux distributions)

Polycrate does not change that—it only ensures Ansible runs on your side cleanly. You don’t install anything extra on the edge nodes.

What happens if an edge node is unreachable during an update?

Ansible marks the host as unreachable but does not abort the entire rollout—especially combined with serial.
With serial: 10, for example, 10 hosts are processed at a time. If one fails, the other nine continue. The unreachable host stays visible in the report and can be targeted again later.

Because the playbooks are idempotent, you can run the same Polycrate command again once connectivity returns. Ansible then only applies what is still missing.

Can I integrate Polycrate into existing OT/IT environments?

Yes. Typical scenarios:

• on OT/IoT engineers’ laptops to roll out updates independently
• on a central Linux server in the plant as an automation hub
• in CI/CD pipelines for periodic health checks or config drift detection

Because Polycrate is container-based, you get the same environment everywhere. You can start small—for example with only an OTA block—and add more blocks (monitoring, security, backups) later.

More questions? See our FAQ.

From Routine to a Reproducible Fleet

In this article you saw how to turn a messy collection of edge nodes into a manageable fleet:

• You manage Raspberry Pis and other edge nodes centrally via a YAML inventory.
• You use a Polycrate block to encapsulate routine tasks like OTA updates and configuration deployment.
• You run everything with simple commands without fighting Ansible installs and Python versions.
• You benefit from built-in workspace encryption and clear, shareable automation.

For many IoT and OT teams, this step is critical:
Away from “someone SSHs in and fixes it somehow”—toward traceable, versioned, repeatable flows that still work in a year and can be audited.

At ayedo we support you with:

• hands-on workshops on IoT and edge automation (including Polycrate and Ansible),
• preconfigured blocks for typical tasks such as OTA updates, logging, monitoring, and security,
• and individual guidance on embedding Polycrate into your existing OT and IT landscape—from the factory floor to the cloud.

If you want to structure and automate your own edge fleet safely, a focused workshop is a good start—overview and registration: Workshops.