Fabian Peter · · 8 min read

Polycrate: Deployment Automation for Kubernetes and Cloud Migration

Polycrate: Migration from On-Premise to Kubernetes

Ansible Kubernetes Polycrate Automation

TL;DR

  • Polycrate is an Ansible-based framework for deployment automation that containerizes all necessary tools, enabling reproducible deployments across different environments—from bare metal to Kubernetes.
  • Core concepts like Blocks, Workspace, and Actions allow for modular, versionable, and auditable representation of complex cloud migrations and Day-2 operations.
  • For cloud migrations, PolyHub provides free Blocks to migrate managed services from hyperscalers like AWS RDS, ElastiCache, or S3 to Kubernetes-native alternatives like CloudNativePG, Redis, or MinIO—a practical lever for Data Act-compliant cloud switching.
  • Polycrate supports the implementation of requirements from the Data Act, NIS-2, DORA, and the Cyber Resilience Act by enabling reproducible, documented, and provider-independent deployments.
  • ayedo uses Polycrate and the PolyHub to pragmatically support companies in cloud migration, Kubernetes platform development, and compliance-oriented infrastructure automation.

Polycrate as a Framework for Deployment Automation

Polycrate addresses a common but structural problem in modern infrastructures: the actual complexity rarely lies in a single tool but in the integration and operation of entire toolchains—across multiple providers, regions, and environments.

Instead of building each environment with a new set of shell scripts, playbooks, and ad-hoc workarounds, Polycrate offers a unified framework to:

  • encapsulate tools and dependencies,
  • standardize installation logic,
  • provide reusable workflows for deployment and maintenance.

Technically, Polycrate consists of a CLI that executes all actions within a Docker container. This container brings a complete cloud-native toolchain—including Ansible, kubectl, Helm, Terraform, and other tools for migration, backup, and automation. This minimizes local dependencies and ensures reproducible results: checking out a workspace and running Polycrate yields the same behavior, regardless of the local machine.

Blocks, Workspace, Actions: Three Building Blocks for Order

Polycrate structures infrastructure into three core concepts, creating a clear abstraction layer.

Blocks: Modularized Infrastructure Components

A Block encapsulates a specific system or function, for example:

  • a Kubernetes cluster (such as k3s on bare metal),
  • a database (CloudNativePG),
  • a Redis cluster,
  • a MinIO deployment,
  • observability stacks or security components.

A Block contains everything needed for this system: required tools, Ansible playbooks, standard configurations, documentation. Blocks are versionable and thus usable as reusable, portable components—both within a company and via the PolyHub.

Workspace: Shared Context for Complex Scenarios

A Workspace bundles multiple Blocks into a consistent context. Typical examples:

  • A "Landing Zone" workspace for the initial deployment of a sovereign Kubernetes platform.
  • A migration workspace for replacing AWS RDS, ElastiCache, and S3 with CloudNativePG, Redis, and MinIO.
  • An operations workspace for Day-2 operations (backups, upgrades, compliance checks).

The Workspace defines how Blocks interact, which configurations are shared (e.g., kubeconfigs, secrets, network settings), and which workflows are relevant at the organizational level.

Actions: Usable Workflows Instead of Script Collections

Actions are user-friendly commands provided from Blocks, such as:

  • install for the initial installation of a component,
  • upgrade for controlled updates,
  • backup and restore for data protection,
  • migrate for cloud migrations.

Instead of working through various scripts and playbooks, stakeholders receive a clearly structured interface: "What actions can I reasonably perform on this system?" This reduces dependency on individuals and improves auditability and documentation.

Polycrate as an Enabler for Cloud Migration

Cloud migration today often means moving out of proprietary services of hyperscalers into standardized, Kubernetes-native architectures. This is where Polycrate comes in.

PolyHub: Free Building Blocks for Hyperscaler Alternatives

PolyHub offers curated, free Blocks for typical infrastructure components. Instead of reinventing every migration path, you can reuse proven patterns.

Examples of common migrations:

  • AWS RDS → CloudNativePG
    Polycrate Blocks provide CloudNativePG as a Kubernetes operator, including configuration for high availability, backups, and monitoring. A Block thus becomes an "RDS-like" database platform in your cluster.

  • AWS ElastiCache → Redis on Kubernetes
    A Redis Block handles the installation of a highly available Redis cluster, including Sentinel/fencing mechanisms and optional persistence. For applications, Redis remains Redis—only the operating mode becomes sovereign.

  • AWS S3 → MinIO
    A MinIO Block provides S3-compatible object storage in your own cluster or on bare metal. Applications that currently speak S3 can usually be switched to MinIO without code changes.

Through these pre-built Blocks, you get a concrete migration narrative: from managed services of the hyperscaler to Kubernetes-native services that you can operate yourself—or together with a partner.

