Das Polycrate-Ökosystem: PolyHub, API, MCP und die Zukunft der Automatisierung

TL;DR

• Polycrate ist längst mehr als ein CLI-Tool: Mit PolyHub, API-Plattform und MCP entsteht ein Ökosystem, in dem wiederverwendbare Automatisierungs-Bausteine, Monitoring und KI-Integration zusammenkommen.
• PolyHub fungiert als Marktplatz für versionierte Blöcke – von Linux-Patching über Windows-Management bis Kubernetes –, während die Polycrate-API Workspaces, Runs und Alerts zentral sichtbar und steuerbar macht.
• MCP (Model Context Protocol, polycrate mcp) stellt KI-Clients Hub-, Doku- und Schema-Tools bereit – Ausführung bleibt bei dir in der CLI; Details in der MCP-Dokumentation.
• Die Artikel-Reihe hat gezeigt, wie Linux-, Windows-, IoT- und Enterprise-Teams mit Polycrate von anfänglichen Playbooks zu strukturierten, verschlüsselten, teilbaren Automationsplattformen kommen.
• ayedo begleitet diesen Weg als erfahrener Partner mit Polycrate-Expertise, Platform-Engineering-Angeboten und Beratungsleistungen – von der ersten Demo bis zu Managed Blocks und API-Integration.

Das Polycrate-Ökosystem im Überblick

Polycrate ist als pragmatische Antwort auf ein bekanntes Problem entstanden: Ansible ist stark, aber das Drumherum kann aufwendig sein. Python-Versionen, lokale Setups, Playbook-Wildwuchs, fehlende Struktur, Freigaben für Compliance – all das kostet Zeit.

Mit Polycrate wird Ansible in einen Container verlagert und bekommt ein Rahmenwerk:

• Die komplette Toolchain läuft im Container – kein lokales Ansible, kein Python-Chaos, weniger Supply-Chain-Risiken.
• Blöcke strukturieren Automatisierung und geben Guardrails gegen Playbook-Sprawl.
• Workspaces bündeln Hosts, Secrets, Blöcke und Workflows.
• Workspace-Verschlüsselung mit age sorgt für einfache, eingebaute Sicherheit.

Was in dieser Artikel-Reihe eher implizit mitschwang: Polycrate ist nicht nur ein Tool, sondern ein Ökosystem. Dazu gehören:

• PolyHub: der Marktplatz für wiederverwendbare Blöcke, erreichbar unter hub.polycrate.io
• Polycrate-API-Plattform: zentrale Sicht auf Workspaces, Runs, Status und Alerts
• MCP (Model Context Protocol): KI-Clients nutzen polycrate mcp (stdio), um u. a. Hub, Doku und Schemas abzufragen – siehe MCP-Dokumentation
• Community und Open Source: eigene Blöcke bauen, teilen, forken, verbessern

Im Folgenden schauen wir uns diese Bausteine an – und was das konkret für Linux-Admins, Windows-Teams, IoT-Umgebungen und Enterprise-Architekten bedeutet.

PolyHub – der Marktplatz für Automatisierung

PolyHub ist die OCI-basierte Registry für Polycrate-Blöcke. Technisch werden Blöcke wie Container-Images versioniert und veröffentlicht; praktisch fühlt es sich an wie ein App-Store für Automatisierung:

• Offizielle ayedo-Blöcke (z.B. für Kubernetes, Monitoring, Security, Storage)
• Community-Blöcke für Linux, Windows, IoT, Edge, Compliance
• Eigene, interne Blöcke, die in private Registries gepusht werden

Welche Blöcke gibt es – und wie finde ich sie?

Auf hub.polycrate.io kannst du nach Blöcken filtern, etwa:

