Polycrate vs. plain Ansible: What You Gain – and Why It’s Worth It

TL;DR

• Plain Ansible is a powerful tool for ad-hoc automation, quick scripts, and simple setups – but teams quickly hit limits with dependencies, structure, and sharing.
• Polycrate builds on Ansible, neatly encapsulates it in a container, and introduces a block/workspace model that systematically addresses dependency chaos, playbook sprawl, and secret handling.
• Instead of “ansible installed somewhere,” with Polycrate you get a reproducible, containerized toolchain, sharable automation via OCI registry, workspace encryption, and guardrails for larger teams.
• There are valid scenarios where plain Ansible is the better choice – such as for very small environments, temporary scripts, or restricted environments without containers.
• ayedo supports you in finding the right mix of Ansible and Polycrate – from initial tests to comprehensive Platform Engineering with automated compliance and operational security.

Polycrate and Ansible in Direct Comparison

Ansible has been a de facto standard for automation for years – from Linux servers to Windows hosts to network components and IoT. Polycrate picks up exactly there: It doesn’t replace Ansible but structures and operationalizes it.

A rough classification:

In essence: Ansible is the engine, Polycrate is the operations framework around it.

Dependency Management: From “pip install ansible” to polycrate run

The Classic Way with Plain Ansible

Many teams start like this:

sudo apt-get install ansible

# or
python3 -m venv .venv
source .venv/bin/activate
pip install ansible==9.5.1
pip install -r requirements.txt

This includes:

• Different Python versions (2.7 vs. 3.x, different minor releases),
• Manual dependencies for collections (e.g., azure.azcollection, community.general),
• Individual ansible.cfg, SSH setups, PATH issues per workstation.

At the team level, this means:

• Onboarding is tedious (“Which Ansible version are you using?”),
• Errors that only occur on certain laptops,
• Supply chain risks due to uncontrolled pip install from the internet.

Polycrate: Ansible in the Container, Toolchain Included

With Polycrate , Ansible always runs in a container. Locally, you only need Polycrate and a container runtime (Docker, Podman):

polycrate run linux-patch patch

What happens here:

• Polycrate starts a defined container with a predefined toolchain (Ansible, Python, possibly kubectl, helm, etc.).
• The Ansible playbook is always executed in the same environment – identical on every developer laptop.
• There is no pip install on the workstation, no Python version conflicts, no manual setup.

This solves the classic dependency problem:

• No local Ansible installation,
• No Python version chaos,
• No individual “snowflake” workstations.

Details on integration can be found in the Ansible Integration in Polycrate and the Best Practices .

Sharing: Git Repos vs. Blocks in the OCI Registry

How Sharing Typically Looks with Plain Ansible

The standard is:

• A Git repo with playbooks and roles,
• Possibly an internal Galaxy-like repository,
• Documentation on how variables should be set (“Please read README.md”).

If you want to use a playbook from another team, you must:

• Clone the Git repo,
• Install dependencies,
• Understand ansible.cfg,
• Learn variable structure and conventions.

This works but becomes confusing as the organization grows.

Polycrate: Sharable Automation with Blocks

In Polycrate, you package automation into blocks. Each block is:

• Versioned,
• Portable,
• Shareable via OCI registry (e.g., cargo.ayedo.cloud or own registry),
• Reusable and configurable via workspace.poly.

An example of a local block blocks/linux-patch/block.poly:

name: linux-patch
version: 0.1.0
kind: generic

config:
  target_hosts: all
  maintenance_window: "sunday-2200"

actions:
  - name: patch
    description: "Performs a dist-upgrade on Linux servers"
    playbook: patch.yml

Excerpt from workspace.poly that instantiates the block:

name: acme-corp-automation
organization: acme

blocks:
  - name: linux-patch
    from: linux-patch
    config:
      target_hosts: all
      maintenance_window: "sunday-2200"

Another workspace – perhaps from another team – could reference the same block via a registry:

name: acme-ops
organization: acme

blocks:
  - name: linux-patch-prod
    from: cargo.ayedo.cloud/acme/linux/linux-patch:0.1.0
    config:
      target_hosts: prod-linux
      maintenance_window: "saturday-2300"

With polycrate run linux-patch-prod patch, they use your automation without:

• Knowing your Git layout,
• Adopting your ansible.cfg,
• Repeating your collections installation routines.

This is “Sharable Automation”: What you build, others can use immediately – versioned and reproducible. More on this in the PolyHub Documentation and directly in PolyHub at hub.polycrate.io .