Data Act-Compliant Cloud Switching with Polycrate

The Data Act mandates binding rules for cloud switching and interoperability from September 12, 2025. Companies gain a right to portability, but they must also be able to technically implement it.

Polycrate addresses three central requirements:

  1. Open, Machine-Readable Formats
    Workspaces, Blocks, and configurations are in open, text-based formats. They are versionable, auditable, and transferable to other providers or service providers.

  2. Functional Equivalence Through Standard Components
    Instead of proprietary database or cache services, you use CloudNativePG, Redis, or MinIO—technologies that can be operated on any infrastructure that supports Kubernetes.

  3. Documented Switching Processes
    Clearly defined Actions (e.g., migrate-rds-to-cloudnativepg) explicitly document switching processes. These Actions can become part of your internal policies and compliance documentation.

Thus, Polycrate becomes the operational counterpart to the legal portability claims of the Data Act.

Polycrate for Kubernetes: From k3s Cluster to Day-2 Operations

Kubernetes is now the de facto standard for a cloud-agnostic platform. Polycrate consistently uses Kubernetes as the target environment—regardless of whether the cluster runs on a hyperscaler, a European provider, or in your own data center.

k3s Installation and Cluster Bootstrap

Many organizations start with k3s to run a lean, production-ready Kubernetes cluster on bare metal or VMs. Polycrate Blocks for k3s can:

  • prepare hosts (network, kernel parameters, container runtime),
  • provision an initial control plane node and worker nodes,
  • securely manage kubeconfigs and certificates in the workspace,
  • install basic components like CNI, ingress, storage class.

The k3s infrastructure thus becomes part of the same automation logic as your applications. Changes to the cluster are traceable and repeatable—a crucial point for auditability and disaster recovery.

Managed Apps and Day-2 Operations

Once the cluster is up, the actual operation begins: upgrades, scaling, backups, monitoring, security. Polycrate Blocks handle these tasks for a growing number of "Managed Apps," such as:

  • databases (CloudNativePG, MySQL),
  • caches (Redis),
  • object storage (MinIO),
  • observability stacks (e.g., Prometheus-/VictoriaMetrics-based solutions),
  • ingress and API gateways,
  • registries like Harbor for container images.

Day-2 operations are encapsulated in Actions that bundle tasks such as:

  • rolling updates with pre-checks and rollback strategies,
  • regular backups and test restores,
  • rotation of certificates and secrets,
  • scaling adjustments based on metrics,
  • security hardening and compliance checks.

For stakeholders, this creates a clear, operable set of maintenance routines that replace the proliferation of individual admin scripts.

Compliance, Sovereignty, and Reproducibility

Regulations like the NIS-2 Directive, the Digital Operational Resilience Act (DORA), the Data Act, and the upcoming Cyber Resilience Act shift the focus away from mere functionality towards robust, traceable resilience.

Reproducible Deployments as a Response to NIS-2 and DORA

The NIS-2 Directive must be transposed into national law by October 17, 2024, and requires effective technical and organizational measures to ensure operational resilience. DORA applies directly to financial companies and their IT service providers from January 17, 2025, focusing particularly on ICT risk management and operational stability.

Polycrate supports these requirements operationally by:

  • ensuring deployments run deterministically because all steps are defined and versioned in the workspace.
  • making changes to infrastructure and applications traceable and trackable (Who executed which Action with which version and when?).
  • allowing disaster recovery scenarios to be tested, as complete environments can be rebuilt from the workspace.

What was once a collection of "best effort" scripts becomes a controlled, repeatable process—a prerequisite for audits and external reviews.

Cloud Sovereignty and Provider Independence

The European discourse on "cloud sovereignty" is reflected in initiatives and guidelines like the Cloud Sovereignty Framework. At its core, it is about retaining technological agency, even if individual providers fail, prices rise, or regulatory conditions change.

Polycrate addresses this goal by:

  • consistently using open standards (Ansible, Kubernetes, OCI images),
  • providing portable workspaces that can be applied to different providers,
  • employing polyglot toolchains that are not tied to a single hyperscaler.

This makes it realistic to shift workloads from a hyperscaler to a European provider or your own data center without reinventing automation.

Cyber Resilience Act: Secure-by-Design Throughout the Lifecycle

The Cyber Resilience Act was passed in 2024; most material obligations are expected to take effect from 2027. It demands security-by-design and continuous maintenance throughout the product lifecycle.

With Polycrate, you can:

  • represent security-relevant configurations (e.g., cluster hardening, encryption activation, logging) as repeatable Actions.
  • roll out patches and security updates in a standardized manner—not just once, but as an established routine.
  • demonstrate that maintenance and update obligations have indeed been fulfilled.