• infra/linux-* für Linux-Server (Patch-Management, Hardening)
• infra/windows-* für Windows-Server, AD, GPO
• k8s/* für Kubernetes-Cluster, Ingress, Monitoring
• security/* für CIS-Benchmarks, Audit-Logging, Compliance-Checks

Jeder Block ist:

• Versioniert (z.B. :0.4.2 – niemals :latest verwenden)
• Dokumentiert (Inputs, Actions, Beispiele)
• Sharable: Du kannst ihn in deinen Workspaces einbinden oder forken und anpassen

Ein Beispiel für eine Workspace-Definition, die einen Block aus PolyHub und einen lokalen Block kombiniert:

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

blocks:
  - name: linux-patching
    from: registry.acme-corp.com/acme/infra/linux-patching:0.4.2
    config:
      target_hosts: "linux_all"

  - name: custom-hardening
    from: custom-hardening
    config:
      profile: "cis_level1"

Das YAML-Inventory liegt – wie in der Workspace-Dokumentation beschrieben – im Workspace-Root als inventory.yml:

# inventory.yml
all:
  children:
    linux_all:
      hosts:
        server01.acme-corp.com:
          ansible_user: ubuntu
        server02.acme-corp.com:
          ansible_user: ubuntu

Der lokale Block custom-hardening könnte so aussehen:

# blocks/custom-hardening/block.poly
name: custom-hardening
version: 0.1.0
kind: generic

config:
  profile: "cis_level1"

actions:
  - name: apply
    description: "Hardening-Profil anwenden"
    playbook: hardening.yml

Und das dazugehörige Ansible-Playbook:

# blocks/custom-hardening/hardening.yml
---
- name: Apply custom hardening profile
  hosts: all
  become: true

  vars:
    hardening_profile: "{{ block.config.profile }}"

  tasks:
    - name: Ensure auditd is installed
      ansible.builtin.package:
        name: auditd
        state: present

    - name: Ensure minimal password length
      ansible.builtin.lineinfile:
        path: /etc/pam.d/common-password
        regexp: '^password\s+requisite\s+pam_pwquality\.so'
        line: 'password requisite pam_pwquality.so retry=3 minlen=14'

Ausgeführt wird das Ganze wie gewohnt im Container:

polycrate run custom-hardening apply

Die Dependencies (Ansible, Python, Module wie ansible.builtin.*) bringt der Polycrate-Container mit. Du musst lokal weder Ansible noch Python installieren – das löst das klassische Dependency-Problem elegant und reproduzierbar.

Mit plain Ansible würdest du:

• Ansible lokal und/oder auf einem Control-Host installieren
• ansible.cfg, Python-Versionen und Collections manuell managen
• Das Playbook und Inventory irgendwo „aus der Reihe“ ablegen

Mit Polycrate ist derselbe Inhalt verpackt in einen Block, mit klarer Struktur und Guardrails. Mehr dazu in der Ansible-Integration und den Best Practices.

Polycrate-API – Runs, Workspaces und Alerts im Blick

Die Polycrate-API-Plattform ergänzt die CLI um eine zentrale Sicht. Sie ist der Einstieg in ein automatisierbares Control Plane:

• Monitoring von Runs: Welche Workflows laufen, sind erfolgreich, fehlgeschlagen?
• Workspace-Management: Welche Workspaces existieren, welche Blöcke und Versionen sind im Einsatz?
• Alerts: Benachrichtigungen bei Fehlern, Zeitüberschreitungen oder Policy-Verletzungen

Typische Anwendungsfälle:

• Integration in bestehende Monitoring- und Alerting-Landschaften
• Audit-Reports: Wer hat wann welche Action ausgeführt? Mit aktivierter CLI-API-Anbindung können polycrate run …-Ausführungen als Action Runs an die API gemeldet werden (konfigurierbar, z. B. submit_action_runs) – zentraler Work-/Audit-Trail pro Workspace statt nur verteilter Terminal-Historie; siehe Polycrate API und Audit & Compliance
• Multi-Team-Umgebungen, in denen viele Workspaces parallel betrieben werden

Gerade für Compliance-Verantwortliche ist das spannend: Am 25.05.2018 ist die DSGVO in Kraft getreten – seitdem müssen Zugriffe, Änderungen und Datenflüsse sauber nachvollziehbar sein. Die Polycrate-API bietet dafür strukturierte Daten über Automatisierungsvorgänge, ohne dass du eigene Logs mühsam aggregieren musst.

Technische Details findest du in der Polycrate-Dokumentation, insbesondere Polycrate API, Registry, Workspaces und die CLI.

MCP – Polycrate trifft KI-Tooling

MCP steht für das Model Context Protocol – nicht „Multi Control Plane“. Die CLI stellt mit polycrate mcp einen MCP-Endpunkt über stdio (JSON-RPC) bereit; Cursor, Claude Desktop oder VS Code / Copilot starten diesen Prozess bei Bedarf als Subprozess – du musst keinen separaten Dienst im Projektverzeichnis dauerhaft laufen lassen.

Was Polycrate MCP tatsächlich liefert (Auszug):

• Hub-Tools (hub_list_blocks, hub_inspect_block, …): Blöcke im Hub finden und inspizieren
• docs_get: ausgewählte Seiten der Polycrate-Dokumentation
• Spec-Tools (spec_workspace, spec_block, …): korrekte Struktur für workspace.poly / block.poly usw.
• Guide-Tools und CLI-Metadaten (Versionen, Artefakt-URLs)

Lokale Dateien wie inventory.yml oder Playbooks spiegelt MCP nicht automatisch – dafür nutzt du die IDE (Projektkontext) zusammen mit diesen Tools. Details und Client-Konfiguration: MCP Server Integration.

Das eröffnet Perspektiven wie:

• Block-Discovery und Konfigurationshilfe direkt im Chat (Hub + Doku + Schemas)
• Schnellere, konsistentere workspace.poly-Entwürfe ohne Copy-Paste aus veralteten Beispielen
• Klar getrennte Verantwortung: Vorschläge in der KI, Ausführung weiterhin mit polycrate run bei dir

Wichtig: MCP ersetzt keine Compliance-Regeln. Block-Modell, Workspaces und Workspace-Verschlüsselung bleiben die Leitplanken – unabhängig davon, ob eine KI Konfiguration vorschlägt.

Community und Open Source – eigene Blöcke beitragen

Polycrate versteht sich als europäisches, offen dokumentiertes Tooling. Das zeigt sich auch im Umgang mit Blöcken:

• Jeder kann eigene Blöcke erstellen und lokal nutzen.
• Blöcke können als OCI-Artefakte in private oder öffentliche Registries gepusht werden.
• Über PolyHub können sie auffindbar und wiederverwendbar werden.

Der Weg zu einem Community-Block:

1. Lokalen Block in blocks/ anlegen (block.poly + Playbooks, Templates)
2. Version sauber pflegen (version: 0.1.0, 0.2.0, …)
3. Gegen echte Zielumgebungen testen (Linux, Windows, IoT, Kubernetes)
4. Block in eine Registry pushen (z.B. cargo.ayedo.cloud) – siehe Registry-Dokumentation
5. Metadaten pflegen, damit andere wissen, was der Block tut und welche Policies er erfüllt

Workspace-Verschlüsselung ist dabei ein Pluspunkt: Du kannst sensible Konfiguration (Passwörter, API-Keys, Kubeconfigs) im Workspace mit age verschlüsseln, ohne externe Systeme wie Vault aufsetzen zu müssen:

polycrate workspace encrypt

Mehr dazu in der Workspace-Verschlüsselungs-Dokumentation.

ayedo als Partner im Polycrate-Ökosystem

ayedo ist nicht nur Initiator und Maintainer von Polycrate, sondern begleitet Unternehmen auch operativ:

• Polycrate-Einführung und Architektur: Von der ersten Demo bis zur strukturierten Automatisierungsplattform – beschrieben auf unserer Seite zu Polycrate.
• Platform Engineering: Aufbau einer internen Developer Platform oder Automationsplattform, bei der Polycrate, Kubernetes, Monitoring & Co. zusammenspielen – mehr dazu unter Platform Engineering.
• Beratung & Enablement: Reviews von bestehenden Ansible-Umgebungen, Migration in Blöcke, Schulungen für Teams im Linux-, Windows-, IoT- oder Compliance-Kontext – siehe unsere Beratung.
• Managed Blocks & Registry: Pflege von kritischen Blöcken (z.B. Hardening, Patching, Kubernetes-Cluster-Management) inklusive Security-Updates und Versionsstrategie.

Die Stärke: Das Team arbeitet selbst täglich mit Ansible, Kubernetes und klassischer Infrastruktur. Die Lösungen sind praxisnah – von „Wie strukturieren wir unsere Workspaces?“ bis „Wie binden wir Polycrate in unser bestehendes Ticketing- und Monitoring-System ein?“.

Was diese Artikel-Reihe gezeigt hat

In 25 Beiträgen haben wir Polycrate aus verschiedenen Blickwinkeln betrachtet:

• Linux / System Administration: Patch-Management, Reboots, Hardening, User-Management – alles als wiederverwendbare Blöcke.
• Windows-Administration: AD-Management, GPO-Rollouts, WinRM-Setup, Software-Verteilung – mit Polycrate als strukturiertem Rahmen um Windows-Module herum.
• Compliance & Security: Policy as Code, CIS-Benchmarks, Audit-Trails, DSGVO-konforme Workspaces mit Verschlüsselung und Nachvollziehbarkeit.
• Enterprise-Architektur: Multi-Team-Kollaboration, Block-Registry, Versionierung, Guardrails statt Wildwuchs.
• IoT & Edge: Raspberry Pi-Flotten, Edge-Nodes, OTA-Updates – mit Polycrate-Containern als reproduzierbarem Control-Plane.
• DevOps & Cloud-Native: Kubernetes-Cluster, Helm-Deployments, Multi-Cluster-Aufbau, ohne sich nur auf Cloud-Native zu verengen.

Immer wiederkehrende Muster:

• Das Dependency-Problem verschwindet, weil alles im Container läuft.
• Blöcke sind die Basiseinheit, die du teilen, versionieren und über PolyHub verbreiten kannst.
• Workspace-Verschlüsselung macht Compliance greifbar, ohne UX zu zerstören.
• Guardrails durch das Block-Modell verhindern, dass Playbooks unkontrolliert wachsen.
• Eine einfache CLI („polycrate run BLOCK ACTION“) senkt die Einstiegshürde – auch für weniger technische Kolleg:innen.

Nächste Schritte für verschiedene Zielgruppen

Linux / System Admins

Konkreter Startpunkt:

1. Einen neuen Workspace anlegen (z.B. acme-corp-automation).
2. Offizielle Linux-Blöcke aus PolyHub einbinden (z.B. linux-patching, linux-hardening).
3. Ein erstes Patch-Fenster als Workflow definieren.

Technisch: Folge der Workspace-Anleitung und der Ansible-Integration, binde deine SSH-Hosts laut SSH-Dokumentation ein und starte mit einem Standard-Block aus PolyHub.

Windows Admins

Konkreter Startpunkt:

1. Einen Workspace mit Windows-Hosts und WinRM-Zugriff aufsetzen.
2. Einen Windows-Block aus PolyHub (z.B. für AD-User oder GPO-Rollouts) einbinden.
3. Ein häufiges Runbook (z.B. Onboarding neuer Nutzer) als Block-Action kapseln.

Die Windows-spezifischen Module (ansible.windows.*) laufen im Container, du musst sie nicht auf dem Admin-Laptop verwalten. Details zur Nutzung von Windows-Hosts mit Polycrate findest du in der Ansible-Integration.

Enterprise-Architekten & Compliance-Verantwortliche

Konkreter Startpunkt:

1. Einen Pilot-Workspace definieren (z.B. für eine kritische Applikation).
2. Eine Block-Strategie festlegen: Welche Fähigkeiten sollen als Standard-Blöcke verfügbar sein?
3. Workspace-Verschlüsselung aktivieren und mit der Security-Abteilung abstimmen.

Nutze die API-Plattform, um Runs und Compliance-relevante Events zentral sichtbar zu machen, und entwickle gemeinsam mit den Teams ein Block-Katalog-Modell. Die Seiten zu Workspaces, Registry und Workspace-Verschlüsselung sind hier besonders relevant.

IoT- und Edge-Spezialisten

Konkreter Startpunkt:

1. Einen Workspace für deine Edge-Nodes anlegen (z.B. Raspberry Pis, Embedded Linux).
2. Einen Block für das Basis-Provisioning (OS-Setup, Monitoring-Agent, SSH-Konfiguration) bauen oder aus PolyHub adaptieren.
3. Polycrate als „OTA-Control-Plane“ etablieren: Updates, Rollbacks, Health-Checks.

Weil Polycrate im Container läuft, kannst du dasselbe Setup von der Dev-Workstation bis zum CI/CD-System nutzen – ohne pro Umgebung neu zu installieren. Die Best Practices helfen bei der Strukturierung deiner Edge-Blöcke.

Häufige Fragen

Brauche ich die Polycrate-API, um mit PolyHub-Blöcken zu starten?

Nein. Du kannst Polycrate rein über die CLI nutzen und Blöcke aus PolyHub direkt in deinen workspace.poly einbinden. Die API-Plattform wird interessant, wenn:

• Mehrere Teams parallel mit Polycrate arbeiten
• Du Runs zentral monitoren und auswerten möchtest
• Alerts (z.B. für fehlgeschlagene Deployments) notwendig sind

Für den Einstieg reicht ein Workspace, ein paar Blöcke, ein inventory.yml – alles lokal. Später kannst du die API hinzufügen, ohne deine bestehenden Workspaces wegzuwerfen.

Wie sicher ist die Workspace-Verschlüsselung im Vergleich zu Vault?

Polycrate nutzt age für die Verschlüsselung von Workspaces. Das ist leichtgewichtig, kryptographisch solide und vollständig in Polycrate integriert. Du brauchst kein separates System wie Vault, um:

• Secrets im Workspace sicher abzulegen
• Kubeconfigs, SSH-Keys oder Passwörter zu schützen
• Compliance-Anforderungen bezüglich „Secrets im Git“ zu adressieren

Vault bleibt sinnvoll für komplexe Secret-Management-Landschaften. Wenn es „nur“ um sichere Workspaces und Auditierbarkeit von Automatisierung geht, ist die eingebaute Workspace-Verschlüsselung oft der schnellere Weg.

Wie unterstützt ayedo beim Aufbau einer Automatisierungsplattform mit Polycrate?

ayedo unterstützt auf mehreren Ebenen:

• Analyse deiner bestehenden Ansible-/Skript-Landschaft und Ableitung einer Block-Struktur
• Aufbau einer oder mehrerer Polycrate-Registries (interne PolyHub-Variante)
• Definition von Guardrails, Workspaces und Standard-Blöcken
• Integration der Polycrate-API in Monitoring, Ticketing und IAM

Ob du nur punktuell Unterstützung brauchst oder eine langfristige Begleitung wünschst – Details findest du auf den Seiten zu Polycrate, Platform Engineering und unsere Beratung.

Weitere Fragen? Siehe unsere FAQ

Von der Theorie zur Umsetzung

Polycrate, PolyHub, API-Plattform und MCP bilden zusammen ein Ökosystem, das Automatisierung strukturiert, teilbar und zukunftsfähig macht – ohne dabei den Alltag von Linux-Admins, Windows-Teams oder IoT-Spezialisten aus den Augen zu verlieren.

In dieser Artikel-Reihe haben wir Schritt für Schritt gezeigt, wie:

• Aus einzelnen Ansible-Playbooks wiederverwendbare Blöcke werden
• Workspaces Ordnung, Verschlüsselung und Auditierbarkeit bringen
• PolyHub als Marktplatz die Wiederverwendung fördert
• Die API-Plattform Runs und Workspaces transparent macht (optional inkl. Action-Run-Tracking über die API)
• MCP (Model Context Protocol) KI-Assistenten mit Hub-, Doku- und Schema-Kontext versorgt – ohne polycrate run aus der KI zu automatisieren

ayedo begleitet dich dabei technisch und organisatorisch:

• Wir helfen beim Design deiner Block- und Workspace-Architektur.
• Wir stellen erprobte, gepflegte Blöcke für Infrastruktur, Security und Kubernetes bereit.
• Wir integrieren Polycrate in deine bestehende Plattform- und Compliance-Landschaft.

Der beste Weg, den Mehrwert für dein eigenes Umfeld zu beurteilen, ist eine konkrete Demo mit deinen Anforderungen und Beispielen aus deinem Alltag.

Übersicht und Anmeldung: Workshops.