Secrets and Compliance: Ansible Vault vs. Workspace Encryption

Ansible Vault in Practice

Ansible Vault is proven but cumbersome to handle:

• You must decide: Encrypt the entire file or only individual variables?
• Passwords or vault IDs must be securely distributed and managed.
• Integration into CI/CD is possible but usually specifically “tweaked.”

From a compliance perspective (e.g., in the context of GDPR, which came into effect on May 25, 2018), you ask questions like:

• Where are my secrets stored in the Git repo?
• Who has access to vault keys?
• How do I document that secrets are encrypted?

Polycrate: Workspace Encryption with age

Polycrate takes a different approach: The entire workspace (or selected parts, especially artifacts/secrets/) can be encrypted with age. You don’t need a separate vault service.

Typical procedure:

# Initialize workspace (if not already done)
polycrate workspace init

# Add secrets, e.g., SSH keys, API tokens
mkdir -p artifacts/secrets
echo "super-secret-password" > artifacts/secrets/db-password.txt

# Encrypt workspace
polycrate workspace encrypt

Polycrate ensures that:

• Secrets don’t end up in plaintext in the Git repo,
• Access is regulated via the CLI,
• Actions transparently access the decrypted content when executed.

Advantages over Vault:

• No additional server component (no HashiCorp Vault or similar),
• Easy to use for admins and engineers,
• Direct integration into the workspace model.

Details can be found in the documentation on Workspace Encryption .

Structure and Guardrails: From Playbook Sprawl to Block Model

Plain Ansible: Free but Quickly Confusing

With Ansible, you can choose your structure completely freely:

• playbooks/, roles/, group_vars/, host_vars/, inventories/ …
• Project A uses a different structure than Project B,
• Conventions exist – but are not enforced.

In small teams, this is often okay. In larger environments, it quickly becomes chaotic:

• You don’t immediately find out where a variable comes from,
• Changes to global variables have unexpected side effects,
• “One-off playbooks” easily emerge that no one understands anymore.

Polycrate: Block/Action/Workspace as Structural Framework

Polycrate provides you with a clear framework:

• Workspace: Top level (workspace.poly), central configuration, inventories, secrets.
• Block: Functionally delimited unit (e.g., Linux patching, AD user management, Kubernetes deployment).
• Action: Specific operation within a block (e.g., patch, dry-run, rollback).

This framework prevents playbook sprawl and creates guardrails. Each action is called exactly like this:

polycrate run linux-patch patch

No long ansible-playbook commands with numerous parameters – easily understandable even for colleagues who don’t write Ansible daily.

Example: Linux Patching with Ansible vs. Polycrate

Plain Ansible Playbook patch.yml:

- name: Patch Linux systems
  hosts: all
  become: true

  tasks:
    - name: Update package list
      ansible.builtin.apt:
        update_cache: yes

    - name: Perform dist-upgrade
      ansible.builtin.apt:
        upgrade: dist
        autoremove: yes
        autoclean: yes

Inventory as YAML (inventory.yml):

all:
  hosts:
    server01.acme-corp.com:
      ansible_user: ubuntu
    server02.acme-corp.com:
      ansible_user: ubuntu

Call with plain Ansible:

ANSIBLE_INVENTORY=inventory.yml ansible-playbook patch.yml

Now the same with Polycrate. We use the same content from patch.yml, but parameterize hosts:

- name: Patch Linux systems (Polycrate)
  hosts: "{{ block.config.target_hosts }}"
  become: true

  tasks:
    - name: Update package list
      ansible.builtin.apt:
        update_cache: yes

    - name: Perform dist-upgrade
      ansible.builtin.apt:
        upgrade: dist
        autoremove: yes
        autoclean: yes

Our block blocks/linux-patch/block.poly:

name: linux-patch
version: 0.1.0
kind: generic

config:
  target_hosts: all
  maintenance_window: "sunday-2200"

actions:
  - name: patch
    description: "Performs a dist-upgrade on the defined hosts"
    playbook: patch.yml

And workspace.poly in the root directory:

name: acme-corp-automation
organization: acme

config:
  environment: "prod"

blocks:
  - name: linux-patch
    from: linux-patch
    config:
      target_hosts: all
      maintenance_window: "sunday-2200"

Call:

polycrate run linux-patch patch

Key points:

• The inventory (inventory.yml) is in the workspace root – Polycrate automatically sets ANSIBLE_INVENTORY.
• The variables block.config.* come from workspace.poly and are “deep-merged” with the block config. You have a central configuration model instead of scattered group_vars and host_vars.
• The block model’s guardrails keep your automation modular, traceable, and testable.

