The Polycrate Ecosystem: PolyHub, API, MCP, and the Future of Automation

TL;DR

• Polycrate is more than just a CLI tool: With PolyHub, an API platform, and MCP, it forms an ecosystem where reusable automation blocks, monitoring, and AI integration come together.
• PolyHub acts as a marketplace for versioned blocks—from Linux patching to Windows management to Kubernetes—while the Polycrate API makes workspaces, runs, and alerts centrally visible and manageable.
• MCP (Model Context Protocol, polycrate mcp) gives AI clients Hub, docs, and schema tools—execution stays in your CLI; see the MCP documentation.
• This article series has shown how Linux, Windows, IoT, and enterprise teams can evolve from initial playbooks to structured, encrypted, shareable automation platforms with Polycrate.
• ayedo accompanies this journey as an experienced partner with Polycrate expertise, platform engineering offerings, and consulting services—from the first demo to managed blocks and API integration.

Overview of the Polycrate Ecosystem

Polycrate was created as a pragmatic response to a well-known problem: Ansible is powerful, but the surrounding setup can be cumbersome. Python versions, local setups, playbook sprawl, lack of structure, compliance approvals—all of these consume time.

With Polycrate, Ansible is containerized and gets a framework:

• The entire toolchain runs in the container—no local Ansible, no Python chaos, fewer supply chain risks.
• Blocks structure automation and provide guardrails against playbook sprawl.
• Workspaces bundle hosts, secrets, blocks, and workflows.
• Workspace encryption with age ensures simple, built-in security.

What was more implicit in this article series: Polycrate is not just a tool, but an ecosystem. It includes:

• PolyHub: the marketplace for reusable blocks, accessible at hub.polycrate.io
• Polycrate API Platform: central view of workspaces, runs, status, and alerts
• MCP (Model Context Protocol): AI clients use polycrate mcp (stdio) to query Hub, docs, and schemas—see MCP documentation
• Community and Open Source: build, share, fork, and improve your own blocks

Let's take a closer look at these components—and what they mean for Linux admins, Windows teams, IoT environments, and enterprise architects.

PolyHub – The Marketplace for Automation

PolyHub is the OCI-based registry for Polycrate blocks. Technically, blocks are versioned and published like container images; practically, it feels like an app store for automation:

• Official ayedo blocks (e.g., for Kubernetes, monitoring, security, storage)
• Community blocks for Linux, Windows, IoT, Edge, compliance
• Custom internal blocks pushed to private registries

What Blocks Are Available – and How Do I Find Them?

At hub.polycrate.io, you can filter blocks, such as:

• infra/linux-* for Linux servers (patch management, hardening)
• infra/windows-* for Windows servers, AD, GPO
• k8s/* for Kubernetes clusters, ingress, monitoring
• security/* for CIS benchmarks, audit logging, compliance checks

Each block is:

• Versioned (e.g., :0.4.2—never use :latest)
• Documented (inputs, actions, examples)
• Sharable: You can integrate it into your workspaces or fork and customize it

An example of a workspace definition that combines a block from PolyHub and a local block:

# 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"

The YAML inventory is located in the workspace root as inventory.yml, as described in the workspace documentation:

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

The local block custom-hardening might look like this:

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

config:
  profile: "cis_level1"

actions:
  - name: apply
    description: "Apply hardening profile"
    playbook: hardening.yml

And the corresponding 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'

The whole setup is executed as usual in the container:

polycrate run custom-hardening apply

Dependencies (Ansible, Python, modules like ansible.builtin.*) are included in the Polycrate container. You don't need to install Ansible or Python locally—this elegantly and reproducibly solves the classic dependency problem.

With plain Ansible, you would:

• Install Ansible locally and/or on a control host
• Manually manage ansible.cfg, Python versions, and collections
• Store the playbook and inventory "out of sequence" somewhere

With Polycrate, the same content is packaged into a block, with clear structure and guardrails. More on this in the Ansible integration and best practices.

Polycrate API – Monitoring Runs, Workspaces, and Alerts

The Polycrate API platform complements the CLI with a central view. It is the entry point to an automatable control plane:

• Monitoring of Runs: Which workflows are running, successful, or failed?
• Workspace Management: Which workspaces exist, which blocks and versions are in use?
• Alerts: Notifications for errors, timeouts, or policy violations

Typical use cases:

• Integration into existing monitoring and alerting landscapes
• Audit reports: who ran which action when? With the CLI connected to the API, polycrate run … executions can be submitted as action runs (configurable, e.g. submit_action_runs)—a central work/audit trail per workspace instead of only scattered terminal history; see Polycrate API and Audit & Compliance
• Multi-team environments where many workspaces are operated in parallel

This is particularly interesting for compliance officers: On May 25, 2018, the GDPR came into force—since then, accesses, changes, and data flows must be traceable. The Polycrate API provides structured data on automation processes without you having to laboriously aggregate your own logs.

Technical details can be found in the Polycrate documentation, especially Polycrate API, registry, workspaces, and the CLI.

MCP – Polycrate Meets AI Tooling

MCP is the Model Context Protocol—not “Multi Control Plane.” The CLI exposes an MCP endpoint via polycrate mcp over stdio (JSON-RPC). Cursor, Claude Desktop, or VS Code / Copilot launch this process on demand as a subprocess—you do not need a long-running service in your project folder.

What Polycrate MCP actually provides (examples):

• Hub tools (hub_list_blocks, hub_inspect_block, …): find and inspect blocks on the Hub
• docs_get: selected Polycrate documentation pages
• Spec tools (spec_workspace, spec_block, …): correct structure for workspace.poly / block.poly, etc.
• Guide tools and CLI metadata (versions, artifact URLs)

MCP does not automatically mirror local files like inventory.yml or playbooks—use the IDE (project context) together with these tools. Details and client configuration: MCP Server Integration.

This enables workflows such as:

• Block discovery and configuration help in chat (Hub + docs + schemas)
• Faster, more consistent workspace.poly drafts without copy-paste from stale examples
• Clear separation: suggestions in the AI, execution still with polycrate run on your side

Important: MCP does not replace compliance rules. The block model, workspaces, and workspace encryption remain the guardrails—whether or not an AI suggests configuration.

Community and Open Source – Contributing Your Own Blocks

Polycrate sees itself as European, openly documented tooling. This is also reflected in the handling of blocks:

• Anyone can create and use their own blocks locally.
• Blocks can be pushed as OCI artifacts to private or public registries.
• Through PolyHub, they can become discoverable and reusable.

The path to a community block:

1. Create a local block in blocks/ (block.poly + playbooks, templates)
2. Maintain versioning properly (version: 0.1.0, 0.2.0, …)
3. Test against real target environments (Linux, Windows, IoT, Kubernetes)
4. Push the block to a registry (e.g., cargo.ayedo.cloud)—see registry documentation
5. Maintain metadata so others know what the block does and which policies it fulfills

Workspace encryption is a plus: You can encrypt sensitive configuration (passwords, API keys, kubeconfigs) in the workspace with age without having to set up external systems like Vault:

polycrate workspace encrypt

More on this in the workspace encryption documentation.

ayedo as a Partner in the Polycrate Ecosystem

ayedo is not only the initiator and maintainer of Polycrate but also supports companies operationally:

• Polycrate Introduction and Architecture: From the first demo to a structured automation platform—described on our Polycrate page.
• Platform Engineering: Building an internal developer platform or automation platform where Polycrate, Kubernetes, monitoring & co. play together—more on this under Platform Engineering.
• Consulting & Enablement: Reviews of existing Ansible environments, migration into blocks, training for teams in Linux, Windows, IoT, or compliance contexts—see our consulting.
• Managed Blocks & Registry: Maintenance of critical blocks (e.g., hardening, patching, Kubernetes cluster management) including security updates and version strategy.

The strength: The team works daily with Ansible, Kubernetes, and traditional infrastructure. The solutions are practical—from "How do we structure our workspaces?" to "How do we integrate Polycrate into our existing ticketing and monitoring system?".

What This Article Series Has Shown

In 25 articles, we have looked at Polycrate from various perspectives:

• Linux / System Administration: Patch management, reboots, hardening, user management—all as reusable blocks.
• Windows Administration: AD management, GPO rollouts, WinRM setup, software distribution—with Polycrate as a structured framework around Windows modules.
• Compliance & Security: Policy as Code, CIS benchmarks, audit trails, GDPR-compliant workspaces with encryption and traceability.
• Enterprise Architecture: Multi-team collaboration, block registry, versioning, guardrails instead of sprawl.
• IoT & Edge: Raspberry Pi fleets, edge nodes, OTA updates—with Polycrate containers as a reproducible control plane.
• DevOps & Cloud-Native: Kubernetes clusters, Helm deployments, multi-cluster setup, without narrowing down to just Cloud-Native.

Recurring patterns:

• The dependency problem disappears because everything runs in the container.
• Blocks are the basic unit you can share, version, and distribute via PolyHub.
• Workspace encryption makes compliance tangible without ruining UX.
• Guardrails from the block model stop playbooks from growing unchecked.
• A simple CLI (polycrate run BLOCK ACTION) lowers the entry barrier—even for less technical colleagues.

Next steps for different audiences

Linux / system admins

Concrete starting points:

1. Create a new workspace (e.g. acme-corp-automation).
2. Pull in official Linux blocks from PolyHub (e.g. patching, hardening).
3. Define a first maintenance window as a workflow.

Technically: follow the workspace guide and Ansible integration, wire SSH hosts per the SSH documentation, and start with a standard block from PolyHub.

Windows admins

Concrete starting points:

1. Set up a workspace with Windows hosts and WinRM access.
2. Add a Windows block from PolyHub (e.g. AD users or GPO rollouts).
3. Wrap a frequent runbook (e.g. user onboarding) as a block action.

Windows modules (ansible.windows.*) run in the container—you do not manage them on the admin laptop. See Ansible integration.

Enterprise architects & compliance

Concrete starting points:

1. Define a pilot workspace (e.g. for a critical application).
2. Agree a block strategy: which capabilities should be standard blocks?
3. Enable workspace encryption and align with security.

Use the API platform to make runs and compliance-relevant events visible centrally, and develop a block catalog with your teams. Workspaces, registry, and workspace encryption are especially relevant.

IoT and edge specialists

Concrete starting points:

1. Create a workspace for your edge nodes (e.g. Raspberry Pis, embedded Linux).
2. Build or adapt a block for base provisioning (OS setup, monitoring agent, SSH).
3. Establish Polycrate as an “OTA control plane”: updates, rollbacks, health checks.

Because Polycrate runs in the container, you can use the same setup from dev workstations to CI/CD without reinstalling per environment. Best practices help structure edge blocks.

Frequently asked questions

Do I need the Polycrate API to start with PolyHub blocks?

No. You can use Polycrate purely via the CLI and reference blocks from PolyHub in workspace.poly. The API platform becomes interesting when:

• Multiple teams work with Polycrate in parallel
• You want to monitor and evaluate runs centrally
• You need alerts (e.g. for failed deployments)

To get started, a workspace, a few blocks, and inventory.yml locally are enough. You can add the API later without throwing away existing workspaces.

How does workspace encryption compare to Vault?

Polycrate uses age for workspace encryption. It is lightweight, cryptographically sound, and fully integrated. You do not need a separate system like Vault to:

• Store secrets safely in the workspace
• Protect kubeconfigs, SSH keys, or passwords
• Address compliance around “secrets in Git”

Vault remains right for complex secret-management estates. Where the focus is secure workspaces and auditable automation, built-in workspace encryption is often faster.

How does ayedo help build an automation platform with Polycrate?

ayedo helps on several levels:

• Analysis of your Ansible/script landscape and a derived block structure
• Building one or more Polycrate registries (internal PolyHub-style catalogs)
• Defining guardrails, workspaces, and standard blocks
• Integrating the Polycrate API into monitoring, ticketing, and IAM

Whether you need spot support or long-term partnership—see Polycrate, Platform Engineering, and our consulting.

More questions: FAQ.

From theory to practice

Polycrate, PolyHub, the API platform, and MCP form an ecosystem that makes automation structured, shareable, and future-proof—without losing sight of day-to-day work for Linux admins, Windows teams, or IoT specialists.

This series showed how:

• Individual Ansible playbooks become reusable blocks
• Workspaces bring order, encryption, and auditability
• PolyHub as a marketplace drives reuse
• The API platform makes runs and workspaces transparent (optionally including action-run tracking via the API)
• MCP (Model Context Protocol) supplies AI assistants with Hub, docs, and schema context—without automating polycrate run from the model

ayedo supports you technically and organizationally:

• We help design your block and workspace architecture.
• We provide proven, maintained blocks for infrastructure, security, and Kubernetes.
• We integrate Polycrate into your existing platform and compliance landscape.

The best way to judge value for your environment is a concrete demo with your requirements and real-world examples.

Overview and registration: Workshops.