Skip to main content
Clone stack configurations from existing clusters or remote repositories. Perfect for replicating production setups to staging or dev environments.

​
Prerequisites

  • Ankra CLI installed and configured
  • A cluster configuration file (YAML)

​
Clone from a Local File

Copy stacks from an existing cluster configuration:

​
Clone from GitHub

Pull configurations directly from a repository:

​
Clone Options

Examples:

​
Example Workflow

1

Clone from GitHub

2

Apply the Configuration

3

Customize Values

Edit the YAML file or use the UI to adjust values for your environment (resource limits, domains, replicas).

​
Clone via UI

You can clone stacks directly in the Ankra UI: Clone a single stack:
  1. Navigate to Stacks in your cluster
  2. Click the menu on any stack card
  3. Select Clone to Cluster
  4. Choose a target cluster and click Clone Stack
Clone multiple stacks at once:
  1. Navigate to Stacks in your cluster
  2. Click the Clone Stacks button next to the search bar (or click a stack card’s avatar to start selecting)
  3. Select the stacks you want to clone - a floating action bar shows the count
  4. Click Clone to Cluster, choose a target cluster, and confirm
  5. All selected stacks are cloned as drafts to the target cluster
For a full guide on multi-stack cloning, see Clone Stacks Between Clusters.

​
Clone a whole cluster

Clone Cluster in a cluster’s menu copies every stack of that cluster onto a new one and, with Deploy after cloning left on, deploys them there straight away. The dialog asks where the clone should run:
  • Import an existing cluster - Ankra creates an import cluster and prints the command that connects it. Pick this when the clone should land on Kubernetes you already run.
  • Build on a cloud provider - Ankra provisions a new cluster on Hetzner, OVHcloud, UpCloud, DigitalOcean, Scaleway, Proxmox VE or HPE Morpheus and copies the stacks onto it. Choose the provider and click Continue; the provider’s create page opens with a Cloning from notice, where you pick the credential, region, node sizes and the usual create options. Create Cluster there builds the cluster and clones the stacks in one request. This is the path for moving a workload between clouds.
A cloud-provider clone skips the stacks the provider’s own provisioning installs - the cloud controller (hcloud, openstack, upcloud-cloud-provider, digitalocean-cloud-provider, scaleway-cloud-provider), networking, external-dns and, on kubeadm targets, cilium. The new cluster gets the target provider’s versions of those; the result lists them under stacks_skipped with a warning naming each one. Stacks whose values pin the old provider (a storage class, a load-balancer annotation, a node selector) still clone, so review each draft before deploying.
The same request is available to automation: POST /org/clusters/imported/{cluster_id}/clone with target_provider and a target object carrying that provider’s create body (the fields of POST /org/clusters/{provider}), and deploy_after_clone: true to deploy the clones. The response carries target_provider, stacks_skipped, stacks_deployed and stacks_held alongside the cloned and failed stacks; each cloned stack reports its needs_input.

​
Stacks that need your input

A clone never carries secrets: every value a member’s encrypted_paths seal is replaced by the ENCRYPTED_VALUE_REMOVED placeholder on the target. A stack that still holds that placeholder cannot come up healthy, so the clone does not deploy it. It is kept as a draft and marked Needs input in the stack list, with the members and values to re-enter listed on the chip and in the clone result. Open the draft: the builder shows the same list as a banner, each entry opens the add-on or manifest that holds the field, and once every placeholder is replaced the banner disappears and Create Stack deploys it. Everything else deploys on its own; addons that had no stored configuration deploy with chart defaults and are named in the warnings.

​
What a cluster clone carries

Beyond the stacks, a cluster clone also copies the source cluster’s cluster variables, so stack content keeps resolving its ${{ ankra.* }} tokens. Everything else that is cluster-scoped cannot be cloned and is named in the result’s warnings instead: a deployed SOPS key, registry pull secrets, the Git repository connection, and Prometheus or log source connections. Reconnect those on the new cluster before deploying stacks that need them.

​
Next Steps

Ankra CLI Reference

Full CLI command reference.

GitOps Examples

Example cluster configurations to clone.