More on workspace and block structure: Workspaces , Blocks , and Actions .

Configuration management: hardcoded variables vs. deep-merge

With plain Ansible you often see:

• hardcoded variables in the playbook,
• variables in vars/, group_vars/, host_vars/,
• overrides via -e on the CLI.

That is flexible, but:

• the source of a variable is sometimes hard to trace,
• you must enforce conventions strictly or sprawl wins.

Polycrate adds:

• workspace.config for global defaults,
• block.config per block instance,
• additional parameters per action (e.g. interactive input or pipeline parameters),
• defined deep-merge behavior across these layers.

That lets you separate environments cleanly:

• workspace.config.environment = "prod" vs. "dev",
• different target_hosts per block instance,
• while reusing the same blocks and playbooks.

You keep Ansible’s strengths (idempotency, large module ecosystem) and gain a clear configuration model at workspace level.

Ecosystem: Ansible Galaxy vs. PolyHub

Ansible Galaxy is a huge pool of roles and collections. Many can be used directly inside Polycrate blocks:

• collections: in requirements.yml,
• roles: in your playbooks.

Polycrate extends this with:

• PolyHub for curated, versioned blocks for infrastructure, monitoring, security, storage, and more,
• official ayedo blocks for common tasks (e.g. Kubernetes baselines, monitoring stacks, security scans),
• company blocks in a private registry.

You combine Galaxy’s breadth with Polycrate’s structured block model and sharing story.

When plain Ansible is the better choice

Polycrate is not a silver bullet. Plain Ansible is often enough—or better—when:

• Very small setups: a few servers, one admin, little collaboration; a hand-built playbook may be enough.
• Short-lived scripts and prototypes: quick tests, one-off migrations, ad-hoc API calls—a single playbook without a workspace is faster.
• Heavily restricted environments: no Docker or Podman; you must rely on system packages.
• Mature Ansible estates: if you already have clear conventions, CI/CD, and secret handling, Polycrate’s upside may be smaller—or mainly in sharing and a unified developer toolchain.

Important: Polycrate builds on Ansible. You do not have to “switch” wholesale—you can:

• wrap existing playbooks as blocks,
• build new automation in the block model,
• use Polycrate for collaboration, compliance, and reproducibility,
• keep one-off automation on plain Ansible.

Frequently asked questions

Can I reuse my existing Ansible playbooks in Polycrate?

Yes. Polycrate runs Ansible in a container. You can:

1. put your playbook in a block directory,
2. add a block.poly that points to it,
3. reference the block in workspace.poly,
4. run it with polycrate run BLOCK ACTION.

Migration effort depends on how tidy your current layout is. Often you only need to parameterize hosts (e.g. hosts: "{{ block.config.target_hosts }}") and move inventory/variables into the workspace model. See Ansible integration in Polycrate .

Do I need Kubernetes or container expertise?

You do not need Kubernetes skills, but basic container literacy helps. Polycrate uses containers for a reproducible Ansible toolchain. For typical Linux/Windows/AD/IoT scenarios you do not build images yourself—you use the standard toolchain or one provided by your organization. If you already do Platform Engineering , Polycrate fits well with container and GitOps workflows.

Is Polycrate only for large enterprises?

No. Larger orgs feel dependency chaos, sharing, compliance, and multi-team issues most—but smaller teams also gain from easier onboarding, clear block boundaries, and built-in workspace encryption without an extra vault stack.

If your Ansible footprint is growing and getting messy, Polycrate is worth a look before sprawl hardens.

More questions: FAQ .

From theory to practice

Plain Ansible and Polycrate are not opposites—they are two layers of the same idea: scriptable, declarative infrastructure. Ansible is the engine; Polycrate handles the operational pain: dependencies, sharing, structure, secrets, reuse.

In this article you saw:

• where Polycrate adds concrete value (container toolchain, guardrails, workspace encryption, block sharing),
• when plain Ansible is enough,
• how a simple use case—Linux patching—looks with both approaches,
• how the block/workspace model bridges single playbooks and a structured automation portfolio.

At ayedo we support teams from first Polycrate experiments to full Platform Engineering setups where Ansible, Polycrate, monitoring, security, and compliance work together. Whether you optimize Ansible first or later build a full Polycrate -based automation platform, the next steps should stay pragmatic, traceable, and workable for your team.

If you want to feel how polycrate run compares to ansible-playbook in daily use, now is a good time to try it.

Overview and registration: Workshops .